Ciber-resiliência automatizada para programadores e agentes

Faça de cada build a sua primeira linha de defesa.

Coloque a segurança da cadeia de abastecimento no centro do seu software, com runners rápidos e fiáveis que custam menos.

Execute o seu primeiro build Veja como funciona

Runners seguros
SBOM geradas no build
Monitorização de vulnerabilidades
Resposta a vulnerabilidades

185 pacotes registados
6 ligações recusadas
SBOM completa
Corrigido em v2.4.1

Build

northwind-controls/web-portal

release.yml #1843 · 5d08e3b
runs-on: craci
size 2 · x86-64
Pacotes
185 pacotes registados
- next 15.2.2
- react 19.0.0
- react-dom 19.0.0
- express 4.21.2
- tailwindcss 4.0.14
- typescript 5.8.2
Policy gate

Build #1843 travado
CVE-2025-29927 · Critical
Build #1844 aprovado
Corrigido em next 15.2.3
Artefacto lançado

ghcr.io/northwind-controls/web-portal:2.4.1

sha256:e2b9…5c07
Lançado como v2.4.1

Equipas que desenvolvem com o CRACI

As vulnerabilidades chegam mais depressa do que qualquer correção.

Aos atacantes basta uma porta de entrada, e os agentes ajudam-nos a encontrá-la mais depressa do que nunca. A sua equipa tem de fechar todas as brechas, quase sempre à mão.

2026 até agora

CVE publicadas por dia: 293; Uma a cada 5 minutos, em média.
Mais por dia do que no ano anterior: +124%; Face à média diária de 2025.
Classificadas como High ou Critical, todos os dias: 148; Segundo as respetivas pontuações CVSS.

CVE publicadas por dia, por ano
Ano	CVE por dia	High ou Critical por dia
2020	39	7
2021	54	12
2022	68	20
2023	78	28
2024	109	48
2025	131	54
2026 até agora	293	148

Da lista pública de CVE, atualizada diariamente. Escolha um ano para comparar. Ler o relatório de CVE

Porquê agora

Os alertas tornaram-se ruído.
Quando centenas de conclusões são urgentes, nenhuma o é. As equipas deixam de gerir o risco e passam a contar alertas.
O volume ultrapassa qualquer equipa.
A triagem e as correções continuam a ser feitas à mão. Com este volume, contratar mais pessoas não fecha a lacuna.
As correções competem com as funcionalidades.
As equipas de produto são avaliadas pelas funcionalidades que lançam, pelo que o trabalho de segurança fica à espera de um sprint calmo que nunca chega.
Os scanners limitam-se a estimar.
Uma lista deduzida a partir de ficheiros depois do build não vê o que realmente entrou, e uma falsa confiança faz com que ninguém vá verificar.

O seu software ganha forma durante o build.

O seu lockfile fixa o que deveria ser instalado. O build decide o que realmente chega. O CRACI regista cada pacote à medida que entra, com a versão resolvida, a sua origem e se foi restaurado de uma cache de CI.

package-lock.json O que fixou

"packages": {
  …
  
  
  
  
  
  …
}

Lista apenas versões, não a origem de cada pacote nem como entrou.

Registo do build #1842 185 pacotes registados

Pacotes registados durante o build de exemplo #1842 de northwind-controls/web-portal, agrupados pela forma como entraram no build.
Pacote	Resolvida	Entrou via	Origem
Via package.json
express via package.json	4.21.2	package.json	registry.npmjs.org
next via package.json Agora afetado por CVE-2025-29927 · Critical	15.2.2	package.json	registry.npmjs.org
react via package.json · da cache de CI	19.0.0	package.json	Cache de CI
react-dom via package.json · da cache de CI	19.0.0	package.json	Cache de CI
styled-jsx via next	5.1.6	next	registry.npmjs.org
Via script de build
tailwindcss via script de build	4.0.14	script de build	registry.npmjs.org
typescript via script de build	5.8.2	script de build	registry.npmjs.org
e mais 178 pacotes registados

185 pacotes registados · 2 restaurados da cache

Proteja o build. Registe as suas dependências.

Os seus jobs são executados em runners do CRACI em vez de runners alojados no GitHub, duas vezes mais depressa. Cada pacote que descarregam é registado com a sua versão, origem e licença. Tudo o que venha de uma fonte fora da sua política é recusado.

Secure Build Service

Cada job é executado na sua própria máquina virtual isolada, atrás de uma política de egress verificada antes de o job começar.

VM isolada
Egress negado por defeito
Falha em modo fechado
Alerta em caso de violação

Package Analytics

Um proxy que reconhece pacotes regista cada pacote que um job descarrega, com a versão resolvida, a origem e a licença declarada.

