Capítulo 14 — Engenharia de software

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX027.

flowchart TD
  N0["14.1 Por que o processo importa"]
  N1["14.2 Um ciclo de vida de desenvolvimento seguro"]
  N2["14.3 Revisões e inspeções"]
  N3["14.4 Dependências e a cadeia de suprimentos"]
  N4["14.5 Versões para sistemas de vida longa"]
  N5["14.7 Atividade prática"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX027"]

Desenho lógico

flowchart LR
  N0["14.1 Por que o processo importa"]
  N1["14.2 Um ciclo de vida de desenvolvimento seguro"]
  N2["14.3 Revisões e inspeções"]
  N3["14.4 Dependências e a cadeia de suprimentos"]
  N4["14.5 Versões para sistemas de vida longa"]
  N5["14.7 Atividade prática"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX027"]

[14.1 Por que o processo importa]
    |
    v
[14.2 Um ciclo de vida de desenvolvimento seguro]
    |
    v
[14.3 Revisões e inspeções]
    |
    v
[14.4 Dependências e a cadeia de suprimentos]
    |
    v
[14.5 Versões para sistemas de vida longa]
    |
    v
[14.7 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX027]

Objetivos de aprendizagem e conexão

Ao fim deste capítulo você será capaz de (1) aplicar um ciclo de vida de desenvolvimento seguro de software ao software de infraestrutura; (2) gerenciar requisitos, revisões de projeto, revisão de código e inspeções; (3) gerenciar dependências e a cadeia de suprimentos de software com SBOMs e proveniência; e (4) planejar versões e atualizações para software embarcado e de TO de vida longa. Ele se apoia nos capítulos 5 e 9 e prepara os capítulos 28, 31 e 39.

14.1 Por que o processo importa

Brooks (1987) defendeu que as dificuldades essenciais do software — complexidade, conformidade, mutabilidade, invisibilidade — não admitem um avanço único e decisivo. O processo não as remove; ele torna os erros visíveis cedo, quando corrigi-los é barato, e deixa evidências de que o trabalho foi feito. Em infraestrutura crítica, a evidência faz parte do produto: reguladores, seguradoras e donos de ativos vão pedi-la. No gateway do TMRP, essa evidência inclui a revisão do modelo de ameaças, os resultados dos testes e a compilação assinada, que vão todos para o dossiê.

14.2 Um ciclo de vida de desenvolvimento seguro

O NIST Secure Software Development Framework (SP 800-218) agrupa as práticas em preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades. Concretamente: requisitos de segurança e modelos de ameaças com cada funcionalidade; padrões de codificação segura; revisão por pares; análise estática automatizada e testes na integração contínua; sistemas de compilação protegidos; recebimento e divulgação de vulnerabilidades; e correções com avisos claros. Os princípios de Secure by Design da CISA acrescentam que os fabricantes devem assumir a responsabilidade pelos resultados de segurança dos clientes — padrões seguros, nenhuma senha padrão, linguagens com segurança de memória onde for viável.

14.3 Revisões e inspeções

Fagan (1976) descreveu inspeções formais de projeto e de código, com papéis e listas de verificação definidos, relatando que elas encontravam defeitos mais cedo e de forma mais barata do que os testes. A revisão de código moderna é mais leve, mas mantém os princípios: uma segunda pessoa competente lê cada mudança, com uma lista de verificação que inclui validação de entradas, autenticação, tratamento de erros e registro em log. Métricas de complexidade, como a complexidade ciclomática de McCabe (McCabe, 1976), sinalizam funções difíceis de testar. Na LRWA, cada mudança no código do gateway é lida por um segundo engenheiro com uma lista de verificação.

14.4 Dependências e a cadeia de suprimentos

A maior parte do software é montada a partir de componentes de terceiros. Uma lista de materiais de software (SBOM) os relaciona para que, quando uma vulnerabilidade for anunciada, você saiba se é afetado (recursos de SBOM da CISA). A proveniência — evidência verificável de como e a partir de quê um artefato foi construído — protege contra compilações adulteradas; o framework SLSA define níveis de integridade da compilação, e as compilações reprodutíveis permitem que partes independentes confirmem que um binário corresponde ao seu código-fonte.

14.5 Versões para sistemas de vida longa

O software de TO pode ser mantido por vinte anos. Planeje: atualizações assinadas; reversão (rollback); implantação em etapas (bancada de teste, uma instalação, frota); janelas de compatibilidade; datas de fim de suporte publicadas com antecedência; e um processo de atualização que funcione quando uma instalação só é alcançável de forma intermitente. Um mecanismo de atualização é ele próprio uma superfície de ataque e precisa ser autenticado. No TMRP, o plano é concreto: o gateway passa da bancada para a PS2 e depois para a PS1, uma imagem de reversão é mantida em cada etapa, e as atualizações precisam chegar a estações que só são alcançáveis de forma intermitente pela LTE. Como os gateways estão registrados como dívida técnica com horizonte de três anos, a data de fim de suporte é publicada desde o início.

14.6 Exemplo resolvido: o projeto do gateway de telemetria (sintético)

O TMRP precisa construir um pequeno gateway que acrescente autenticação HMAC para as RTUs legadas da PS1 e da PS2. O plano: requisitos R1, R2 e R7 rastreados até os testes; um modelo de ameaças revisado por um segundo engenheiro; apenas a biblioteca padrão do Python, evitando dependências de terceiros; análise estática e testes unitários na integração contínua; compilações num executor dedicado, com artefatos assinados e um SBOM (trivialmente curto aqui); implantação numa bancada, depois na PS2, depois na PS1; e uma imagem de reversão mantida. Cada etapa deixa um registro no dossiê de evidências (Capítulo 48).

14.7 Atividade prática

Escreva um plano de uma página, mapeado ao SSDF, para uma pequena ferramenta que você tenha escrito: para cada um dos quatro grupos de práticas, liste duas práticas concretas e a evidência que cada uma produz. Escolha algo real que você tenha escrito, como o seu interpretador do Laboratório 3, para que as práticas sejam concretas. Para cada prática, nomeie a evidência que ela deixa: um registro de revisão, um relatório de teste, uma compilação assinada ou um modelo de aviso. Se uma prática não deixar nenhuma evidência, mude-a ou admita que ela é apenas uma intenção. Compare seu plano com o plano do gateway do TMRP e anote uma prática que você acrescentaria.

14.8 Erros comuns e limites

• Documentos de processo sem as práticas que eles descrevem.
• Revisão de código sem lista de verificação ou sem autoridade para bloquear.
• Dependências baixadas no momento da compilação sem fixação de versão nem proveniência.
• Mecanismos de atualização sem autenticação ou reversão.
• Nenhuma data de fim de suporte publicada.

O plano do gateway do TMRP foi escrito para evitar cada um desses erros. Ele usa apenas a biblioteca padrão, então não há dependências sem versão fixada; as revisões seguem uma lista de verificação; as compilações são assinadas, com um SBOM; a implantação mantém uma imagem de reversão; e os gateways têm um horizonte publicado de três anos.

Exercícios — capítulo 14

EX027 — Lista de verificação de revisão. Objetivo: criar uma lista de verificação de revisão para código de infraestrutura. Entradas: o código dos laboratórios 3 e 8. Passos: escreva uma lista de verificação de dez itens e aplique-a aos dois laboratórios, registrando uma constatação para cada um. Evidência esperada: lista de verificação e duas constatações. Rubrica: 3 = lista específica (validação de entradas, comparação em tempo constante, tratamento de chaves, caminhos de erro, registro em log, limites) e constatações reais; 2 = lista genérica; 1 = sem constatações; 0 = nada.

EX028 — Simulação de resposta com SBOM. Objetivo: usar um SBOM numa resposta a vulnerabilidade. Entradas: um SBOM sintético que lista libmodbus 3.1.6, openssl 3.0.8, zlib 1.2.13 para o firmware da RTU-B, e um aviso sobre um deles. Passos: descreva os passos de triagem, do aviso à decisão, incluindo como você determina a explorabilidade na sua implantação. Evidência esperada: procedimento. Rubrica: 3 = correspondência, análise de alcançabilidade, contato com o fornecedor, controle compensatório, comunicação; 2 = sem alcançabilidade; 1 = "atualizar tudo"; 0 = nada.

Síntese do capítulo

O processo torna os erros visíveis cedo e deixa evidências. Use um framework reconhecido de desenvolvimento seguro, revise com listas de verificação, meça a complexidade e trate as dependências e as compilações como parte da sua superfície de ataque, com SBOMs e proveniência. Projete versões e atualizações para décadas, com autenticação, implantação em etapas e reversão.