SBOM-automatisering: ersätt kalkylblad med byggregistrering

Därför slutar manuella SBOM:er fungera

De blir inaktuella vid nästa bygge. Beroenden ändras med varje release, och ett kalkylblad ändras bara när någon kommer ihåg att uppdatera det.
De stannar vid det människor kan se. Direkta beroenden är lätta att lista. Det är inte de transitiva beroendena under dem, och ingen kan följa dem för hand.
De förökar sig. Flera produkter med flera versioner som stöds innebär dussintals filer, var och en med sin egen ägare och sin egen bild av sanningen.
De kan inte svara på den viktiga frågan. När en ny sårbarhet dyker upp behöver du veta vilka releaser som innehåller paketet. Att söka igenom en mapp med kalkylblad går långsamt, och du kan inte lita på svaret.
De är inte vad andra efterfrågar. Kunder och verktyg förväntar sig ett maskinläsbart format som CycloneDX eller SPDX. Se hur du besvarar en kunds SBOM-förfrågan.

Vad bra SBOM-automatisering gör

Tar fram en SBOM för varje bygge, utan att någon behöver köra eller komma ihåg något.
Täcker hela trädet, transitiva beroenden inräknade, i alla led.
Kopplar varje SBOM till ett bygge, så att du vet vilken fil som beskriver vilken release.
Anger vad den inte kunde se, i stället för att presentera en ofullständig lista som en hel.
Exporterar ett standardformat, så att SBOM:en fungerar med nästa verktyg och nästa kund.
Fortsätter att bevaka det som levererats, eftersom en release som var ren på måndagen kan vara drabbad på tisdagen.

Tre sätt att hålla SBOM:er, jämförda

Fråga	Kalkylblad	Skanner i CI	Registrerad under bygget
När uppdateras den?	När någon kommer ihåg det	När skanningssteget körs	Vid varje bygge
Varifrån kommer uppgifterna?	Från människor	Från lockfiler eller det färdiga byggresultatet	Från det bygget faktiskt hämtade
Transitiva beroenden?	Sällan	De som den kan räkna ut	I alla led
Dolda beroenden, till exempel nedladdningar från installationsskript?	Nej	Missas	Registreras
Paket som återställs från en CI-cache?	Nej	Beror på verktyget	Registreras och markeras som cachade
Sårbarhetsbevakning?	Manuell	Oftast ett separat verktyg	Inbyggd i CRACI

Att automatisera med en skanner är en verklig förbättring jämfört med ett kalkylblad, men skannern gissar ändå vad som ingick. För resonemanget, se varför bygget är den pålitliga källan.

Vad som händer med dina kalkylblad

Komponentdatan flyttar ut: versioner och paket kommer från bygget, så ingen behöver skriva in dem. Kvar blir den kunskap som bara ditt team har, till exempel vilka produkter som finns, vem som äger dem och vilka versioner som fortfarande stöds. Det är den delen som är värd en människas tid.

Så hanterar CRACI det här

CRACI ersätter dina GitHub-hostade runners med snabbare och billigare runners och registrerar SBOM:en medan varje bygge körs. Du anger runs-on: craci, och dina körningar syns fortfarande i GitHub. Standardbyggen får en komplett SBOM utan konfiguration. Byggen med egna paketregister eller ovanliga containeruppsättningar kan behöva en del.

Registrerad, inte skannad. CRACI ser trafiken som kommer in i varje bygge, inklusive de dolda beroenden som lockfile-baserade verktyg missar. Varje komponent i SBOM:en fanns i bygget.
En fullständighetsstatus för varje jobb, så att du vet när ett bygge inte kunde registreras fullt ut och varför.
Export i CycloneDX och SPDX, inklusive transitiva beroenden och de sårbarheter som hittats i komponenterna.
En vy över alla produkter. Inventarievyn visar vilka programvaruversioner som är driftsatta på vilka produkter, och CRACI fortsätter att omvärdera bevakade SBOM:er.

För att införa det i team med olika pipelines, se SBOM-generering över utvecklingsteam.

SBOM-automatisering: vanliga frågor

Vad är SBOM-automatisering?

Att ta fram en software bill of materials som en del av bygget, så att varje release har en utan att någon skapar den för hand. De bättre lösningarna bevakar också varje SBOM för nya sårbarheter efter att releasen har levererats.

Kan vi ha våra SBOM:er i Excel?

Ett kalkylblad kan fungera som en första inventering, men det är svårt att hålla aktuellt och det når inte transitiva beroenden. Det är inte heller ett standardformat för SBOM. Kunder och säkerhetsverktyg förväntar sig i allmänhet CycloneDX eller SPDX, och Cyber Resilience Act kräver ett vanligt förekommande, maskinläsbart format.

Kräver SBOM-automatisering ett nytt steg i varje pipeline?

Med de flesta generatorer gör den det: du lägger till ett steg i varje arbetsflöde och håller det uppdaterat. CRACI registrerar SBOM:en i runnern, så det finns inget steg att lägga till i dina jobb.

Vilka ekosystem registrerar CRACI?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, Debian- och Ubuntu-paket (apt), Alpine-paket (apk) och Git-källor, plus nedladdningar för Yocto och OpenEmbedded. Maven och Java finns på roadmapen.

Vilka CI-system och plattformar stöder CRACI?

GitHub Actions i dag, med andra CI-system på roadmapen. Runners finns för Linux x86-64 och ARM64 i dag, med Windows och macOS på roadmapen.

Hur gör vi med komponenter vi köper från leverantörer?

Du kan lägga till leverantörers SBOM:er i CRACI, så att inköpta komponenter bevakas tillsammans med dina egna byggen.

Vad kostar det?

CRACI tar bara betalt för byggminuter: $0.002 per vCPU-minut ($0.004 för en standardrunner med 2 vCPU), mätt per sekund, utan månadsavgift och utan avgift per SBOM.