123% flere rapporterede CVE'er pr. dag i 2026 end sidste år.

Sammenligning

CRACI vs en DIY SBOM-stack

Hvert lag i en stack til forsyningskædesikkerhed har et godt open source-værktøj. Arbejdet ligger i at vælge dem, koble dem sammen, holde dem kørende og lukke hullet mellem en scanning og en registrering af buildet.

Opdateret

Det korte svar

En DIY-stack bygget af Syft eller Trivy, Grype, Dependency-Track, Cosign og Renovate koster ikke noget i licenser, kører overalt og giver et dygtigt platformteam fuld kontrol. CRACI er en managed GitHub Actions-runner, der registrerer, hvad hvert build hentede, styrer, hvad det kan forbinde sig til, overvåger det leverede og eksporterer dokumentationen. Forskellen handler mindre om funktioner og mere om, hvor SBOM'en kommer fra, og hvem der vedligeholder samlingerne. Bygger du på GitLab, Jenkins eller Windows, eller skal alt køre på din egen infrastruktur, er DIY den ærlige anbefaling i dag.

Sådan ser stacken ud

En komplet hjemmebygget opsætning har som regel syv lag. Hvert af dem er et rigtigt projekt med sit eget vedligehold.

  1. Generering. Syft ("generating a Software Bill of Materials (SBOM) from container images and filesystems"), Trivy, cdxgen (et OWASP-projekt, der laver CycloneDX BOM'er "from source and container images") eller Microsoft SBOM Tool, som skriver SPDX og forventer en build drop-mappe, et pakkenavn, en version og en leverandør på kommandolinjen.
  2. Matching. Grype scanner images, filsystemer og SBOM'er med EPSS, KEV og risikoscoring. OSV-Scanner matcher lockfiles, SBOM'er og container-images mod OSV.dev.
  3. Administration. OWASP Dependency-Track indlæser CycloneDX-SBOM'er og overvåger dem over tid. Dets API-server kræver mindst 2 GB RAM og 2 CPU-kerner (8 GB og 4 kerner anbefales), og dokumentationen henviser produktionsudrulninger til Docker Compose med en separat database.
  4. Signering. Cosign signerer images, blobs og SBOM-attestationer med nøglefri signering via Fulcio og en Rekor-transparenslog. GitHub artifact attestations bygger på Sigstore og giver provenance på SLSA v1.0 Build Level 2.
  5. Opdateringer. Renovate eller Dependabot åbner pull requests, der holder afhængigheder opdaterede.
  6. Egress-kontrol. StepSecurity Harden-Runner kan auditere eller blokere udgående forbindelser fra GitHub Actions-jobs. Community-niveauet er gratis for offentlige repositories på GitHub-hostede runnere; private repositories og self-hosted runnere kræver Enterprise-niveauet. Alternativet er din egen proxy og egne firewallregler omkring self-hosted runnere.
  7. Rapportering. Nogen skal omsætte output fra alt det ovenstående til de dokumenter, en revisor, en kunde eller en teknisk CRA-dokumentation har brug for.
Funktion CRACI DIY-stack
Kører dine builds Jobs kører på CRACI-runnere Værktøjerne kører som trin i din CI
SBOM registreret fra buildet Observerede hentninger, inklusive cachede pakker Rekonstrueret ud fra filer bagefter
SBOM'ens fuldstændighed Angivet pr. job og pr. cache Afhænger af generatoren, dens indstillinger og om du installerede først
Egress-politik på runneren Default deny eller allow, blokerer ved fejl (fail closed) Harden-Runner eller din egen proxy
Signeret provenance Ingen signeret provenance Cosign eller GitHub artifact attestations
Overvågning af leverede SBOM'er Overvågede SBOM'er genvurderes løbende Dependency-Track, når du først hoster det
Porteføljepolitik, VEX og triage Triage, VEX og licenspolitik Politikker og VEX i Dependency-Track
CRA-dokumentation og rapporter SBOM'er i CycloneDX eller SPDX, registreringer via API; ingen rapporteksport Du samler selv rapporter fra hvert værktøj
Andre CI-systemer, Windows og macOS Linux på GitHub Actions i dag; anden CI, Windows og macOS på roadmappen Generatorer og scannere kører i enhver CI
Kører på din egen infrastruktur Managed i dag; kundehostede runnere på roadmappen, Enterprise Open source-værktøjer, du selv hoster
Omkostning $0.002 pr. vCPU-minut ($0.004 for 2 vCPU), målt pr. sekund; intet månedligt gebyr og ingen betaling pr. SBOM Gratis licenser. Du betaler med ingeniørtid, hosting og vedligehold.
  • Inkluderet
  • Delvist
  • Ikke inkluderet
  • På roadmappen

Omkostningen ligger i samlingerne

At vælge en generator er at vælge dens blinde vinkler

Peg flere SBOM-generatorer mod det samme repository, og de bliver ikke enige om, hvad det indeholder. Hver af dem læser et andet sæt filer og resolver dem forskelligt, så den komponentliste, du får, er lige så meget en egenskab ved det værktøj, du valgte, som ved projektet. NTIA's leverandørfelt viser det samme fra den anden side: De fleste generatorer har ingen kilde til det, så det ender tomt, uanset hvad repositoriet indeholder.

Ingen af disse værktøjer er i stykker. Hvert af dem træffer en anden, dokumenteret beslutning om, hvad der tæller som en komponent, og hvilke filer der er til at stole på. Men en DIY-stack arver de beslutninger, du nu har valgt, og resten af pipelinen (matching, overvågning, rapportering) kan kun blive lige så komplet som det første trin.

Sammenkoblingen er dit ansvar

Hvert værktøj har sin egen release-kadence, sårbarhedsdatabase, outputformat og konfiguration. Nogen skal fastlåse versionerne, opdatere databaserne, holde Dependency-Track og dets database patchet, rotere signeringsidentiteter, beslutte, hvilken SBOM der skal hvorhen, og opdage, når et trin i al stilhed begynder at producere mindre. Det er løbende platformarbejde, ikke en engangsopsætning.

Værktøjerne er også afhængigheder

Sikkerhedsværktøjer kører inde i dine builds med adgang til dine secrets, så de hører hjemme i din trusselsmodel. I marts 2026 offentliggjorde Aqua Security en advisory, der beskrev, hvordan kompromitterede credentials blev brugt til at udgive en ondsindet Trivy-release og til i omkring 12 timer at force-pushe de fleste trivy-action-tags til kode, der stjal credentials. Aqua dokumenterede det offentligt, og det kunne være sket for ethvert udbredt projekt. Det viser, hvorfor egress-kontrol på runneren er vigtig: En default deny-politik begrænser, hvor et kompromitteret trin kan sende data hen, dog ikke alle kanaler (advisoryen beskriver også en reserveløsning, der oprettede repositories på ofrets GitHub-konto).

Hvornår DIY er det rette valg

  • Din CI er ikke GitHub Actions. CRACI understøtter kun GitHub Actions i dag, med GitLab CI og Jenkins på roadmappen. Teams på GitLab, Jenkins og CircleCI kan køre alle open source-værktøjerne ovenfor.
  • Du bygger på Windows eller macOS. CRACI-runnere er Linux (x86-64 og ARM64) i dag; Windows og macOS er på roadmappen.
  • Alt skal køre på din infrastruktur. CRACI kører managed runnere på europæisk infrastruktur i dag, med kundehostede runnere på roadmappen for Enterprise.
  • Du har et platformteam, der gerne vil eje det. Er vedligeholdet af stacken en bevidst investering, og kører du allerede Dependency-Track godt, så behold det.
  • Du har brug for én SBOM til ét spørgeskema. Ved en lejlighedsvis forespørgsel, hvor der ikke er meget på spil, kan en generator kørt i hånden være nok.

Hvad CRACI erstatter, og hvad det ikke erstatter

CRACI dækker flere lag ét sted, med udgangspunkt i buildet. Du ændrer runs-on til craci, og kørslerne vises stadig i GitHubs brugerflade. En pakkebevidst proxy registrerer, hvad hvert job henter fra npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets, og dokumentationen for afhængighederne følger med CI-caches. Hvert job og hver cache får en fuldstændighedsstatus: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

  • Generering: CycloneDX og SPDX fra det registrerede build, inklusive transitive afhængigheder.
  • Overvågning: fund samlet på tværs af builds og repositories, og overvågede SBOM'er genvurderes løbende.
  • Provenance: API'et returnerer SBOM'er, netværkstraces og provenance. CRACI signerer ikke provenance.
  • Egress: politik pr. job med 24 indbyggede presets for softwarekilder, valideret før jobbet starter, der blokerer ved fejl (fail closed) og advarer ved overtrædelser.
  • Eksport: SBOM'er som CycloneDX eller SPDX, inklusive sårbarheder; ingen rapporteksport.

Det erstatter ikke alt. Blokeringslister for pakker er på roadmappen. Har du brug for signeret provenance, så behold Cosign eller GitHub artifact attestations. Renovate eller Dependabot giver stadig mening til at holde alle afhængigheder opdaterede, ikke kun de sårbare. Er Dependency-Track dér, dit sikkerhedsteam arbejder, kan CycloneDX-SBOM'en hentes via CRACI's REST API og bruges som input til det.

Et inventar over, hvad der er udrullet hvor

CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Når en ny sårbarhed dukker op, kan du se, hvilke produkter der kører den berørte version, i stedet for at stykke det sammen fra release notes og regneark.

Til Cyber Resilience Act

CRA kræver, at producenter identificerer og dokumenterer sårbarheder og komponenter i produkter med digitale elementer, "herunder ved at udarbejde en softwarestykliste" (bilag I, del II). Rapportering af aktivt udnyttede sårbarheder gælder fra september 2026, med 24 timer til den første underretning. En DIY-stack kan understøtte det, så længe nogen ejer dokumentationssporet fra hver release tilbage til dens SBOM. CRACI automatiserer en væsentlig del af den synlighed i og dokumentation for softwareforsyningskæden, som virksomheder har brug for i deres bredere CRA-compliance-proces, og indsender CRA-underretningerne på dine vegne. Uanset hvilken vej du vælger, er det stadig dit team, der afgør, hvad der er aktivt udnyttet. Se CRA-compliance og SBOM-generering under buildet.

Sammenlign din stack med ét registreret build

Book en demo, så kører vi et af dine GitHub Actions-workflows på CRACI og lægger dets SBOM ved siden af den, dine nuværende værktøjer producerer.

Book en demo