Capítulo 14 — Engenharia de software

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Desenvolvimento como controle"]
  N1["14.2 Gestão de mudanças"]
  N2["14.3 Código de terceiros"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Desenvolvimento como controle"]
  N1["14.2 Gestão de mudanças"]
  N2["14.3 Código de terceiros"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX040"]

[14.1 Desenvolvimento como controle]
    |
    v
[14.2 Gestão de mudanças]
    |
    v
[14.3 Código de terceiros]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) aplicar práticas de desenvolvimento seguro como controles de governança; (2) gerenciar mudanças com aprovação e rastreabilidade; (3) incluir o código de terceiros no risco.

14.1 Desenvolvimento como controle

A Ardwell desenvolve e mantém seu portal de pagamento para clientes. Nadia aprende que as práticas de desenvolvimento seguro, como revisão de código, testes de segurança e gestão de dependências, são controles de governança, além de hábitos de engenharia. A ISO/IEC 27002:2022 inclui controles para ciclos de vida de desenvolvimento seguro e codificação segura, e o PCI DSS v4.0 exige que o software sob medida dos sistemas de pagamento seja desenvolvido com segurança. Ela mapeia cada prática do fluxo de trabalho da equipe do portal a esses requisitos e anota onde já existe evidência nas ferramentas da equipe, como os registros de revisão no repositório, que podem ser reaproveitados nas auditorias.

14.2 Gestão de mudanças

Toda mudança no portal passa por um ticket, uma revisão de código e uma aprovação antes da implantação. Nadia confere um mês sintético de mudanças e descobre que a maioria é rastreável do ticket até a implantação, mas algumas correções emergenciais pularam a revisão. Ela recomenda um caminho emergencial documentado, com revisão posterior em até dois dias úteis. A gestão de mudanças rastreável permite que os auditores confirmem que o que roda em produção foi aprovado, e que os engenheiros encontrem a mudança que introduziu um problema quando algo quebra. A revisão em dois dias úteis mantém o caminho emergencial rápido sem perder a rastreabilidade.

14.3 Código de terceiros

O portal depende de dezenas de bibliotecas de código aberto. Nadia aprende que cada uma é um fornecedor cujas vulnerabilidades se tornam risco da Ardwell. Ela propõe uma lista de materiais de software (SBOM) com cada componente e sua versão, com alertas automáticos quando uma vulnerabilidade conhecida for publicada. Também anota as obrigações de licenciamento, que são uma questão de compliance por si só. O Prof. Brenner observa que as aplicações modernas são, em sua maior parte, código de outras pessoas, então a governança precisa alcançar os componentes que a equipe nunca escreveu. A SBOM também diz à Ardwell, em poucas horas, que versões do portal são afetadas quando uma vulnerabilidade de biblioteca é anunciada.

Exemplo resolvido

Nadia mapeia as práticas de desenvolvimento às normas, encontra correções emergenciais sem rastreabilidade e propõe uma lista de materiais de software.

Caso sintético. Os registros de mudanças são sintéticos; as normas citadas são reais.

Erros e limites

As revisões variam em profundidade. As listas de componentes deixam escapar as dependências transitivas.

Exercícios

• EX040 — Normas para o desenvolvimento. A que duas normas Nadia mapeou o desenvolvimento seguro?
  Mostrar critérios de avaliação

  Rubrica: 3 = ISO/IEC 27002:2022 e PCI DSS v4.0;; 2 = duas;; 1 = vago;; 0 = nenhuma.
• EX041 — Caminho emergencial. O que Nadia recomendou para as correções emergenciais?
  Mostrar critérios de avaliação

  Rubrica: 3 = um caminho documentado com revisão em até dois dias úteis;; 2 = revisão posterior;; 1 = vago;; 0 = nenhuma.
• EX042 — Risco das bibliotecas. Por que as bibliotecas de código aberto são uma preocupação de governança?
  Mostrar critérios de avaliação

  Rubrica: 3 = suas vulnerabilidades e licenças se tornam risco da Ardwell;; 2 = fornecedor;; 1 = vago;; 0 = nenhuma.

Síntese

Desenvolvimento seguro, mudanças rastreáveis e inventários de componentes são controles de governança no software.