O código que ninguém escreveu
Uma aplicação moderna pode ter uns poucos milhares de linhas próprias e centenas de milhares de linhas de dependências: bibliotecas, frameworks, imagens de sistema operativo. Cada uma pode ter vulnerabilidades conhecidas, e algumas podem ter sido manipuladas de propósito antes de chegar.
Revisar o código próprio é necessário. Ignorar tudo o resto deixa aberta a maior parte da superfície.
O que contém cada artefacto
A prática que o resolve apoia-se na própria construção, que já é uma porta de aprovação (como em que falhe a construção, não a produção):
- Lista de componentes. Cada construção gera um inventário de tudo o que o artefacto contém (o que se costuma chamar SBOM): cada biblioteca, com a sua versão.
- Análise de vulnerabilidades. Esse inventário cruza-se com as bases de vulnerabilidades conhecidas. O crítico detém a construção; o restante registra-se com prazo.
- Versões fixadas. As dependências fixam-se a versões concretas, para que a construção de hoje e a de amanhã contenham o mesmo.
- Assinatura do artefacto. O que se publica vai assinado, e a implementação só aceita artefactos assinados pela própria construção. Encaixa com implementar por digest: a impressão digital diz o que é; a assinatura diz quem o fez.
O que vem depois da implementação
Uma dependência sem vulnerabilidades hoje pode tê-las amanhã, quando se descobre uma nova. Como cada artefacto em produção tem a sua lista de componentes guardada, responder a «estamos afetados por esta vulnerabilidade?» é uma consulta de minutos, não uma busca de dias por todos os repositórios.
Também os segredos e a configuração
O código que se publica não deve levar dentro credenciais (vimo-lo em segredos com nome, nunca com valor), e a configuração de infraestrutura analisa-se tal como o código da aplicação, com regras como código.
Com o software sob controlo, falta proteger o que mais importa no fim: os dados.
Como o aplicamos: Cibersegurança.