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 código"]
  N2["14.3 Gestão de dependências"]
  N3["14.4 Integridade do build"]
  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 código"]
  N2["14.3 Gestão de dependências"]
  N3["14.4 Integridade do build"]
  N0 --> N1 --> N2 --> N3 --> Q["EX040"]

[14.1 Segurança no ciclo de vida]
    |
    v
[14.2 Revisão de código]
    |
    v
[14.3 Gestão de dependências]
    |
    v
[14.4 Integridade do build]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) integrar a segurança ao ciclo de vida do desenvolvimento; (2) usar uma revisão de código atenta às ameaças; (3) gerenciar vulnerabilidades nas dependências.

14.1 Segurança no ciclo de vida

Os desenvolvedores da Saltmarsh constroem um aplicativo para os motoristas registrarem as confirmações de entrega. Lindiwe aprende que a segurança acrescentada no fim é cara, enquanto a segurança considerada desde os requisitos é mais barata. Ela ajuda a escrever os requisitos de segurança: os motoristas se autenticam com suas próprias contas, as confirmações não podem ser alteradas depois de enviadas e os dados de localização são guardados apenas enquanto puderem surgir disputas. O Prof. Hale observa que requisitos claros dão aos testadores algo concreto para conferir, em vez de uma instrução vaga para tornar o aplicativo seguro. O dono do produto aceita os três requisitos.

14.2 Revisão de código

Lindiwe participa das revisões de código do aplicativo dos motoristas. Ela procura os padrões que aprendeu: consultas montadas com strings, segredos no código, ausência de validação de entradas e permissões conferidas apenas na interface do usuário. Numa mudança, o aplicativo esconde dos motoristas um botão de exclusão, mas o servidor aceita pedidos de exclusão de qualquer pessoa logada. Ela explica que toda verificação precisa acontecer no servidor, porque os atacantes não usam a interface oficial. O desenvolvedor corrige a verificação no servidor no mesmo dia e acrescenta um teste que envia um pedido de exclusão a partir de uma conta de motorista e espera uma recusa.

14.3 Gestão de dependências

O aplicativo dos motoristas usa dezenas de bibliotecas de código aberto. Lindiwe monta uma lista das dependências com as versões e a confere toda semana contra bases públicas de vulnerabilidades. Uma biblioteca tem uma falha conhecida que permite negação de serviço, e existe uma atualização. Os desenvolvedores a atualizam depois de executar seus testes. Ela aprende que a maior parte do código das aplicações é emprestada, então saber o que está incluído é essencial, e que uma lista de dependências é em si um registro de segurança. A verificação semanal leva poucos minutos e roda automaticamente no servidor de build, enviando os resultados ao canal da equipe.

14.4 Integridade do build

O código é transformado em pacotes instaláveis por um servidor de build. Se um atacante alterar o build, todos os usuários recebem software malicioso. Lindiwe recomenda que os builds rodem a partir de scripts sob controle de versão, que os servidores de build sejam isolados e que os pacotes sejam assinados com uma chave protegida. O Prof. Hale liga isso à recomendação anterior dela sobre a chave de assinatura de código. Ela aprende que o caminho do código-fonte até o dispositivo do usuário faz parte da superfície de ataque e precisa ser protegido. O líder de desenvolvimento acrescenta essas etapas ao roteiro.

Exemplo resolvido

Lindiwe escreve requisitos de segurança para um aplicativo de motoristas, encontra na revisão uma lacuna de autorização no servidor, acompanha as dependências semanalmente e recomenda um pipeline de build protegido.

Caso sintético. O aplicativo é sintético.

Erros e limites

Esconder um botão na interface não impede os pedidos ao servidor.

Exercícios

• EX040 — Falha da exclusão. Que falha a revisão de código encontra?

  Mostrar critérios de avaliação

  Rubrica: 3 = o servidor aceita pedidos de exclusão de qualquer pessoa logada;; 2 = parcialmente correto;; 1 = vago;; 0 = nenhuma.

• EX041 — Verificação das dependências. Com que frequência as dependências são conferidas?

  Mostrar critérios de avaliação

  Rubrica: 3 = semanalmente;; 2 = parcialmente correto;; 1 = errado;; 0 = nenhuma.

• EX042 — Proteção do build. Cite uma proteção do build que ela recomenda.

  Mostrar critérios de avaliação

  Rubrica: 3 = pacotes assinados;; 2 = uma;; 1 = vago;; 0 = nenhuma.