Mais 124% CVE comunicadas por dia em 2026 do que no ano passado.

Plataforma

Como funciona o CRACI

O CRACI executa os seus builds de GitHub Actions e regista o que cada um descarrega. Tudo o resto, do acompanhamento de vulnerabilidades às evidências para o CRA, assenta nesse registo.

Atualizado a

Visão geral da plataforma CRACI. O código-fonte no GitHub passa pelo GitHub Actions até ao CRACI Secure Build Service. O build alimenta o CRACI Package Analytics e, depois, a Vulnerability Analysis (que também recebe dados de fornecedores terceiros), o Digital Inventory e o Compliance Reporting, que comunica a terceiros como clientes, fornecedores e a ENISA. O build alimenta também o CRACI Attack Prevention. O Attack Prevention e o Digital Inventory conduzem ambos à implementação em staging e em produção.
A plataforma CRACI, da esquerda para a direita. Abrir o diagrama em tamanho real.

A versão curta

A maioria das ferramentas de segurança analisa o seu código ou os seus manifestos a posteriori e deduz o que um build provavelmente continha. O CRACI é o runner do build, pelo que vê o que o build efetivamente obteve, no momento em que o obteve. Esse registo é a base de tudo o que está no diagrama: análise de pacotes, prevenção de ataques, análise de vulnerabilidades, rastreabilidade e relatórios de conformidade.

Mantém o GitHub e o GitHub Actions. A alteração é uma linha em cada workflow:

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

Passo a passo

1. Código-fonte e CI/CD: GitHub e GitHub Actions

O seu código continua no GitHub. Liga a sua organização instalando a GitHub App do CRACI, em todos os repositórios ou apenas nos que escolher. Os workflows continuam a ser executados a partir do GitHub Actions e as respetivas execuções continuam a aparecer no GitHub. O GitHub Actions é hoje a integração de CI suportada; o suporte para outros sistemas de CI/CD está no roadmap.

2. Build: CRACI Secure Build Service

Os jobs são executados em runners do CRACI, em máquinas virtuais isoladas. Os runners vão de 1 a 32 unidades de computação (cada uma com 1 vCPU e 3 GB de RAM), em x86-64 e ARM64 nativos, com uma imagem Ubuntu compatível com o GitHub ou com as imagens slim do CRACI. A utilização é medida ao segundo.

Os builds no CRACI são executados cerca de duas vezes mais depressa do que nos runners alojados standard do GitHub. Cada minuto também custa menos: um runner Linux standard de 2 vCPU custa $0.004 por minuto, face aos $0.006 do GitHub (cerca de 33% menos). Somando as duas coisas, um build que demora 10 minutos no GitHub termina em cerca de 5 no CRACI e custa cerca de 67% menos. O CRACI fatura ainda ao segundo, em vez de arredondar cada job para cima, ao minuto inteiro, pelo que os pipelines compostos por muitos jobs curtos poupam ainda mais. Ver a comparação completa com os runners alojados no GitHub.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. Descoberta da cadeia de abastecimento: CRACI Package Analytics

Enquanto o job é executado, um proxy que reconhece pacotes observa o tráfego para as fontes de pacotes e regista cada dependência externa que o build descarrega, em fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como nas predefinições de descarga do Yocto e do OpenEmbedded. As evidências acompanham as caches de CI, pelo que os pacotes restaurados de uma cache continuam contabilizados.

É esta a diferença face a outras ferramentas de SBOM. Essas leem o lockfile ou o resultado do build e deduzem o que entrou. O CRACI vê o tráfego, pelo que regista também as dependências ocultas que nenhum lockfile lista: código descarregado por hooks de npm install, ficheiros que os scripts de build de Rust obtêm durante o build e as camadas da imagem base de um build de contentor.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.

Cada job e cada cache recebem um estado de completude, de Complete a Not recorded, para que saiba até que ponto pode confiar na SBOM produzida. As SBOM são exportadas em CycloneDX ou SPDX, incluindo as dependências transitivas.

4. Segurança contínua da cadeia de abastecimento: CRACI Attack Prevention

A mesma camada que regista o tráfego também o controla. Uma política de egress decide que hosts um job pode contactar, com negação ou permissão por defeito, predefinições integradas para fontes de software comuns e regras personalizadas para as suas. As políticas são validadas antes de o job começar e falham em modo fechado, e o CRACI alerta-o em caso de violação. Uma dependência ou ferramenta de build comprometida que tente contactar o exterior é travada no runner.

