SBOM como evidência de conformidade: ISO 27001, SOC 2 e NIS2

Evidência não é conformidade

Um controlo é cumprido por um processo que funciona. A evidência mostra que funciona. Uma SBOM mostra uma coisa específica: o que uma determinada versão continha. Nada mostra sobre controlo de acessos, resposta a incidentes ou se alguém agiu perante uma constatação.

Também pode estar errada sem que ninguém repare. Um gerador que leu os ficheiros errados produz uma SBOM válida que omite metade do produto. A análise de vulnerabilidades dessa SBOM sai limpa, a plataforma de conformidade vê que foi feita uma análise e todas as verificações ficam a verde. O que uma verificação de SBOM SOC 2 a verde confirma analisa essa falha em pormenor.

A evidência de uma SBOM conta quando:

1. Está ligada a uma versão. Uma SBOM por cada versão distribuída, não uma para o repositório.
2. Está completa, ou diz o que omitiu. Uma SBOM que declara as suas lacunas é de confiança para o que indica.
3. É guardada durante o período que a auditoria abrange. Um auditor que recolhe uma amostra de março do ano passado precisa da SBOM de março do ano passado.
4. É reavaliada quando surgem novas vulnerabilidades. Uma lista que ninguém compara com novos avisos de segurança prova pouco sobre a gestão de vulnerabilidades.

Para saber o que contém uma SBOM, consulte o que é uma SBOM. Para os frameworks de desenvolvimento seguro de produtos industriais e de software federal dos EUA, consulte IEC 62443-4-1 e NIST SSDF.

ISO/IEC 27001:2022

A ISO/IEC 27001 é a norma face à qual se certifica um sistema de gestão de segurança da informação (glossário). O Anexo A enumera 93 controlos; a organização seleciona os que a sua avaliação de risco exige e regista-os na sua Declaração de Aplicabilidade. A ISO/IEC 27002:2022 dá as orientações de implementação. Nenhuma das duas menciona SBOM. A tabela cita apenas os títulos (em inglês) dos controlos e diz em poucas palavras do que trata cada um.

Controlo	Do que trata	Como uma SBOM ou um registo do build serve de evidência	O que não cobre
5.9 "Inventory of information and other associated assets"	Saber que ativos tem e quem é o seu responsável	O software que distribui e executa é um ativo. Uma lista de componentes por versão é o inventário do que está dentro dele.	Hardware, dados, pessoas e serviços
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	Gerir o risco associado aos fornecedores e à cadeia de abastecimento de TIC	Em dois sentidos. Como comprador, pode exigir SBOM aos fornecedores e monitorizá-las. Como fornecedor, a sua SBOM é o que o processo de cadeia de abastecimento do seu cliente certificado lhe pede. Os componentes open source fazem parte da cadeia de abastecimento de TIC mas não vêm com acordo de fornecimento, e é precisamente por isso que um inventário deles importa.	Contratos, avaliações e revisões de fornecedores
8.8 "Management of technical vulnerabilities"	Obter informação sobre vulnerabilidades, avaliar a exposição e agir em conformidade	Uma lista de componentes atual, comparada com avisos de segurança e reavaliada quando surgem novos, mais um registo das versões que continham uma versão vulnerável e desde quando	A aplicação de correções na infraestrutura, a análise de hosts e as próprias decisões
8.25 "Secure development life cycle"	Regras para desenvolver software e sistemas de forma segura	Um processo de lançamento registado e repetível: cada versão compilada no mesmo pipeline, com a sua SBOM	A maior parte do controlo: formação, ambientes, conceção e revisão
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Requisitos, conceção e código	Não diretamente. Estes tratam do que escreve, não do que incorpora.	Tudo: revisão de código, SAST e registos de conceção são aqui a evidência
8.29 "Security testing in development and acceptance"	Testar a segurança antes do lançamento	Uma policy gate que bloqueia um build perante uma vulnerabilidade é um teste registado com um resultado	Testes funcionais de segurança, testes de intrusão
8.30 "Outsourced development"	Orientar e monitorizar o desenvolvimento subcontratado	O código subcontratado compilado no seu pipeline recebe a mesma SBOM e as mesmas verificações que o seu	O contrato, as práticas próprias do fornecedor

