CRACI vs en egen SBOM-stack

Det korta svaret

En egen stack byggd av Syft eller Trivy, Grype, Dependency-Track, Cosign och Renovate kostar inget i licenser, körs var som helst och ger ett kapabelt plattformsteam full kontroll. CRACI är en hanterad GitHub Actions-runner som registrerar vad varje bygge hämtade, styr vart det kan ansluta, bevakar det som levererats och exporterar bevisen. Skillnaden handlar mindre om funktioner och mer om varifrån SBOM:en kommer och vem som underhåller skarvarna. Om du bygger på GitLab, Jenkins eller Windows, eller om allt måste köras på din egen infrastruktur, är DIY den ärliga rekommendationen i dag.

Så ser stacken ut

En komplett lösning du bygger själv har oftast sju lager. Vart och ett är ett riktigt projekt med eget underhåll.

1. Generering. Syft ("generating a Software Bill of Materials (SBOM) from container images and filesystems"), Trivy, cdxgen (ett OWASP-projekt som skapar CycloneDX-BOM:er "from source and container images") eller Microsoft SBOM Tool, som skriver SPDX och förväntar sig en mapp med byggresultat, ett paketnamn, en version och en leverantör på kommandoraden.
2. Matchning. Grype skannar avbilder, filsystem och SBOM:er, med EPSS, KEV och riskpoäng. OSV-Scanner matchar lockfiler, SBOM:er och containeravbilder mot OSV.dev.
3. Hantering. OWASP Dependency-Track tar in SBOM:er i CycloneDX och bevakar dem över tid. Dess API-server behöver minst 2 GB RAM och 2 CPU-kärnor (8 GB och 4 kärnor rekommenderas), och dess dokumentation hänvisar produktionsdriftsättningar till Docker Compose med en separat databas.
4. Signering. Cosign signerar avbilder, blobbar och SBOM-attesteringar, med nyckellös signering via Fulcio och en Rekor-transparenslogg. GitHub artifact attestations bygger på Sigstore och ger proveniens enligt SLSA v1.0 Build Level 2.
5. Uppdateringar. Renovate eller Dependabot öppnar pull requests för att hålla beroenden aktuella.
6. Egress-kontroll. StepSecurity Harden-Runner kan granska eller blockera utgående anslutningar från GitHub Actions-jobb. Dess Community-nivå är gratis för publika repon på GitHub-hostade runners; privata repon och självhostade runners kräver Enterprise-nivån. Alternativet är din egen proxy och egna brandväggsregler runt självhostade runners.
7. Rapportering. Någon gör om resultatet av allt ovan till de dokument som en revisor, en kund eller en teknisk dokumentation för CRA behöver.

Kostnaden ligger i skarvarna

Att välja generator är att välja dess blinda fläckar

Rikta flera SBOM-generatorer mot samma repo så blir de inte överens om vad det innehåller. Var och en läser en annan uppsättning filer och tolkar dem på sitt sätt, så komponentlistan du får är lika mycket en egenskap hos verktyget du valde som hos projektet. NTIA:s leverantörsfält visar samma sak från andra hållet: de flesta generatorer har ingen källa för det, så det blir tomt oavsett vad repot innehåller.

Inget av verktygen är trasigt. Vart och ett gör ett eget, dokumenterat val av vad som räknas som en komponent och vilka filer som går att lita på. Men en egen stack ärver valen i de verktyg du råkade välja, och resten av pipelinen (matchning, bevakning, rapportering) kan aldrig bli mer komplett än det första steget.

Limmet är ditt

Varje verktyg har sin egen releasetakt, sårbarhetsdatabas, utdataformat och konfiguration. Någon låser versionerna, uppdaterar databaserna, håller Dependency-Track och dess databas patchade, roterar signeringsidentiteter, bestämmer vilken SBOM som går vart och märker när ett steg i tysthet börjar leverera mindre. Det är löpande plattformsarbete, inte en engångsinstallation.

Verktygen är också beroenden

