Duas formas de experimentar o CRACI no seu build
Escolha o que for mais útil neste momento, e adaptaremos a chamada a isso.
Artūrs Vavilovs
Account Executive, CRACI · Helsínquia
O CRACI é uma equipa de 14 pessoas em Helsínquia, apoiada pela Lifeline Ventures. Estamos a acompanhar pessoalmente o onboarding de cada equipa antes da disponibilidade geral, e não lhe pediremos que retire nada para perceber se isto lhe é útil.
O que vamos abordar
- Aponte um workflow representativo para o CRACI (runs-on: craci) e compare o tempo de build e o custo lado a lado
- Percorra a SBOM registada pelo build, incluindo as dependências ocultas que as ferramentas baseadas em lockfiles não veem
- Veja como a política de egress bloqueia as ligações de que um build não precisa, antes de saírem do runner
O tempo de build é algo de que a sua equipa se queixa, ou já todos o aceitaram em silêncio?
- Onde as SBOM e os registos de vulnerabilidades do build se enquadram nos referenciais a que responde: o CRA, a NIS2, a ISO 27001, o SOC 2 e o PCI DSS
- Veja como cada build distribuído é monitorizado face a novas vulnerabilidades e como o histórico de builds mostra que builds continham uma vulnerabilidade e durante quanto tempo
- Se o CRA se aplicar à sua empresa, como o CRACI submete as notificações de vulnerabilidades às autoridades em seu nome
Quando surge uma vulnerabilidade numa dependência, quanto tempo demora a descobrir que versões suas a contêm?
Escolha uma hora
Escolha um horário, indique o seu nome e email, e o convite é enviado de imediato.
O que pode verificar na chamada
Builds cerca de 2x mais rápidos
Em comparação com os runners alojados no GitHub, graças a hardware mais rápido, tempos de fila mais curtos e cache. A chamada serve precisamente para ver se obtém o mesmo resultado nos seus workflows.
SBOM registadas a partir do próprio build
O CRACI vê o que cada job obtém durante a execução, pelo que a SBOM descreve o que foi distribuído e não o que um lockfile sugere.
Política de egress no runner
Com uma política de negação por predefinição, o runner só permite as fontes de que um build precisa, pelo que um pacote comprometido não consegue enviar os seus segredos para o host de um atacante.
SBOM do build que foi distribuído
Exportações em CycloneDX e SPDX com todas as dependências transitivas, registadas durante o build da versão em vez de reconstruídas depois.
Exposição que pode demonstrar
Os builds distribuídos são reavaliados à medida que surgem novas vulnerabilidades, e o histórico de builds mostra que builds continham uma vulnerabilidade e durante quanto tempo.
Proveniência através da API
A API devolve SBOM, traços de rede e proveniência de cada build, pelo que as evidências saem do próprio build.
Apoiado por