Seja honesto quanto aos controlos 8.25 a 8.30: a maior parte do que pedem está fora de uma SBOM. Reivindicar mais é a forma mais rápida de perder a confiança do auditor em tudo o resto.

Exemplo prático: um auditor pergunta pelo 8.8

"Como sabem quando uma nova vulnerabilidade afeta um produto que já distribuíram?" Eis a cadeia de evidências para um aviso de segurança, e quem fornece cada elo.

Passo	Evidência	Origem
1. O conteúdo da versão	A SBOM da versão 4.2, registada pelo build que a produziu	As suas ferramentas de build
2. A correspondência com o aviso	Uma nova CVE publicada para uma biblioteca dessa SBOM, associada pelo seu package URL	A sua monitorização de vulnerabilidades
3. A janela de exposição	Todos os builds que continham a versão vulnerável, e a data do primeiro	O seu histórico de builds
4. A decisão	Quem a avaliou, quando, e o resultado: corrigir, mitigar ou não afetado, com o motivo	O seu processo e os respetivos registos
5. A correção	A versão 4.2.1, cuja SBOM já não contém a versão vulnerável	As suas ferramentas de build

As ferramentas podem fornecer os passos 1, 2, 3 e 5. O passo 4 é o seu processo, e é o passo que os auditores leem com mais atenção.

SOC 2

Um relatório SOC 2 declara se os controlos cumprem os Trust Services Criteria do AICPA (2017, com pontos de foco revistos em 2022). Os critérios são declarações de resultados. Não mencionam SBOM, e em dois deles as SBOM ajudam.

• CC7.1 pede que a entidade "uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities". Evidência: uma SBOM por versão, reavaliada face a novos avisos de segurança, e um registo de como cada constatação foi tratada.
• CC8.1 abrange a gestão de alterações: como as alterações à infraestrutura, aos dados, ao software e aos procedimentos são autorizadas, desenvolvidas ou adquiridas, testadas, aprovadas e implementadas. Evidência: cada versão compilada num pipeline registado, a alteração das dependências visível de um build para o seguinte, e policy gates como controlo sobre o que pode ser distribuído.

Os critérios estão em revisão. Em outubro de 2026, o AICPA publicou um exposure draft dos Trust Services Criteria de 2027, com uma reestruturação direcionada dos critérios, comentários até 15 de janeiro de 2027 e uma data de entrada em vigor proposta para trabalhos iniciados a 31 de dezembro de 2027 ou depois. É um rascunho, e a numeração dos critérios pode mudar: confirme o texto final antes de associar evidências aos novos números.

Se já utiliza uma plataforma SOC 2, mantenha-a. A questão é o que mostra a SBOM por trás das suas verificações: verificações de SBOM SOC 2 comparadas.

NIS2

A Diretiva SRI 2 (UE) 2022/2555 aplica-se a entidades essenciais e importantes dos setores que enumera. Se lê isto como fornecedor de software ou de dispositivos, normalmente não está abrangido. O seu cliente está, e as obrigações dele chegam-lhe sob a forma de perguntas. O artigo 21.º estabelece as medidas de gestão dos riscos de cibersegurança, e três passagens dão origem à maioria dessas perguntas:

• Artigo 21.º, n.º 2, alínea d): a segurança da cadeia de abastecimento, incluindo os aspetos de segurança das relações entre cada entidade e os seus fornecedores ou prestadores de serviços diretos.
• Artigo 21.º, n.º 2, alínea e): a segurança na aquisição, no desenvolvimento e na manutenção de redes e sistemas de informação, incluindo o tratamento e a divulgação de vulnerabilidades.
• Artigo 21.º, n.º 3: as entidades têm de ter em conta as vulnerabilidades específicas de cada fornecedor e prestador de serviços direto e a qualidade global dos produtos e das práticas de cibersegurança dos seus fornecedores e prestadores de serviços, incluindo os seus procedimentos de desenvolvimento seguro. É esta a frase que se transforma num questionário em cima da sua secretária.