Säkerhetsverktyg körs inne i dina byggen med åtkomst till dina hemligheter, så de hör hemma i din hotmodell. I mars 2026 publicerade Aqua Security ett säkerhetsmeddelande som beskrev hur komprometterade inloggningsuppgifter användes för att publicera en skadlig Trivy-release och för att under cirka 12 timmar tvinga de flesta trivy-action-taggar att peka på kod som stal inloggningsuppgifter. Aqua dokumenterade det öppet, och det hade kunnat hända vilket brett använt projekt som helst. Det visar varför egress-kontroll på runnern spelar roll: en policy som nekar som standard begränsar vart ett komprometterat steg kan skicka data, men inte varje kanal (säkerhetsmeddelandet beskriver också en reservväg som skapade repon på offrets GitHub-konto).

När DIY är rätt val

• Din CI är inte GitHub Actions. CRACI har i dag stöd för enbart GitHub Actions, med GitLab CI och Jenkins på roadmapen. Team på GitLab, Jenkins och CircleCI kan köra alla verktygen med öppen källkod ovan.
• Du bygger på Windows eller macOS. CRACI-runners kör Linux (x86-64 och ARM64) i dag; Windows och macOS finns på roadmapen.
• Allt måste köras på din infrastruktur. CRACI kör i dag hanterade runners på europeisk infrastruktur, med kundhostade runners på roadmapen för Enterprise.
• Du har ett plattformsteam som vill äga det. Om underhållet av stacken är en medveten investering och du redan driver Dependency-Track väl, behåll det.
• Du behöver en SBOM till ett frågeformulär. För en enstaka förfrågan där lite står på spel kan det räcka att köra en generator för hand.

Vad CRACI ersätter, och vad det inte ersätter

CRACI täcker flera lager på ett ställe, med början i bygget. Du ändrar runs-on till craci, och körningarna syns fortfarande i GitHubs gränssnitt. En paketmedveten proxy registrerar vad varje jobb hämtar från npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar, och beroendebevisen följer med CI-cachar. Varje jobb och cache får en fullständighetsstatus: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

• Generering: CycloneDX och SPDX från det registrerade bygget, inklusive transitiva beroenden.
• Bevakning: fynd sammanställda över byggen och repon, och bevakade SBOM:er omvärderas löpande.
• Proveniens: API:t returnerar SBOM:er, nätverksspårningar och proveniens. CRACI signerar inte proveniens.
• Egress: policy per jobb med 24 inbyggda förinställningar för programvarukällor, valideras innan jobbet startar, blockerar vid fel och varnar vid överträdelser.
• Export: SBOM:er som CycloneDX eller SPDX, inklusive sårbarheter; ingen rapportexport.

Det ersätter inte allt. Blocklistor för paket finns på roadmapen. Om du behöver signerad proveniens, behåll Cosign eller GitHub artifact attestations. Renovate eller Dependabot är fortfarande vettiga för att hålla alla beroenden aktuella, inte bara de sårbara. Om Dependency-Track är där ditt säkerhetsteam arbetar kan SBOM:en i CycloneDX hämtas via CRACI:s REST API och matas in där.

En inventering av vad som är driftsatt var

CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt. När en ny sårbarhet dyker upp ser du vilka produkter som kör den berörda versionen i stället för att pussla ihop det från release notes och kalkylblad.

För Cyber Resilience Act

CRA kräver att tillverkare identifierar och dokumenterar sårbarheter och komponenter i produkter med digitala element, "bland annat genom att upprätta en programvaruförteckning" (bilaga I, del II). Rapportering av aktivt utnyttjade sårbarheter gäller från september 2026, med 24 timmar för den första anmälan. En egen stack kan stödja det, så länge någon äger beviskedjan från varje release tillbaka till dess SBOM. CRACI automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som företag behöver för sitt bredare arbete med CRA-efterlevnad, och lämnar in CRA-anmälningarna åt dig. Oavsett vilken väg du väljer ligger det kvar hos ditt team att avgöra vad som aktivt utnyttjas. Se CRA-efterlevnad och SBOM-generering under bygget.