Como a política só permite aquilo de que o build precisa, em vez de procurar hosts maliciosos conhecidos, funciona contra um ataque que ninguém viu antes. Se um worm como o Shai-Hulud chegar primeiro ao seu build, a tentativa de enviar os seus segredos para fora é bloqueada na mesma.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. Resposta contínua na cadeia de abastecimento: CRACI Vulnerability Analysis

Os pacotes registados são cruzados com vulnerabilidades conhecidas e as SBOM monitorizadas são reavaliadas continuamente, pelo que uma vulnerabilidade divulgada depois do lançamento continua a chegar até si. As vistas ao nível da organização mostram que builds e repositórios partilham uma dependência vulnerável, e as equipas de segurança podem fazer a triagem de cada conclusão e enviá-la à equipa responsável pela correção. Pode também adicionar SBOM dos seus fornecedores terceiros, para que os componentes que compra sejam monitorizados a par dos que os seus próprios builds descarregam.

Using SBOMs for improved cybersecurity

Como uma SBOM do build se transforma em monitorização de vulnerabilidades após o lançamento, que é a função da geração de SBOM e do acompanhamento de vulnerabilidades do CRACI.

Petteri Pulkkinen e Erika Marttinen em Kubernetes Community Days Helsinki 2026, de 22:11 a 23:27 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

6. Rastreio da cadeia de abastecimento: CRACI Digital Inventory

Cada build tem a sua SBOM e o traço de rede daquilo a que se ligou, e a API do CRACI devolve SBOM, traços de rede e dados de proveniência. Quando uma nova vulnerabilidade ou um pacote comprometido chega às notícias, pode indicar, a partir de um único sítio, quais dos seus builds estão afetados.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. Relatórios da cadeia de abastecimento: CRACI Compliance Reporting

As evidências recolhidas pelo caminho chegam a quem as pede: clientes, fornecedores e autoridades. As SBOM são exportadas em CycloneDX ou SPDX, incluindo as vulnerabilidades encontradas nos seus componentes, a API devolve SBOM, traços de rede e dados de proveniência, e o CRACI submete as notificações de vulnerabilidades do CRA em nome da sua empresa.

O Cyber Resilience Act é a regra mais conhecida por trás disto, mas não a única. Em todos os referenciais o pedido é o mesmo: saber o que está no seu software e ter um processo para encontrar e tratar as suas vulnerabilidades.

  • Cyber Resilience Act da UE: uma SBOM e gestão de vulnerabilidades para produtos com elementos digitais vendidos na UE, com obrigações de comunicação a partir de setembro de 2026.
  • NIS2: segurança da cadeia de abastecimento e gestão e divulgação de vulnerabilidades para entidades essenciais e importantes.
  • ISO/IEC 27001: não menciona SBOM, mas os controlos do seu Anexo A exigem um inventário de ativos (5.9), segurança na cadeia de abastecimento das TIC (5.21) e gestão de vulnerabilidades técnicas (8.8). As SBOM geradas no build e a monitorização contínua são evidências para os três.
  • FDA dos EUA: uma SBOM nas submissões de pré-comercialização de dispositivos médicos ligados, bem como um plano para monitorizar e tratar vulnerabilidades após o lançamento.
  • Executive Order 14028 dos EUA: SBOM para cada produto e um processo de divulgação de vulnerabilidades, nas orientações de segurança da cadeia de abastecimento de software para fornecedores que vendem ao governo federal.

O CRACI fornece as SBOM e a monitorização contínua de vulnerabilidades que estes referenciais esperam, bem como as evidências que sustentam as suas declarações de conformidade. Cumprir cada referencial continua a ser um processo da sua empresa; o CRACI torna automática a parte das evidências.

8. Implementação: staging e produção

O que chega a staging e a produção foi compilado sob a sua política de rede, com uma SBOM registada durante o build e monitorizada quanto a novas vulnerabilidades após o lançamento.

Saiba mais

Veja o CRACI no seu próprio pipeline

Marque uma demo e analisaremos consigo os seus builds, as suas SBOM e as suas evidências de conformidade.

Marcar demo