Regulamento de Execução (UE) 2024/2690

O Regulamento de Execução (UE) 2024/2690 da Comissão, de 17 de outubro de 2024, estabelece os requisitos técnicos e metodológicos das medidas do artigo 21.º, n.º 2, para prestadores de serviços de DNS, registos de nomes de domínio de topo, prestadores de serviços de computação em nuvem, prestadores de serviços de centros de dados, fornecedores de redes de distribuição de conteúdos, prestadores de serviços geridos, prestadores de serviços de segurança geridos, mercados em linha, motores de pesquisa em linha, plataformas de serviços de redes sociais e prestadores de serviços de confiança. Não vincula os outros setores da NIS2, mas é a descrição pública mais detalhada do que significa segurança da cadeia de abastecimento, e outros compradores inspiram-se nela. Os pontos que chegam aos fornecedores:

Ponto do Anexo	O que diz	O que se pergunta ao fornecedor
5.1.2(a)	A seleção de fornecedores tem em conta as práticas de cibersegurança dos fornecedores e prestadores de serviços, incluindo os seus procedimentos de desenvolvimento seguro	Como desenvolve de forma segura, e como sabe o que entra no seu produto?
5.1.4(e) e (f)	Os contratos especificam, quando adequado, o direito de auditar ou de receber relatórios de auditoria, e a obrigação de os fornecedores e prestadores de serviços tratarem as vulnerabilidades que representem um risco para a entidade	Vai tratar as vulnerabilidades do que entrega, e podemos ver a evidência?
5.2	Um registo dos fornecedores diretos, com uma lista dos produtos, serviços e processos de TIC que cada um fornece	Que produtos e versões nos fornece?
6.1.2(c)	Na aquisição de serviços ou produtos de TIC: informação que descreva os componentes de hardware e software utilizados nesses serviços ou produtos de TIC	Que componentes de hardware e software contém o seu produto? É o mais perto que qualquer texto desta página chega de uma SBOM, e mesmo assim não a menciona.
6.10	Tratamento de vulnerabilidades: monitorizar a informação sobre vulnerabilidades através de canais como os anúncios das CSIRT ou a informação prestada por fornecedores ou prestadores de serviços (6.10.2(a)) e, quando uma vulnerabilidade não precisa de correção, documentar e fundamentar o motivo (6.10.3)	Como nos vai informar sobre vulnerabilidades, e porque é que esta não é um problema?

O último ponto descreve uma declaração de não afetado com o respetivo motivo. É isso que um documento VEX transporta, embora o regulamento não indique um formato.

Exemplo prático: um questionário de um cliente sujeito à NIS2

Cinco perguntas do tipo que um cliente deriva desses pontos, com a evidência que um fornecedor pode anexar. Algumas respostas vêm de registos que as suas ferramentas mantêm; outras são políticas que redige.

Pergunta	Evidência a anexar	Registo ou política
"Indique os componentes de software da versão do produto que nos entrega." (6.1.2(c))	A SBOM dessa versão, em CycloneDX ou SPDX, com a completude declarada	Registo
"Descreva o seu tratamento de vulnerabilidades e os respetivos prazos." (5.1.4(f))	O seu procedimento de tratamento de vulnerabilidades, com níveis de gravidade e tempos-alvo	Política
"Quais das versões que utilizamos continham a biblioteca vulnerável, e desde quando?" (6.10)	O histórico de builds com todos os builds que continham o componente, com datas	Registo
"Porque é que esta CVE não nos afeta?" (6.10)	Uma declaração de não afetado com a justificação, como "o código vulnerável não está presente"	Registo, com base na sua avaliação
"Como podem os investigadores comunicar vulnerabilidades nos seus produtos?" (5.1.2(a))	A sua política de divulgação coordenada de vulnerabilidades	Política

Uma distinção a manter: para produtos com elementos digitais vendidos na UE, o Cyber Resilience Act exige de facto uma SBOM. A NIS2 não.

DORA, se vende a entidades financeiras