npm
PyPI
RubyGems
Cargo
Go
Nix
OCI
Yocto
e outros

Evento de política Build #1842

time2025-03-14 09:13:07 UTC
jobrelease.yml #1842
stepnpm run build
policyDefault deny. Allowed: npm, GitHub, ghcr.io, Docker Hub, example.com
denied malicious.example:443
reasonO host não consta da política
actionBloqueado no runner

Ligação recusada. Alerta enviado.

Grafo de dependências v2.4.0

Excerto da SBOM CycloneDX 1.7 · JSON

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  …
  "components": [{
    "name": "next",
    "version": "15.2.2",
    "purl": "pkg:npm/[email protected]",
    "licenses": [
      { "license": { "id": "MIT" } }
    ]
  }, …]
}

É exportada em CycloneDX ou SPDX, com dependências transitivas e vulnerabilidades incluídas.

O CRACI vê o tráfego que os scanners não veem.

Outras ferramentas de SBOM leem o lockfile ou o resultado do build e adivinham o que entrou. O CRACI vê o que realmente chega a cada build, incluindo as dependências ocultas trazidas por hooks de build, scripts de build e imagens base.

Scanner

Scanner da concorrência

Método: Lê o package-lock.json
Quando: Depois do build
Vê: O que o lockfile lista

SBOM que um scanner produz a partir do lockfile do build de exemplo #1842.
Pacote	Versão	Licença	Encontrado em
next pkg:npm/[email protected]	15.2.2	MIT	package-lock.json
react pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
react-dom pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
express pkg:npm/[email protected]	4.21.2	MIT	package-lock.json
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	package-lock.json
Não consta de nenhum lockfile, logo não consta da SBOM
Não consta de nenhum lockfile, logo não consta da SBOM
Não consta de nenhum lockfile, logo não consta da SBOM

142 pacotes listados 43 em falta

SBOM registada

Método: Vê o tráfego do build
Quando: Durante o build
Vê: O que o build obteve

SBOM que o CRACI regista a partir do tráfego do build de exemplo #1842.
Pacote	Versão	Licença	Obtido de
next pkg:npm/[email protected]	15.2.2	MIT	registry.npmjs.org
react pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
react-dom pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
express pkg:npm/[email protected]	4.21.2	MIT	registry.npmjs.org
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	registry.npmjs.org
binário pré-compilado oculto via hook postinstall · pkg:npm/hidden-package	—	—	registry.npmjs.org
2 descargas do script de build oculto via script de build · pkg:generic/[email protected]?download_url=example.com/tool	—	—	example.com
40 pacotes do SO da imagem base oculto via Dockerfile FROM · pkg:oci/ubuntu	—	—	registry.hub.docker.com

185 pacotes registados mais 43 do que o lockfile mostra

Build de exemplo. Como funcionam as SBOM geradas no build

Associe potenciais vulnerabilidades às versões exatas.

O CRACI verifica continuamente as SBOM registadas quanto a novas vulnerabilidades. Neste exemplo ilustrativo, uma vulnerabilidade crítica é divulgada 7 dias após o lançamento. Siga o registo do build desde o pacote afetado até à correção da equipa.

Passo 1 de 4

CVE-2025-29927 é divulgada

next é uma dependência direta, e o build #1842 registou a versão exata.

Gravidade: Critical 9.1
Pacote: next
Afetado: de 15.0.0 a 15.2.2
Corrigido em: 15.2.3

Passo 2 de 4

Uma versão está afetada

O CRACI cruza-a com a SBOM registada.

Versão: web-portal v2.4.0
Correspondência: next 15.2.2, dependência direta
SBOM: Complete

Passo 3 de 4

Foi lançada como esta imagem

A versão, a sua imagem e a sua SBOM ficam juntas.

Imagem: ghcr.io/northwind-controls/web-portal:2.4.0
Versão: v2.4.0
SBOM: Acompanhada

Passo 4 de 4

A correção tem um responsável

Faça a triagem, encaminhe-a e acompanhe-a até uma versão corrigida.

Responsável: Equipa de plataforma
Ação: Atualizar o next para 15.2.3 e refazer o build
Corrigido em: web-portal v2.4.1, 2025-03-22

Responda a cada auditor com provas.

Cada build deixa evidências: SBOM, registos de vulnerabilidades e o percurso de cada correção até uma versão. Use-as nos seus processos de CRA, NIS2, ISO 27001 e SOC 2, para que a pergunta de um auditor se resolva com uma descarga e não com um projeto.

Composição: Uma SBOM gerada no build para cada versão.

CycloneDX
SPDX
Dependências transitivas
Vulnerabilidades
Licenças declaradas
Gestão de vulnerabilidades: As SBOM registadas são reavaliadas continuamente.

