Segurança da cadeia de abastecimento de software, registada a partir de cada build
A cadeia de abastecimento do seu software encontra-se com o seu produto no build de CI. O CRACI executa os seus jobs de GitHub Actions em runners seguros e regista cada dependência que descarregam, controla o que cada build pode contactar e continua a acompanhar as vulnerabilidades no que distribuiu.
Runners seguros para GitHub Actions
Altere runs-on para craci e os seus jobs de GitHub Actions passam a ser executados nos runners do CRACI, com as execuções a continuarem a aparecer no GitHub. Cada job recebe a sua própria máquina virtual isolada, em Linux x86-64 ou ARM64, alojada na Europa. Os builds são executados cerca de duas vezes mais depressa do que nos runners alojados no GitHub, graças a hardware mais rápido, filas de espera mais curtas e cache.
Uma SBOM registada a partir de cada build
O CRACI é um registador, não um scanner. Um proxy que reconhece pacotes, no runner, vê cada pacote que o job descarrega de fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como das predefinições de descarga do Yocto e do OpenEmbedded, incluindo pacotes restaurados de caches de CI. A SBOM de cada job tem um estado de completude e é exportada em CycloneDX ou SPDX com as dependências transitivas e a licença declarada de cada componente.
Controle o que um build pode contactar
Uma política de egress decide a que hosts um job se pode ligar: negação ou permissão por defeito, 24 predefinições integradas de fontes de software, fontes personalizadas tipadas para registos de pacotes e Git, e regras de rede explícitas. A política é validada antes de o job começar e falha em modo fechado, e as violações geram um alerta. Uma dependência ou um passo de build comprometido não consegue enviar dados discretamente para um host que nunca aprovou.
Proveniência do que distribui
A REST API pública devolve SBOM, traços de rede e dados de proveniência para cada job, tudo registado a partir do mesmo build. As evidências saem do próprio build, sem nenhum passo adicional no workflow.
Acompanhamento de vulnerabilidades após o lançamento
O CRACI reavalia continuamente as SBOM do que lançou à medida que são publicadas novas vulnerabilidades e agrega as conclusões de todos os builds e repositórios. As equipas de segurança fazem a triagem e encaminham cada uma para a equipa responsável pela correção. As policy gates podem bloquear um build com base em conclusões ou numa licença, o VEX é suportado, as SBOM de fornecedores são monitorizadas a par dos seus próprios builds e a vista de inventário mostra que versões de software estão implementadas em que produtos.
Evidências para clientes e auditores
Clientes, auditores e regulamentos pedem cada vez mais uma SBOM por versão e um registo de como as vulnerabilidades foram tratadas. O CRACI exporta SBOM em CycloneDX ou SPDX, incluindo as vulnerabilidades encontradas nos seus componentes, e uma REST API pública devolve SBOM, traços de rede e dados de proveniência. As mesmas evidências servem o Cyber Resilience Act da UE, a NIS2, os requisitos de SBOM da FDA e os controlos de cadeia de abastecimento da ISO 27001.
As perguntas que um incidente na cadeia de abastecimento levanta
Quando um pacote, uma action de CI ou um registo é comprometido, as primeiras horas são gastas a perceber se a sua empresa foi afetada. Estas são as perguntas que as equipas fazem, e onde o registo do build feito pelo CRACI lhes dá resposta.
| A pergunta | Como o CRACI responde |
|---|---|
| Algum dos nossos builds descarregou a versão comprometida do pacote? | A SBOM de cada build lista os pacotes que o job efetivamente obteve, pelo que pesquisa nos builds registados em vez de voltar a analisar os repositórios. |
| Quais dos nossos produtos e versões estão afetados? | As SBOM monitorizadas são reavaliadas continuamente, e a vista de inventário associa as versões de software aos produtos em que estão implementadas. |
| Um passo de build pode ter enviado segredos para algum lado? | O traço de rede de cada job regista as ligações que estabeleceu, e a política de egress bloqueia os hosts fora da política antes de serem contactados. |
| Esta SBOM está suficientemente completa para ser entregue? | A SBOM de cada job indica a sua completude: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. |
| Quem está a corrigir, e conseguimos provar que foi tratado? | As conclusões são triadas e encaminhadas para as equipas responsáveis, e as SBOM são exportadas em CycloneDX ou SPDX com as vulnerabilidades encontradas nos seus componentes. |
O CRACI cobre o build e o que este distribui. A análise de código, a deteção de segredos e a análise de alcançabilidade ficam com as suas ferramentas de segurança aplicacional. O GitHub Actions é suportado hoje, com outros sistemas de CI no roadmap.
Segurança da cadeia de abastecimento de software: respostas
O que abrange, porque pertence à CI/CD e qual o papel do CRACI
O que é a segurança da cadeia de abastecimento de software?
A segurança da cadeia de abastecimento de software protege tudo o que entra no seu software entre o primeiro commit e o lançamento: dependências open source, imagens base, ferramentas de build, actions de CI de terceiros, o próprio pipeline de CI e os artefactos que distribui. Significa saber que partes são essas, controlar de onde vêm e provar o que entrou em cada versão.
Porquê proteger a cadeia de abastecimento de software na CI/CD?
O build de lançamento é onde as suas dependências são resolvidas, descarregadas e empacotadas. Um build de produção não é o build num portátil: intervalos de versões, tags mutáveis e caches fazem com que possa descarregar algo diferente. Um registo feito durante a execução do build de lançamento é o único registo fiável do que foi distribuído, e o runner do build é o sítio onde pode controlar o que o build pode contactar.
Em que difere o CRACI de um scanner de segurança da cadeia de abastecimento?
Os scanners leem ficheiros a posteriori: um manifesto, um lockfile, código-fonte ou um binário final. O CRACI é o runner dos seus jobs de GitHub Actions, pelo que observa o build enquanto decorre e regista os pacotes que cada job efetivamente descarregou, incluindo pacotes restaurados de caches de CI. Cada SBOM indica a sua própria completude, uma política de egress controla o que o build pode contactar e a API devolve SBOM, traços de rede e dados de proveniência.
O CRACI substitui os meus workflows de GitHub Actions?
Não. O CRACI substitui o runner, não o GitHub Actions. Altera runs-on para craci, e os seus workflows, triggers e histórico de execuções continuam no GitHub.
Que sistemas de CI e plataformas suporta o CRACI?
Hoje, o GitHub Actions; outros sistemas de CI estão no roadmap, entre eles o GitLab CI e o Jenkins. Os runners são Linux em x86-64 e ARM64, com Windows e macOS no roadmap.
O CRACI faz SAST, deteção de segredos ou análise de alcançabilidade?
Não. O CRACI regista e controla o build, acompanha as vulnerabilidades no que distribuiu e produz as evidências. Analisar o seu próprio código em busca de falhas ou segredos, bem como a análise de alcançabilidade, são tarefas de uma ferramenta de segurança aplicacional.
Onde são armazenados os dados dos meus builds?
O CRACI está alojado na Europa, em infraestrutura bare-metal europeia, e os dados são conservados durante 180 dias por defeito, com retenção personalizada no Enterprise. O CRACI não armazena o seu código-fonte. O CRACI tem certificação ISO 27001; os detalhes estão no Trust Center.
Veja o que os seus builds efetivamente descarregam
Marque uma demo para ver a SBOM, o traço de rede, a política de egress e a proveniência que o CRACI regista para um build de GitHub Actions
Marcar uma demo