Capítulo 14 — Engenharia de software

Capítulo 14 — Engenharia de software

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Segurança no ciclo de vida"]
  N1["14.2 Revisão de projeto leve"]
  N2["14.3 Revisões e automação"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Segurança no ciclo de vida"]
  N1["14.2 Revisão de projeto leve"]
  N2["14.3 Revisões e automação"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX040"]

[14.1 Segurança no ciclo de vida]
    |
    v
[14.2 Revisão de projeto leve]
    |
    v
[14.3 Revisões e automação]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) integrar atividades de segurança a um ciclo de vida de desenvolvimento; (2) conduzir uma revisão de projeto leve; (3) usar com eficácia a revisão de código e as verificações automatizadas.

14.1 Segurança no ciclo de vida

Sofia entra por um semestre numa equipe da Corvia que constrói um novo serviço de reembolso de passagens. O ciclo de vida da equipe tem requisitos, projeto, implementação, testes, release e manutenção. Daniel lhe mostra onde a segurança se encaixa: casos de abuso junto com os requisitos, modelagem de ameaças no projeto, codificação segura e revisão durante a implementação, testes de segurança antes do release e resposta a vulnerabilidades depois dele. O NIST SP 800-218 organiza essas práticas em grupos: preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades. Integrar a segurança a cada fase custa menos do que tentar acrescentá-la no fim.

14.2 Revisão de projeto leve

Antes de começar a codificação, a equipe faz uma revisão de projeto de uma hora. Eles desenham um diagrama de fluxo de dados do serviço de reembolso, marcam as fronteiras de confiança e passam cada elemento pelas categorias STRIDE, como Shostack (2014) descreve. Descobrem que as solicitações de reembolso poderiam ser repetidas (replay) para obter reembolsos em dobro, e que a equipe de suporte poderia aprovar as próprias solicitações de reembolso. As mitigações são registradas: identificadores únicos de solicitação verificados no servidor e uma regra de que o aprovador deve ser diferente do solicitante. Sofia observa que uma hora encontrou dois problemas sérios que teriam sido caros de corrigir depois do release.

14.3 Revisões e automação

Durante a implementação, toda mudança é revisada por outro engenheiro usando um checklist curto: validação de entrada, verificações de autorização, tratamento de erros e logging. Verificações automatizadas rodam análise estática e varredura de dependências a cada commit. Sofia aprende que as ferramentas captam padrões comuns, mas deixam passar falhas de projeto como o problema da autoaprovação, enquanto as pessoas se cansam de verificações repetitivas que as ferramentas fazem bem. Combinar as duas coisas é eficiente. A equipe acompanha os achados até o fechamento e examina todo achado que as ferramentas deixaram passar para melhorar o checklist, um ciclo de feedback que melhora o próprio processo.

Exemplo resolvido

Sofia relaciona os grupos de práticas do SP 800-218 ao projeto de reembolso, participa de uma revisão STRIDE que encontra problemas de replay e de autoaprovação e ajuda a refinar o checklist de revisão.

Caso sintético. O serviço de reembolso e os achados são sintéticos; o SP 800-218 e Shostack (2014) são reais.

Erros e limites

Revisões leves deixam passar problemas fora do diagrama. As ferramentas produzem falsos positivos que as equipes aprendem a ignorar se não forem ajustadas.

Exercícios

• EX040 — Grupos do SP 800-218. Cite os quatro grupos de práticas do SP 800-218. Rubrica: 3 = preparar a organização, proteger o software, produzir software bem protegido, responder a vulnerabilidades;; 2 = três;; 1 = um;; 0 = nenhuma.

• EX041 — Achados do reembolso. Que dois problemas a revisão de projeto encontrou? Rubrica: 3 = replay de solicitações de reembolso e autoaprovação pela equipe de suporte;; 2 = os dois;; 1 = um;; 0 = nenhuma.

• EX042 — Ferramentas versus pessoas. Que tipo de falha as ferramentas costumam deixar passar? Rubrica: 3 = falhas de projeto, como a lógica de autoaprovação;; 2 = falhas de projeto;; 1 = sintaxe;; 0 = nenhuma.

Síntese

A segurança cabe em todas as fases do ciclo de vida, com revisões de desenho curtas e verificações humanas e automatizadas combinadas detectando falhas diferentes.

Continue estudando — aula 14 (capítulo 14 de 50)

← Capítulo 13 · Índice das aulas · Capítulo 15 →

Continue para a próxima aula já escrita.