Gestão do risco da cadeia de abastecimento de software

Gestão do risco vs segurança

A segurança da cadeia de abastecimento de software é o conjunto de controlos técnicos: SBOM, dependências fixadas, builds restringidos. A gestão do risco situa-se acima disso. Pergunta de que fornecedores e componentes depende o seu negócio, o que acontece se um deles falhar e se o seu esforço foi aplicado no sítio certo.

Quais são os riscos?

Risco	Exemplo	Controlo principal
Componentes vulneráveis	Uma falha numa biblioteca muito utilizada	SBOM e monitorização contínua
Componentes maliciosos	Um pacote sequestrado, ou typosquatting	Avaliação, adoção diferida, limites ao tráfego de saída
Projetos abandonados	Uma dependência com um único responsável pela manutenção, que entretanto seguiu outro caminho	Verificações de saúde e um plano de substituição
Risco de licenças	Um componente copyleft num produto proprietário	Política de licenças
Comprometimento do build	Uma GitHub Action sequestrada chega aos seus segredos	Fixação, isolamento, privilégio mínimo
Risco de fornecedores	O produto ou a atualização de um fornecedor é comprometido	Avaliação, contratos, SBOM dos fornecedores
Risco regulamentar	Um cliente ou uma lei exige evidências que não consegue produzir	Registos mantidos por versão

Um processo em seis passos

Construa o inventário. Liste os produtos que fabrica e o software que compra. Para o que compila, mantenha uma SBOM por versão. Não é possível avaliar o que não se vê.
Ordene pelo que importa. Uma biblioteca no seu serviço de pagamentos não é o mesmo que uma numa ferramenta interna. Classifique os produtos por exposição, dados e impacto no negócio.
Avalie os riscos. Analise as vulnerabilidades, a saúde dos projetos, as licenças e a forma como cada fornecedor trata a segurança. Faça-o em profundidade para o nível superior e de forma ligeira para tudo o resto.
Trate-os. Para cada risco, decida corrigir, substituir, acrescentar um controlo ou aceitar. Um risco aceite precisa de um responsável e de uma data de revisão.
Monitorize continuamente. O risco muda sem nenhuma alteração da sua parte, por exemplo quando é publicado um aviso de segurança ou um responsável pela manutenção sai. As revisões anuais não apanham isto.
Reporte. Dê à direção uma visão resumida: principais riscos, exposição ao longo do tempo e o que foi aceite. Clientes e auditores vão pedir o detalhe.

Avaliar fornecedores

Os questionários, por si só, dizem-lhe o que um fornecedor afirma. Peça coisas que mostrem o que faz:

Uma SBOM do produto, com um formato indicado e uma forma de obter atualizações
Como trata as vulnerabilidades e com que rapidez informa os clientes
Um contacto de segurança e uma política de divulgação
Como compila as versões e se consegue mostrar de onde veio uma versão
Durante quanto tempo uma versão recebe correções de segurança
Certificações e relatórios de auditoria que abranjam o produto que está a comprar

Inclua as expectativas nos contratos. É muito mais fácil exigir uma SBOM ou um prazo de notificação na assinatura do que depois de um incidente.

Referenciais a seguir

NIST SP 800-161 é a principal referência para a gestão do risco de cibersegurança da cadeia de abastecimento, ou C-SCRM. Aplica-se a todos os níveis de uma organização e integra o risco da cadeia de abastecimento na gestão do risco mais ampla.
O NIST SSDF cobre as práticas de desenvolvimento seguro, o que faz dele uma boa base para o que pede aos fornecedores e a si próprio.
O SLSA dá-lhe uma linguagem comum para exprimir o grau de confiança de um build.
A ISO/IEC 27001:2022 inclui controlos para a segurança da cadeia de abastecimento de TIC (Anexo A 5.21) e para vulnerabilidades técnicas (8.8). Não exige uma SBOM, mas as SBOM são boas evidências para esses controlos.
A NIS2 indica a segurança da cadeia de abastecimento como medida obrigatória para as entidades abrangidas, no artigo 21.º, n.º 2, alínea d).

Como medir

Escolha algumas métricas que conduzam a decisões:

Percentagem de produtos com SBOM da versão atual
Tempo para responder a «estamos afetados?» perante uma nova vulnerabilidade crítica
Janela de exposição: durante quanto tempo uma versão vulnerável esteve em produção
Percentagem de fornecedores de nível superior avaliados no último ano
Número de riscos aceites com a data de revisão ultrapassada

Onde o CRACI ajuda

O CRACI dá a um programa de risco os dados que normalmente lhe faltam sobre o software que a sua organização compila. Regista o que cada build de GitHub Actions trouxe, incluindo as licenças declaradas, em SBOM que pode conservar por versão e partilhar em CycloneDX ou SPDX. Monitoriza o que foi distribuído, mostra que builds continham um pacote vulnerável, para que veja o período em que esteve afetado, e pode aplicar a política de licenças e bloquear builds com policy gates. Consulte segurança da cadeia de abastecimento de software com o CRACI e como se comparam as ferramentas.

A avaliação de fornecedores e o seu registo de riscos ficam com as suas ferramentas de governação e com a sua equipa.

Gestão do risco da cadeia de abastecimento de software: perguntas frequentes

O que é a gestão do risco da cadeia de abastecimento de software?

É a forma como uma organização identifica, avalia e reduz o risco de software que não escreveu, incluindo pacotes open source, produtos comerciais, fornecedores de SaaS e ferramentas de build.

O que é C-SCRM?

C-SCRM significa cybersecurity supply chain risk management (gestão do risco de cibersegurança da cadeia de abastecimento), o termo usado pelo NIST. O NIST SP 800-161 é a sua principal orientação e explica como encontrar, avaliar e reduzir os riscos cibernéticos em toda a cadeia de abastecimento, a todos os níveis de uma organização.

Quais são os maiores riscos da cadeia de abastecimento de software?

Componentes open source vulneráveis e maliciosos, sistemas de build e ferramentas de CI comprometidos, projetos abandonados, problemas de licenças e fornecedores que sofrem violações de segurança.

Em que difere da gestão do risco de terceiros?

A gestão do risco de terceiros costuma olhar para os fornecedores enquanto empresas. A gestão do risco da cadeia de abastecimento de software desce até aos componentes e aos processos de build, incluindo projetos open source sem nenhum fornecedor por trás.

Quem é responsável por ela?

Normalmente, a direção de segurança ou de risco define o programa, a segurança de produto responde pelo que a empresa compila e as compras ou a gestão de fornecedores respondem pelo que a empresa adquire. As equipas de engenharia corrigem o que for encontrado.