O Digital Operational Resilience Act, Regulamento (UE) 2022/2554, aplica-se às entidades financeiras, não diretamente aos seus fornecedores. As entidades financeiras têm de identificar e documentar os seus ativos de TIC e as respetivas interdependências e manter inventários dos mesmos (artigo 8.º, n.os 1, 4 e 6), gerir o risco de terceiros no domínio das TIC como parte do seu risco de TIC (artigo 28.º, n.º 1), manter um registo de informação sobre todos os seus contratos de serviços de TIC (artigo 28.º, n.º 3) e incluir disposições mínimas nesses contratos (artigo 30.º). O DORA não menciona SBOM. Para um fornecedor de software a um banco, uma lista de componentes por versão ajuda o cliente a cumprir o artigo 8.º.

Um único mapa de evidências para todos

As linhas são evidências; cada célula indica o controlo, critério ou ponto que suportam, ou "não diretamente".

Evidência	ISO/IEC 27001:2022	SOC 2	NIS2 e 2024/2690	DORA
1. Uma SBOM por versão, com a completude declarada	5.9, 5.21, 8.8	CC7.1	Art. 21.º(2)(d); 6.1.2(c)	Art. 8.º (o inventário do cliente)
2. Reavaliação contínua face a novos avisos de segurança	8.8	CC7.1	Art. 21.º(2)(e); 6.10	Não diretamente
3. Histórico de builds: que versões continham um componente, e desde quando	8.8	CC7.1, CC8.1	6.10	Não diretamente
4. Registos de triagem e encaminhamento	8.8	CC7.1	Art. 21.º(2)(e); 6.10	Não diretamente
5. Declarações de não afetado com motivos	8.8	CC7.1	6.10	Não diretamente
6. Policy gates que bloqueiam um build	8.25, 8.29	CC8.1	Art. 21.º(2)(e)	Não diretamente
7. SBOM de fornecedores monitorizadas juntamente com as suas	5.19, 5.21, 5.22	CC7.1	Art. 21.º(2)(d), 21.º(3); 5.2, 6.10	Art. 28.º(1)
8. Política de egress e registos de rede do build	8.25	CC8.1	Art. 21.º(2)(d)	Não diretamente

O que uma SBOM não prova

• O seu controlo de acessos, resposta a incidentes, continuidade do negócio, segurança dos recursos humanos, criptografia ou segurança física.
• Que alguém corrigiu alguma coisa. Isso é o seu processo, e os respetivos registos.
• Que o seu próprio código não tem falhas. A revisão de código, o SAST e os testes são a evidência disso.
• O que está dentro de binários recebidos sem SBOM.
• Que está certificado. Uma SBOM não é um certificado, e um certificado detido pelo fornecedor da sua ferramenta certifica o sistema de gestão desse fornecedor, não o seu.

Onde entra o CRACI

O CRACI substitui os seus runners alojados pelo GitHub e regista o que cada build trouxe, pelo que a SBOM vem do próprio build da versão, com um estado de completude para cada job.

• As SBOM monitorizadas são reavaliadas continuamente à medida que são publicadas novas vulnerabilidades (acompanhamento de vulnerabilidades).
• O histórico de builds mostra que builds continham uma dependência vulnerável, e portanto o período de exposição, dentro do seu período de retenção. Se a sua auditoria abrange um período mais longo, exporte a SBOM de cada versão e guarde-a com a versão.
• As equipas de segurança fazem a triagem das vulnerabilidades encontradas e encaminham-nas para as equipas responsáveis pela correção, e o CRACI suporta VEX para registar que produtos uma vulnerabilidade não afeta.
• As policy gates podem bloquear um build perante constatações, incluindo um build que contenha uma CVE específica.
• É possível adicionar SBOM de terceiros, para que os componentes comprados sejam monitorizados juntamente com os seus próprios builds.
• As SBOM exportam como CycloneDX ou SPDX, e a API devolve SBOM, rastos de rede e dados de proveniência. A política de egress regista e limita os destinos a que cada build se pode ligar.

