A sua plataforma SOC 2 mostra que o controlo funciona. O CRACI regista o que o build continha.

A configuração de que trata esta página

Muitas equipas de SaaS acabam por adotar o mesmo esquema. Um gerador como o Syft ou o Trivy produz uma SBOM na CI, um scanner de vulnerabilidades vigia os repositórios e uma plataforma de automatização da conformidade liga-se ao GitHub e à conta de cloud para recolher evidências para o SOC 2. Funciona. Os auditores aceitam-no, e ninguém passa a semana anterior a uma auditoria a tirar capturas de ecrã.

Essas plataformas fazem isto bem. A Vanta diz que "connects read-only to your cloud, identity, code, and device tools" e "automatically pulls evidence, maps it to controls," com mais de 1.200 testes automatizados executados de hora a hora. A Drata liga-se a "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" para recolher evidências e mapeá-las para controlos SOC 2. Se o objetivo é um relatório SOC 2 sem reservas, é a ferramenta certa para o trabalho.

Esta página trata de uma questão mais específica: o que essas evidências dizem sobre a própria SBOM.

O que uma verificação SOC 2 realmente pergunta

Os exames SOC 2 reportam face aos AICPA Trust Services Criteria. O critério mais próximo das SBOM é o CC7.1:

"To meet its objectives, the entity 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."

AICPA, 2017 Trust Services Criteria, CC7.1

O critério descreve um resultado. Deixa o método e a profundidade do inventário de componentes por detrás dele ao seu critério e ao do seu auditor. Por isso, um teste automatizado pergunta normalmente se o controlo está implementado e a funcionar: há um scanner ligado, foi executado, as conclusões foram tratadas de acordo com a sua política. É uma pergunta justa, e é a caixa de verificação.

O que a verificação não pergunta é se a SBOM por detrás da análise listou tudo o que a versão continha. Uma vulnerabilidade num componente que a SBOM nunca listou não pode ser cruzada com nada, pelo que a análise não deteta nada e o controlo continua a verde.

Onde uma verificação a verde e uma SBOM completa se separam

Os geradores de SBOM trabalham a partir dos ficheiros que têm à frente, e a sua própria documentação mostra onde isso deixa lacunas:

• No expressjs/express 5.2.1, que não inclui lockfile no repositório, um gerador que resolve dependências a partir de lockfiles não tem nada para resolver. Pode ainda assim devolver um documento, listando o que mais reconhecer, como GitHub Actions e ficheiros de workflow, e nenhuma das dependências npm declaradas em package.json.
• Geradores diferentes devolvem listas diferentes a partir do mesmo checkout, porque cada um decide por si o que conta como componente. A exportação do grafo de dependências do GitHub fica ainda mais longe: é construída a partir do que o GitHub sabe sobre o repositório e lê o branch predefinido em vez do commit fixado.
• O campo de fornecedor da NTIA fica vazio na maioria dos documentos, porque a maioria dos geradores não tem de onde o obter.

Nenhuma dessas ferramentas está avariada. Cada uma leu os ficheiros para que foi apontada, e cada uma produziu um documento válido num formato normalizado, conforme agendado. Para um teste de conformidade, o controlo funcionou. Ainda assim, a SBOM não descrevia o software.

O que o CRACI acrescenta às evidências

O CRACI substitui o runner de GitHub Actions. Altera runs-on para craci, e as execuções continuam a aparecer na interface do GitHub. A SBOM é gerada dentro desse runner enquanto o build acontece: um proxy que reconhece pacotes observa o tráfego para fontes de pacotes, pelo que o registo reflete o que o job obteve e não o que um ficheiro diz que deveria obter.

A completude é indicada, não presumida

Cada job e cada cache recebem um de cinco estados de completude: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. A evidência das dependências acompanha as caches, pelo que os pacotes restaurados de uma cache quente são transportados em vez de desaparecerem sem aviso. Quando um registo está incompleto, di-lo.

Isto corresponde ao rumo das normas. Os elementos mínimos de SBOM de 2026 da CISA e dos seus parceiros pedem aos autores de SBOM que "explicitly state whether the information is unknown to the SBOM author" em vez de deixarem campos em branco sem aviso.

Evidências em formatos que os auditores aceitam

As SBOM são exportadas em CycloneDX ou SPDX, incluindo as vulnerabilidades encontradas nos seus componentes. A API REST pública devolve a SBOM, o traço de rede do job e os dados de proveniência, pelo que os mesmos registos podem seguir para onde quer que estejam as suas evidências de auditoria.

Um inventário do que está implementado e onde

A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. Quando surge uma nova vulnerabilidade, pode ver que produtos executam a versão afetada, em vez de o reconstituir a partir de notas de lançamento e folhas de cálculo.

Mantenha a plataforma SOC 2

O CRACI não é uma plataforma de automatização da conformidade e não substitui uma. Não gere políticas, revisões de acessos, verificações de dispositivos nem questionários a fornecedores. Os dois respondem a perguntas diferentes. A sua plataforma de conformidade mostra que um controlo existe e funciona. O CRACI regista o que o build trouxe e se esse registo está completo.

A diferença aumenta quando vende software na UE. O Cyber Resilience Act exige que os fabricantes identifiquem e documentem os componentes, elaborando uma lista de materiais de software "num formato de uso corrente e legível por máquina, que abranja, no mínimo, as dependências de nível superior dos produtos" (Anexo I, parte II). O Anexo VII coloca a SBOM na documentação técnica e permite que uma autoridade de fiscalização do mercado a solicite. Um relatório SOC 2 atesta a forma como a sua organização gere os seus controlos. Uma SBOM do CRA descreve um produto específico. A nossa visão geral do CRA cobre o calendário, e a página de conformidade com o CRA cobre o que o CRACI automatiza. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que um processo mais amplo de conformidade com o CRA precisa; não torna a sua empresa conforme por si só.

Como experimentar sem tocar na sua auditoria

1. Escolha um repositório cuja SBOM já alimente as suas evidências SOC 2.
2. Aponte o respetivo workflow de lançamento para o CRACI, alterando runs-on para craci.
3. Compare a SBOM registada com a que gera hoje, componente a componente, e verifique o estado de completude do job.
4. Decida se a diferença deve constar das suas evidências.

Pode saber mais sobre a geração de SBOM durante o build e as evidências para o CRA, ou ver como documentamos os nossos próprios controlos na nossa página de segurança.