Triagem
Correção
Guardado com a versão
Comunicação: O CRACI submete em nome da sua empresa.

Alerta precoce
Notificação
Relatório final

Cyber Resilience Act

11 de setembro de 2026 Aplicam-se as obrigações de comunicação
11 de dezembro de 2027 O regulamento aplica-se na íntegra

Ler o guia do CRA

Comunicação de vulnerabilidade Excerto

web-portal v2.4.0

northwind-controls/web-portal · build #1842

SBOM: CycloneDX · Complete
Build: #1842 · commit 9f3c2e1
Vulnerabilidade: CVE-2025-29927 · Critical
Componente: next 15.2.2
Comunicada a: CSIRT e ENISA, através da CRA Single Reporting Platform

Cronologia da gestão

2025-03-14 Versão compilada e SBOM registada
2025-03-21 Aviso publicado e associado a esta versão
2025-03-21 Triagem por Segurança do produto, atribuída a Equipa de plataforma
2025-03-22 v2.4.1 lançada com next 15.2.3

A SBOM é exportada em CycloneDX ou SPDX

Execute o seu primeiro build em 5 minutos.

Nesta demo levamos um site TanStack Start desde o registo até à sua primeira execução no CRACI. Ligamos o GitHub, encaminhamos os jobs com runs-on: craci e acompanhamos a primeira execução. O CRACI regista cada dependência externa que o build descarrega, assinala as vulnerabilidades conhecidas e associa cada uma ao job que a trouxe.

Veja como o CRACI se integra no seu fluxo de entrega.

O CRACI substitui o runner, não o GitHub Actions. Os seus workflows, revisões e passos de implementação ficam como estão.

Ligue a GitHub App

Em todos os repositórios ou só nos que selecionar.
Atualize o seu runner

Defina runs-on: craci no workflow. Mais nada muda.
Execute o próximo build

As execuções continuam a aparecer no GitHub. O registo do build e a SBOM aparecem no CRACI.

Runners: Runners Linux geridos em x86-64 e ARM64, em infraestrutura europeia.
Builds: Docker Engine, Buildx e Compose v2. Os builds Yocto e BitBake estão documentados.
O seu código e dados: O CRACI processa o código-fonte durante o build e não o armazena. Os dados dos builds estão alojados na Europa. O conteúdo das caches depende do que os seus workflows guardam. Ler a página de segurança.
No roadmap: GitLab, Jenkins e outros sistemas de CI, runners Windows e macOS, runners on-prem, Maven e Java.

Execute o seu primeiro build Veja como funciona o CRACI

Perguntas que as equipas fazem antes de uma demo

Compatibilidade, configuração, segurança e tratamento de dados.

Que ambientes de CI e ecossistemas de pacotes são suportados?

O GitHub Actions é hoje a integração de CI suportada, e outros sistemas de CI estão no roadmap. O CRACI regista pacotes de registos npm, PyPI, RubyGems, Cargo, Go, Nix e OCI e de repositórios de pacotes Debian, Ubuntu e Alpine, bem como descargas Git e de outras fontes. Maven e Java estão no roadmap. Os runners são Linux em x86-64 e ARM64.

O que exige a configuração?

Liga a GitHub App do CRACI em todos os repositórios ou nos que selecionar e define runs-on: craci no seu workflow. O CRACI substitui o runner, não o GitHub Actions, pelo que as suas execuções continuam a aparecer no GitHub.

A que dados acede o CRACI e onde são armazenados?

A GitHub App lê o seu código e as suas execuções de Actions, e gere os runners que regista para a sua organização. O CRACI processa o código-fonte durante o build e não o armazena. Os dados dos builds, incluindo metadados, dados de pacotes, traços de rede, SBOM, proveniência, caches e registos de auditoria, estão alojados na Europa, com retenção personalizada no Enterprise. O conteúdo das caches depende do que os seus workflows guardam. Saiba mais sobre segurança e tratamento de dados.

O CRACI bloqueia ou alerta? O que acontece a um build que viola uma política?

A política de egress é aplicada no runner. É validada antes de o job começar e falha em modo fechado, pelo que uma ligação fora da política é recusada e é-lhe enviado um alerta. As policy gates também podem travar um build em tempo real.

Em que formatos posso exportar?

As SBOM são exportadas em CycloneDX ou SPDX, incluindo dependências transitivas, vulnerabilidades e licenças declaradas.

O que está disponível hoje e o que está no roadmap?

Disponível hoje: runners Linux geridos para GitHub Actions, SBOM geradas no build com vulnerabilidades, política de egress, monitorização contínua de vulnerabilidades com triagem e policy gates. No roadmap: GitLab, Jenkins e outros sistemas de CI, runners Windows e macOS e runners on-prem.

Com o apoio de