Capítulo 14 — Engenharia de software

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Requisitos no ciclo de vida"]
  N1["14.2 Gerenciar dependências"]
  N2["14.3 Revisar em busca de uso indevido"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Requisitos no ciclo de vida"]
  N1["14.2 Gerenciar dependências"]
  N2["14.3 Revisar em busca de uso indevido"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX040"]

[14.1 Requisitos no ciclo de vida]
    |
    v
[14.2 Gerenciar dependências]
    |
    v
[14.3 Revisar em busca de uso indevido]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) integrar requisitos criptográficos ao ciclo de vida de desenvolvimento; (2) gerenciar dependências de bibliotecas criptográficas; (3) revisar código em busca de usos indevidos comuns.

14.1 Requisitos no ciclo de vida

Aiyana entra na equipe de software da Ridgeway e descobre que, em projetos anteriores, a criptografia foi acrescentada tarde, o que causou retrabalho. Ela propõe que os requisitos de segurança, como "toda leitura é autenticada com uma chave por medidor" e "o firmware só é aceito com uma assinatura válida", apareçam no backlog desde o início, cada um com um teste de aceitação. Tratar as propriedades criptográficas como requisitos testáveis, e não como uma revisão final, torna-as visíveis no planejamento e nas estimativas e deixa claro qual equipe é dona de cada propriedade.

14.2 Gerenciar dependências

A Ridgeway depende de algumas bibliotecas criptográficas. Aiyana registra a versão, a origem e os mantenedores de cada biblioteca e se inscreve nos seus avisos de segurança. Ela fixa as versões para que os builds sejam reproduzíveis, mas agenda atualizações regulares, porque as bibliotecas criptográficas corrigem vulnerabilidades com frequência. Ela também confere se os pacotes baixados coincidem com os hashes ou as assinaturas publicados, para evitar dependências adulteradas. A equipe concorda em nunca copiar código criptográfico de fóruns para a base de código; se faltar uma função, eles procuram uma biblioteca mantida ou levam o assunto à revisão de projeto.

14.3 Revisar em busca de uso indevido

Aiyana escreve um checklist curto de revisão: nenhuma chave embutida no código; segredos vindos do módulo secrets; nenhum modo ECB nem cifração não autenticada; nonces nunca reutilizados sob uma mesma chave; tags comparadas com hmac.compare_digest; senhas com hash Argon2id; verificação do TLS nunca desativada. Os revisores marcam cada item nas mudanças que tocam a criptografia. No primeiro mês, o checklist pega um auxiliar de testes que desativava a verificação de certificados e estava prestes a ser reutilizado em código de produção. Checklists não substituem a especialização, mas pegam erros comuns de forma confiável.

Exemplo resolvido

Aiyana acrescenta requisitos criptográficos testáveis ao backlog, fixa e monitora as bibliotecas e introduz um checklist de revisão com sete itens que pega uma verificação de TLS desativada.

Caso sintético. A equipe e o incidente são inventados.

Erros e limites

Checklists podem virar mera formalidade; os revisores precisam entender cada item. Fixar versões sem atualizá-las mantém vulnerabilidades conhecidas.

Exercícios

• EX040 — Requisito testável. Dê um exemplo de requisito criptográfico escrito como item de backlog.

  Mostrar critérios de avaliação

  Rubrica: 3 = toda leitura autenticada com uma chave por medidor (ou firmware aceito apenas com assinatura válida), com teste de aceitação;; 2 = exemplo sem teste;; 1 = vago;; 0 = nenhuma.

• EX041 — Regra de dependências. O que a equipe combinou sobre código de fóruns?

  Mostrar critérios de avaliação

  Rubrica: 3 = nunca copiar código criptográfico de fóruns; usar uma biblioteca mantida ou levar à revisão de projeto;; 2 = evitar;; 1 = permitido;; 0 = nenhuma.

• EX042 — O que o checklist pegou. O que o checklist pegou no primeiro mês?

  Mostrar critérios de avaliação

  Rubrica: 3 = um auxiliar de testes que desativava a verificação de certificados e estava prestes a entrar em produção;; 2 = problema de TLS;; 1 = vago;; 0 = nenhuma.

Síntese

A criptografia se torna confiável quando é um requisito testado, suas bibliotecas são gerenciadas ativamente e as revisões procuram usos indevidos conhecidos.