O CRACI fornece evidência para estes controlos. Não torna a sua organização conforme com a ISO 27001 ou o SOC 2 nem a prepara para a NIS2, e não é uma plataforma de automatização da conformidade. O certificado próprio do CRACI é um facto distinto: o sistema de gestão de segurança da informação do CRACI Corporation Oy para o desenvolvimento e a operação da plataforma CRACI está certificado segundo a ISO/IEC 27001, emitido pela Into Certification. Abrange a forma como o CRACI opera o seu serviço, não a sua organização nem os seus produtos. Consulte segurança no CRACI e como funciona o CRACI para a plataforma completa.

Quando o CRACI não é a resposta

• Os seus builds não correm no GitHub Actions. É o único CI que o CRACI suporta hoje; outros sistemas de CI estão no roadmap.
• Precisa de uma plataforma de automatização da conformidade para políticas, revisões de acessos e fluxo de trabalho com o auditor. Mantenha ou adquira uma; consulte verificações de SBOM SOC 2 comparadas.
• A sua lacuna de evidência é sobretudo organizacional: políticas, formação, resposta a incidentes.
• O seu principal risco de fornecedores são binários recebidos sem SBOM. A análise binária responde a isso.

Está a responder ao pedido de um cliente? Consulte como responder a um pedido de SBOM de um cliente, o guia para fornecedores de componentes e a checklist que o seu cliente vai aplicar.

SBOM como evidência de conformidade: perguntas frequentes

A ISO 27001 exige uma SBOM?

Não. A ISO/IEC 27001:2022 não menciona SBOM. Os controlos 5.9 (inventário), 5.21 (cadeia de abastecimento de TIC) e 8.8 (vulnerabilidades técnicas) do Anexo A pedem resultados que uma SBOM suporta, e a organização e o seu auditor decidem que evidência é suficiente.

O SOC 2 exige uma SBOM?

Não. Os Trust Services Criteria são declarações de resultados e não mencionam SBOM. Uma SBOM por versão, reavaliada face a novos avisos de segurança, é evidência para o CC7.1, e um pipeline de build registado suporta o CC8.1, sobre a gestão de alterações.

A NIS2 exige uma SBOM?

Não. O artigo 21.º, n.º 2, alínea d), pede segurança da cadeia de abastecimento e a alínea e) tratamento de vulnerabilidades, sem mencionar SBOM. O Regulamento de Execução (UE) 2024/2690, que abrange certos prestadores de serviços digitais, pede no ponto 6.1.2(c) informação sobre os componentes de hardware e software dos produtos de TIC, ainda sem a palavra SBOM.

Que controlos do Anexo A da ISO 27001 uma SBOM suporta?

Sobretudo o 5.9 (inventário de informação e outros ativos associados), do 5.19 ao 5.22 (fornecedores e cadeia de abastecimento de TIC) e o 8.8 (gestão de vulnerabilidades técnicas). Um registo do build toca em parte no 8.25, no 8.29 e no 8.30. Do 8.26 ao 8.28 tratam de requisitos, conceção e código, fora de uma SBOM.

O que pedem os clientes sujeitos à NIS2 aos seus fornecedores de software?

Normalmente, uma descrição do desenvolvimento seguro, os componentes da versão entregue, o compromisso de tratar vulnerabilidades, uma forma de receber informação sobre vulnerabilidades e os motivos quando uma vulnerabilidade não se aplica. Essas perguntas vêm do artigo 21.º, n.º 3, e, em alguns setores, dos pontos sobre fornecedores do Regulamento de Execução 2024/2690.

Uma SBOM é evidência suficiente para o controlo 8.8 da ISO 27001?

Não. Mostra o que cada versão contém. O controlo 8.8 também exige evidência de que obtém informação sobre vulnerabilidades, avalia a exposição e age em conformidade. Junte à SBOM a reavaliação contínua, um registo das versões afetadas e as decisões tomadas.

Qual é a diferença entre estar em conformidade e ter evidência?

Estar em conformidade significa que os seus processos cumprem os requisitos do framework, segundo a avaliação de um auditor ou de um cliente. A evidência é o que mostra que esses processos funcionam. Uma SBOM é evidência para alguns controlos. Não torna ninguém conforme com nenhum framework.