SBOM-automatisering: vervang spreadsheets door buildrecords

Waarom handmatige SBOM's niet meer werken

Ze zijn bij de volgende build al verouderd. Afhankelijkheden veranderen met elke release, en een spreadsheet verandert alleen als iemand eraan denkt hem bij te werken.
Ze houden op bij wat mensen kunnen zien. Directe afhankelijkheden zijn makkelijk op te sommen. De transitieve afhankelijkheden daaronder niet, en niemand kan die met de hand volgen.
Ze vermenigvuldigen zich. Meerdere producten met elk meerdere ondersteunde versies betekenen tientallen bestanden, elk met een eigen eigenaar en een eigen versie van de waarheid.
Ze beantwoorden de vraag die ertoe doet niet. Duikt er een nieuwe kwetsbaarheid op, dan moet u weten welke releases het pakket bevatten. Een map met spreadsheets doorzoeken gaat traag, en op het antwoord kunt u niet vertrouwen.
Ze zijn niet wat anderen vragen. Klanten en tools verwachten een machineleesbaar formaat zoals CycloneDX of SPDX. Zie hoe u een SBOM-verzoek van een klant beantwoordt.

Wat goede SBOM-automatisering doet

Levert een SBOM op voor elke build, zonder dat iemand iets hoeft uit te voeren of te onthouden.
Dekt de volledige boom, inclusief transitieve afhankelijkheden, op elk niveau.
Koppelt elke SBOM aan één build, zodat u weet welk bestand welke release beschrijft.
Vermeldt wat niet zichtbaar was, in plaats van een gedeeltelijke lijst als volledig te presenteren.
Exporteert een standaardformaat, zodat de SBOM werkt met de volgende tool en de volgende klant.
Blijft monitoren wat is geleverd, want een release die maandag schoon was, kan dinsdag getroffen zijn.

Drie manieren om SBOM's bij te houden, vergeleken

Vraag	Spreadsheet	Scanner in CI	Vastgelegd tijdens de build
Wanneer wordt hij bijgewerkt?	Als iemand eraan denkt	Als de scanstap draait	Bij elke build
Waar komen de gegevens vandaan?	Van mensen	Uit lockfiles of de uiteindelijke output	Uit wat de build daadwerkelijk heeft binnengehaald
Transitieve afhankelijkheden?	Zelden	Die welke hij kan afleiden	Op elk niveau
Verborgen afhankelijkheden, zoals downloads van installatiescripts?	Nee	Gemist	Vastgelegd
Pakketten die uit een CI-cache worden teruggezet?	Nee	Hangt af van de tool	Vastgelegd en gemarkeerd als gecachet
Kwetsbaarheidsmonitoring?	Handmatig	Meestal een aparte tool	Ingebouwd bij CRACI

Automatiseren met een scanner is een echte verbetering ten opzichte van een spreadsheet, en toch blijft het gissen naar wat erin is gegaan. Lees waarom de build de bron van waarheid is.

Wat er met uw spreadsheets gebeurt

De componentgegevens verdwijnen eruit: versies en pakketten komen uit de build, dus niemand hoeft ze over te typen. Wat blijft, is de kennis die alleen uw team heeft, zoals welke producten er zijn, wie de eigenaar is en welke versies nog worden ondersteund. Dat is het deel dat de tijd van een mens waard is.

Hoe CRACI dit aanpakt

CRACI vervangt uw door GitHub gehoste runners door snellere, goedkopere runners en legt de SBOM vast terwijl elke build draait. U stelt runs-on: craci in, en uw runs blijven zichtbaar in GitHub. Standaardbuilds krijgen zonder configuratie een volledige SBOM. Builds met eigen pakketregistries of ongebruikelijke containeropstellingen hebben mogelijk wat configuratie nodig.

Vastgelegd, niet gescand. CRACI ziet het verkeer dat elke build binnenkomt, inclusief de verborgen afhankelijkheden die tools op basis van lockfiles missen. Elk component in de SBOM zat in de build.
Een volledigheidsstatus voor elke job, zodat u weet wanneer een build niet volledig kon worden vastgelegd en waarom.
Export in CycloneDX en SPDX, inclusief transitieve afhankelijkheden en de kwetsbaarheden die in de componenten zijn gevonden.
Eén overzicht over producten heen. De inventarisweergave toont welke softwareversies op welke producten zijn uitgerold, en CRACI blijft gemonitorde SBOM's opnieuw beoordelen.

Voor de uitrol over teams met verschillende pipelines, zie SBOM-generatie over engineeringteams heen.

SBOM-automatisering: veelgestelde vragen

Wat is SBOM-automatisering?

Een software bill of materials opleveren als onderdeel van de build, zodat elke release er een heeft zonder dat iemand die handmatig maakt. De betere opstellingen monitoren elke SBOM ook op nieuwe kwetsbaarheden nadat de release is geleverd.

Kunnen we onze SBOM's in Excel houden?

Een spreadsheet kan dienen als eerste inventarisatie, maar is lastig actueel te houden en reikt niet tot transitieve afhankelijkheden. Het is ook geen standaard SBOM-formaat. Klanten en securitytools verwachten doorgaans CycloneDX of SPDX, en de Cyber Resilience Act vraagt om een gangbaar, machineleesbaar formaat.

Is voor SBOM-automatisering een nieuwe stap in elke pipeline nodig?

Bij de meeste generatoren wel: u voegt aan elke workflow een stap toe en houdt die up-to-date. CRACI legt de SBOM vast in de runner, dus er hoeft geen stap aan uw jobs te worden toegevoegd.

Welke ecosystemen legt CRACI vast?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, Debian- en Ubuntu-pakketten (apt), Alpine-pakketten (apk) en Git-bronnen, plus Yocto- en OpenEmbedded-downloads. Maven en Java staan op de roadmap.

Welke CI-systemen en platforms ondersteunt CRACI?

Vandaag GitHub Actions; andere CI-systemen staan op de roadmap. Runners zijn er vandaag voor Linux x86-64 en ARM64; Windows en macOS staan op de roadmap.

Hoe zit het met componenten die we van leveranciers kopen?

U kunt SBOM's van leveranciers aan CRACI toevoegen, zodat ingekochte componenten samen met uw eigen builds worden gemonitord.

Wat kost het?

CRACI rekent alleen buildminuten: $0.002 per vCPU-minuut ($0.004 voor een standaardrunner met 2 vCPU), per seconde gemeten, zonder maandelijkse kosten en zonder kosten per SBOM.