SBOM-automatisering: erstatt regneark med registrerte bygg

Derfor slutter manuelle SBOM-er å fungere

De blir utdatert ved neste bygg. Avhengigheter endres med hver utgivelse, og et regneark endres bare når noen husker å oppdatere det.
De stopper ved det folk kan se. Direkte avhengigheter er enkle å liste opp. Det er ikke de transitive avhengighetene under dem, og ingen klarer å følge dem for hånd.
De formerer seg. Flere produkter med flere støttede versjoner hver betyr dusinvis av filer, hver med sin egen eier og sin egen versjon av sannheten.
De kan ikke svare på spørsmålet som teller. Når en ny sårbarhet dukker opp, må du vite hvilke utgivelser som inneholder pakken. Å søke gjennom en mappe med regneark tar tid, og du kan ikke stole på svaret.
De er ikke det andre ber om. Kunder og verktøy forventer et maskinlesbart format som CycloneDX eller SPDX. Se hvordan du svarer på en SBOM-forespørsel fra en kunde.

Dette gjør god SBOM-automatisering

Produserer en SBOM for hvert bygg, uten at noen må kjøre eller huske noe.
Dekker hele treet, transitive avhengigheter inkludert, på alle nivåer.
Knytter hver SBOM til ett bygg, så du vet hvilken fil som beskriver hvilken utgivelse.
Sier hva den ikke kunne se, i stedet for å presentere en delvis liste som en hel.
Eksporterer et standardformat, så SBOM-en fungerer med neste verktøy og neste kunde.
Fortsetter å overvåke det som er levert, fordi en utgivelse som var ren på mandag, kan være berørt på tirsdag.

Tre måter å føre SBOM-er på, sammenlignet

Spørsmål	Regneark	Skanner i CI	Registrert under bygget
Når oppdateres den?	Når noen husker det	Når skannesteget kjører	Ved hvert bygg
Hvor kommer dataene fra?	Fra folk	Fra lockfiler eller det ferdige resultatet	Fra det bygget faktisk hentet inn
Transitive avhengigheter?	Sjelden	De den klarer å utlede	På alle nivåer
Skjulte avhengigheter, som nedlastinger fra installasjonsskript?	Nei	Går glipp av dem	Registrert
Pakker gjenopprettet fra en CI-cache?	Nei	Avhenger av verktøyet	Registrert og merket som cachet
Sårbarhetsovervåking?	Manuell	Vanligvis et separat verktøy	Innebygd med CRACI

Å automatisere med en skanner er en reell forbedring fra et regneark, men den gjetter fortsatt på hva som gikk inn. For begrunnelsen, se derfor er bygget fasiten.

Dette skjer med regnearkene dine

Komponentdataene flytter ut: Versjoner og pakker kommer fra bygget, så ingen trenger å skrive dem inn. Det som blir igjen, er kunnskapen bare teamet ditt har, som hvilke produkter som finnes, hvem som eier dem og hvilke versjoner som fortsatt støttes. Det er den delen som er verdt en persons tid.

Slik håndterer CRACI dette

CRACI erstatter de GitHub-hostede runnerne dine med raskere og rimeligere runnere, og registrerer SBOM-en mens hvert bygg kjører. Du setter runs-on: craci, og kjøringene dine vises fortsatt i GitHub. Standardbygg får en fullstendig SBOM uten konfigurasjon. Bygg med egne pakkeregistre eller uvanlige containeroppsett kan trenge noe konfigurasjon.

Registrert, ikke skannet. CRACI ser trafikken som kommer inn i hvert bygg, inkludert de skjulte avhengighetene som lockfile-baserte verktøy går glipp av. Hver komponent i SBOM-en var med i bygget.
En fullstendighetsstatus for hver jobb, så du vet når et bygg ikke kunne registreres fullt ut, og hvorfor.
Eksport i CycloneDX og SPDX, inkludert transitive avhengigheter og sårbarhetene som er funnet i komponentene.
Én oversikt på tvers av produkter. Inventarvisningen viser hvilke programvareversjoner som er utrullet til hvilke produkter, og CRACI vurderer overvåkede SBOM-er fortløpende på nytt.

For å innføre dette i team med ulike pipelines, se SBOM-generering på tvers av utviklingsteam.

SBOM-automatisering: ofte stilte spørsmål

Hva er SBOM-automatisering?

Å produsere en software bill of materials som en del av bygget, slik at hver utgivelse har en uten at noen lager den for hånd. De beste oppsettene overvåker også hver SBOM for nye sårbarheter etter at utgivelsen er levert.

Kan vi beholde SBOM-ene våre i Excel?

Et regneark kan fungere som en første oversikt, men det er vanskelig å holde oppdatert, og det når ikke transitive avhengigheter. Det er heller ikke et standardformat for SBOM. Kunder og sikkerhetsverktøy forventer som regel CycloneDX eller SPDX, og Cyber Resilience Act ber om et vanlig brukt, maskinlesbart format.

Krever SBOM-automatisering et nytt steg i hver pipeline?

Med de fleste generatorer gjør det det: Du legger til et steg i hver workflow og holder det oppdatert. CRACI registrerer SBOM-en i runneren, så det er ikke noe steg å legge til i jobbene dine.

Hvilke økosystemer registrerer CRACI?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, Debian- og Ubuntu-pakker (apt), Alpine-pakker (apk) og Git-kilder, i tillegg til nedlastinger for Yocto og OpenEmbedded. Maven og Java står på veikartet.

Hvilke CI-systemer og plattformer støtter CRACI?

GitHub Actions i dag, med andre CI-systemer på veikartet. Runnerne er Linux x86-64 og ARM64 i dag, med Windows og macOS på veikartet.

Hva med komponenter vi kjøper fra leverandører?

Du kan legge til leverandørers SBOM-er i CRACI, slik at innkjøpte komponenter overvåkes side om side med dine egne bygg.

Hva koster det?

CRACI tar bare betalt for byggeminutter: $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU), målt per sekund, uten månedsavgift og uten gebyr per SBOM.