SBOM-automatisering: erstat regneark med registrerede builds

Hvorfor manuelle SBOM'er holder op med at virke

De er forældede ved næste build. Afhængigheder ændrer sig med hver release, og et regneark ændrer sig kun, når nogen husker at opdatere det.
De stopper ved det, folk kan se. Direkte afhængigheder er lette at liste op. Det er de transitive afhængigheder under dem ikke, og dem kan ingen følge i hånden.
De formerer sig. Flere produkter med flere understøttede versioner hver giver snesevis af filer, hver med sin egen ejer og sin egen opfattelse af sandheden.
De kan ikke svare på det spørgsmål, der betyder noget. Når en ny sårbarhed lander, skal du vide, hvilke releases der indeholder pakken. At gennemsøge en mappe med regneark går langsomt, og du kan ikke stole på svaret.
De er ikke det, andre beder om. Kunder og værktøjer forventer et maskinlæsbart format som CycloneDX eller SPDX. Se sådan svarer du på en kundes SBOM-anmodning.

Det gør god SBOM-automatisering

Producerer en SBOM for hvert build, uden at nogen skal køre eller huske noget.
Dækker hele træet, inklusive transitive afhængigheder i alle lag.
Knytter hver SBOM til ét build, så du ved, hvilken fil der beskriver hvilken release.
Siger, hvad den ikke kunne se, i stedet for at præsentere en delvis liste som en hel.
Eksporterer et standardformat, så SBOM'en virker med det næste værktøj og den næste kunde.
Bliver ved med at overvåge det, der er leveret, for en release, der var ren mandag, kan være berørt tirsdag.

Tre måder at holde SBOM'er på, sammenlignet

Spørgsmål	Regneark	Scanner i CI	Registreret under buildet
Hvornår opdateres den?	Når nogen husker det	Når scanningstrinnet kører	Ved hvert build
Hvor kommer dataene fra?	Mennesker	Lockfiles eller det færdige output	Det, buildet faktisk hentede
Transitive afhængigheder?	Sjældent	Dem, den kan udlede	I alle lag
Skjulte afhængigheder, som downloads fra install-scripts?	Nej	Overses	Registreres
Pakker gendannet fra en CI-cache?	Nej	Afhænger af værktøjet	Registreres og markeres som cachet
Overvågning af sårbarheder?	Manuelt	Som regel et separat værktøj	Indbygget med CRACI

At automatisere med en scanner er en reel forbedring i forhold til et regneark, men den gætter stadig på, hvad der gik ind. For begrundelsen, se hvorfor buildet er sandhedens kilde.

Det sker der med dine regneark

Komponentdataene flytter ud: Versioner og pakker kommer fra buildet, så ingen behøver at taste dem ind. Tilbage bliver den viden, kun dit team har, som hvilke produkter der findes, hvem der ejer dem, og hvilke versioner der stadig understøttes. Det er den del, der er værd at bruge en persons tid på.

Sådan håndterer CRACI det

CRACI erstatter dine GitHub-hosted runnere med hurtigere og billigere runnere og registrerer SBOM'en, mens hvert build kører. Du sætter runs-on: craci, og dine kørsler vises stadig i GitHub. Standardbuilds får en komplet SBOM uden konfiguration. Builds med egne pakke-registries eller usædvanlige container-opsætninger kan kræve en vis konfiguration.

Registreret, ikke scannet. CRACI ser trafikken, der kommer ind i hvert build, inklusive de skjulte afhængigheder, som lockfile-baserede værktøjer overser. Hver komponent i SBOM'en var med i buildet.
En fuldstændighedsstatus for hvert job, så du ved, hvornår et build ikke kunne registreres fuldt ud, og hvorfor.
Eksport i CycloneDX og SPDX, inklusive transitive afhængigheder og de sårbarheder, der er fundet i komponenterne.
Ét overblik på tværs af produkter. Inventory-visningen viser, hvilke softwareversioner der er udrullet til hvilke produkter, og CRACI bliver ved med at genvurdere overvågede SBOM'er.

Om at indføre det i teams med forskellige pipelines, se SBOM-generering på tværs af udviklingsteams.

SBOM-automatisering: ofte stillede spørgsmål

Hvad er SBOM-automatisering?

At producere en software bill of materials som en del af buildet, så hver release har en, uden at nogen laver den i hånden. De bedre opsætninger overvåger også hver SBOM for nye sårbarheder, efter releasen er leveret.

Kan vi beholde vores SBOM'er i Excel?

Et regneark kan fungere som en første oversigt, men det er svært at holde opdateret, og det når ikke ned til de transitive afhængigheder. Det er heller ikke et standardformat til SBOM'er. Kunder og sikkerhedsværktøjer forventer generelt CycloneDX eller SPDX, og Cyber Resilience Act kræver et almindeligt anvendt, maskinlæsbart format.

Kræver SBOM-automatisering et nyt trin i hver pipeline?

Med de fleste generatorer gør det: Du tilføjer et trin til hvert workflow og holder det opdateret. CRACI registrerer SBOM'en i runneren, så der er intet trin at tilføje til dine jobs.

Hvilke økosystemer registrerer CRACI?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, Debian- og Ubuntu-pakker (apt), Alpine-pakker (apk) og Git-kilder samt Yocto- og OpenEmbedded-downloads. Maven og Java er på roadmappen.

Hvilke CI-systemer og platforme understøtter CRACI?

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

Hvad med komponenter, vi køber af leverandører?

Du kan tilføje leverandørers SBOM'er til CRACI, så indkøbte komponenter overvåges side om side med dine egne builds.

Hvad koster det?

CRACI tager kun betaling for build-minutter: $0.002 pr. vCPU-minut ($0.004 for en standard-runner med 2 vCPU), afregnet pr. sekund, uden månedligt gebyr og uden betaling pr. SBOM.