Recursos · 16
Garantia da cadeia de suprimentos de software: componentes para lançamento
Conecte componentes, procedência, builds, vulnerabilidades e atualizações a cada versão realmente implantada.
Atualizado · 3 min
O que este guia ajuda a alcançar
- Conheça as dependências realmente enviadas.
- Verifique a origem do artefato.
- Priorize falhas no contexto.
- Teste a substituição e o rollback.
Verificação rápida
- A lista de materiais corresponde à versão implantada?
- As dependências transitivas estão incluídas?
- Quem pode assinar uma versão?
- Uma vulnerabilidade é explorável em seu uso?
- Um componente crítico pode ser removido sem improvisação?
Método passo a passo
- 1
Mapeie as versões enviadas.
Identifique repositórios, dependências diretas e transitivas, ferramentas de compilação, imagens, serviços externos e proprietários. Conecte todos eles a uma versão verificável.
Entregável: mapa de produto, componente, versão e proprietário.
- 2
Produzir uma lista de materiais utilizável
Gerar uma lista de materiais para cada versão e compará-la com os artefatos efetivamente enviados. Resolver nomes incorretos, versões ausentes e componentes internos.
Entregável: lista de materiais datada e validada.
- 3
Proteger a compilação
Limitar os direitos de publicação, isolar estágios sensíveis e reter a proveniência, resumos e assinaturas. Verificar essas evidências antes da implantação.
Entregável: registro de compilação e política de verificação.
- 4
Triagem de alertas
Conectar cada notificação de vulnerabilidade ao componente, versão, exposição e uso real. Atribuir um responsável, prazo, decisão e evidências de encerramento.
Entregável: fila de triagem contextual.
- 5
Simular a alteração
Substituir um componente crítico em um ambiente de teste, verificar os fluxos de negócios e simular o rollback. Medir as dependências que bloqueiam a alteração.
Entregável: relatório de exercícios de substituição e contingência.
- 6
Manter evidências.
Revisar componentes e fornecedores em grandes lançamentos e após incidentes. Manter registros por um período que permita a investigação e correção.
Entregável: revisar o calendário e o histórico de lançamentos.
Indicadores de gestão
| Indicador | O que mede | Primeira ação |
|---|---|---|
| Cobertura do SBOM | Versões enviadas com inventário de componentes verificado | Resolver discrepâncias antes da publicação |
| Proveniência verificada | Artefatos verificados antes da implantação | Bloquear versões sem as evidências esperadas |
| Tempo de triagem | Tempo entre a notificação relevante e a decisão documentada | Escalar componentes expostos |
| Reversibilidade | Substituições críticas testadas com rollback | Remover dependências bloqueadoras |
Erros comuns
- Confundir inventário do repositório com componentes implantados
- Manter um SBOM sem atualizá-lo
- Classificar uma falha apenas pela pontuação
- Assinar um artefato sem verificar a proveniência da compilação
Perguntas frequentes
Um SBOM é suficiente?
Não. Ele ajuda a identificar componentes, mas a proveniência, a integridade, a exposição e a capacidade de atualização também precisam ser verificadas.
Toda vulnerabilidade deve bloquear uma versão?
Decida com base no uso real, exposição, controles compensatórios e criticidade para os negócios e registre o raciocínio.
Qual estrutura de referência ajuda?
A Estrutura de Desenvolvimento de Software Seguro do NIST oferece práticas de desenvolvimento seguro e proteção de software ao longo do ciclo de vida.
Referências oficiais
As referências apoiam o método. Adapte as verificações ao seu contexto; elas não são uma certificação. Os títulos das referências originais e os documentos de origem podem estar em outro idioma.
