Capítulo 14 — Engenharia de software | Engenharia Inteligência de ameaças e OSINT

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Controle de versão e revisão"]
  N1["14.2 Integração contínua"]
  N2["14.3 Dependências"]
  N3["14.4 Rastreabilidade"]
  N4["14.5 Configuração"]
  N5["Nota de prática — Notas de versão"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Controle de versão e revisão"]
  N1["14.2 Integração contínua"]
  N2["14.3 Dependências"]
  N3["14.4 Rastreabilidade"]
  N4["14.5 Configuração"]
  N5["Nota de prática — Notas de versão"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX040"]

[14.1 Controle de versão e revisão]
    |
    v
[14.2 Integração contínua]
    |
    v
[14.3 Dependências]
    |
    v
[14.4 Rastreabilidade]
    |
    v
[14.5 Configuração]
    |
    v
[Nota de prática — Notas de versão]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) aplicar controle de versão, revisão de código e integração contínua a uma plataforma de CTI; (2) gerenciar dependências com cuidado de cadeia de suprimentos; (3) escrever registros de mudança ligados aos requisitos; (4) separar a configuração do código.

14.1 Controle de versão e revisão

Toda mudança no Lantern passa por um branch, uma execução automática de testes e a revisão de um segundo engenheiro. Mudanças em parsers precisam de um revisor que entenda o formato do parceiro. Revisar é mais do que ler código. O revisor roda os testes, verifica se a mudança corresponde ao que foi pedido e pergunta o que acontece com entradas ruins. Nas mudanças de parser, uma amostra de registros reais de parceiros, coberta pelo acordo, passa pelas duas versões. Kofi já viu revisões detectarem um campo lido da posição errada, que os testes com dados sintéticos limpos tinham deixado passar.

14.2 Integração contínua

A CI roda testes unitários, testes de propriedades e uma reprodução de um feed sintético pelo pipeline inteiro, comparando as saídas com um snapshot sabidamente bom. Uma diferença faz o build falhar até ser explicada. Foi a reprodução que tornou visível a mudança do exemplo resolvido: o snapshot mostrou exatamente quantos indicadores continuariam no bloqueio: 1.240 a mais quando o piso de decaimento caiu de 30 para 20. Uma reprodução que falha nem sempre é um bug. Às vezes a mudança é intencional, e o engenheiro atualiza o snapshot com uma nota explicando o porquê.

14.3 Dependências

Bibliotecas de terceiros podem trazer vulnerabilidades ou estar comprometidas. Fixe as versões, revise as atualizações e prefira a biblioteca padrão para tarefas pequenas. A técnica T1195 Supply Chain Compromise do ATT&CK lembra aos defensores que suas próprias ferramentas são um alvo. A regra de Kofi é que cada nova biblioteca precisa de um motivo que a biblioteca padrão não atenda, de um responsável nomeado e de uma verificação de seus mantenedores e de seu histórico recente. As atualizações chegam em um lote semanal, lido antes do merge, e o build falha se uma dependência for obtida sem versão e hash fixos. O Lantern guarda dados de parceiros e influencia firewalls, o que faz de uma biblioteca comprometida em seu build uma rota atraente para um atacante.

14.4 Rastreabilidade

Cada mudança cita o requisito ou o defeito que trata. Quando um auditor pergunta por que o portão de TLP permite AMBER para "org", o histórico leva ao requisito e à definição do TLP 2.0. Kofi liga cada commit a um ticket, e cada ticket a um número de requisito no documento de requisitos. Um auditor consegue seguir a cadeia do código até o motivo dele em poucos cliques. Mudanças sem um motivo vinculado não entram no merge. Isso também ajuda na remoção de código: se o requisito foi retirado, o vínculo mostra quais partes podem sair.

14.5 Configuração

Os endpoints dos parceiros, as referências a credenciais e os limiares ficam na configuração, e não no código. Os segredos ficam em um cofre; a configuração guarda apenas referências. Separá-los significa que o mesmo código testado pode rodar em teste e em produção com configurações diferentes, e que mudar um limiar não exige um novo build. As mudanças de configuração também passam por revisão, porque um limiar errado pode causar tanto dano quanto um bug. Kofi mantém, ao lado de cada configuração, uma descrição curta do que ela controla e de quem pode alterá-la. Uma credencial nunca é colada na configuração, nem temporariamente; a referência ao cofre é a única coisa armazenada.

Nota de prática — Notas de versão

Cada versão do Lantern sai com notas escritas para os analistas: que comportamento mudou, quais limiares se moveram e como relatar problemas. Analistas que entendem uma mudança têm menos chance de confundir o novo comportamento com um incidente, e relatam regressões mais depressa.

Exemplo resolvido

Um pull request baixa o piso de decaimento de 30 para 20. A reprodução da CI mostra que mais 1.240 indicadores permaneceriam no bloqueio automatizado. O revisor pede o requisito; não existe nenhum. A mudança é rejeitada até que o líder do SOC concorde e um requisito seja escrito.

Caso sintético. O pull request e as contagens são inventados.

Erros e limites

Testes com dados sintéticos não provam o comportamento sobre todos os dados dos parceiros; continue amostrando formatos reais sob o acordo. A pressa é a inimiga habitual da revisão.

Exercícios

EX040 — Valor da reprodução. O que a reprodução de feed sintético na CI detecta que os testes unitários podem deixar passar?
Mostrar critérios de avaliação
Rubrica: 3 = mudanças de comportamento de ponta a ponta entre as etapas; 2 = bugs de integração, de forma vaga; 1 = vago; 0 = nenhuma.
EX041 — Mudança rejeitada. Por que a mudança do piso de decaimento foi rejeitada?
Mostrar critérios de avaliação
Rubrica: 3 = sem requisito/acordo do responsável; grande impacto no comportamento; 2 = um; 1 = os testes falharam; 0 = nenhuma.
EX042 — Local dos segredos. Onde ficam as credenciais dos parceiros, e o que a configuração guarda?
Mostrar critérios de avaliação
Rubrica: 3 = cofre; a configuração guarda referências; 2 = só o cofre; 1 = no código; 0 = nenhuma.

Síntese

Revise, reproduza, fixe versões, rastreie e mantenha os segredos fora do código.

Continue estudando — capítulo 14 de 50

← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →