CRA-efterlevnad: krav på SBOM:er och verktyg

Varje jämförelse visar vad den andra produkten gör bra, var CRACI skiljer sig och när du skulle använda båda. För alla kategorier, se alla jämförelser.

Vad CRA kräver av en SBOM

Cyber Resilience Act, förordning (EU) 2024/2847, placerar SBOM:en bland sina krav på sårbarhetshantering. Den kräver mindre än många tror: en maskinläsbar förteckning över åtminstone beroendena på högsta nivå, som sparas i den tekniska dokumentationen och visas för en myndighet på begäran. Här är vad förordningen säger, fråga för fråga.

Förordningen gäller i sin helhet från den 11 december 2027, och dess rapporteringsskyldigheter gäller från den 11 september 2026. För resten av förordningen, se vad CRA kräver.

Bortom miniminivån: BSI TR-03183-2

Tills kommissionen specificerar formatet genom en genomförandeakt kommer den mest detaljerade offentliga vägledningen från Tysklands federala myndighet för informationssäkerhet (BSI). Dess tekniska riktlinje TR-03183-2, version 2.1.0 från augusti 2025, är vägledning och inte en del av förordningen, men den visar vart förväntningarna är på väg:

• Format: JSON eller XML, giltigt enligt CycloneDX 1.6 eller senare, eller SPDX 3.0.1 eller senare.
• Djup: rekursiv upplösning av beroenden för varje komponent i leveransens omfattning, ända ner till och med den första komponenten utanför den.
• Sanningskälla: SBOM:en måste innehålla "samma information som finns tillgänglig under byggprocessen", eller motsvarande information där det inte finns någon byggprocess.

Riktlinjen namnger också olika typer av SBOM. En Build SBOM "skapas som en del av byggprocessen". En Analysed SBOM "skapas efter byggprocessen genom analys av artefakter som körbara filer, paket, containrar och avbilder för virtuella maskiner". Den distinktionen är den största skillnaden mellan verktygen på den här sidan.

Beroenden på högsta nivå eller transitiva beroenden

Beroendena på högsta nivå är miniminivån, inte målet. En sårbarhet i ett transitivt paket finns ändå i din produkt, och CRA kräver att tillverkare hanterar och åtgärdar sårbarheter i de komponenter de levererar. En SBOM som stannar vid första ledet lämnar de paketen utanför din sårbarhetshantering. Den praktiska frågan är inte om transitiva beroenden ska registreras, utan hur du kan vara säker på att registreringen stämmer med det som levererades. Se transitiva beroenden för hur du listar dem och åtgärdar sårbara.

Build SBOM eller analysed SBOM

De flesta SBOM-verktyg genererar en analysed SBOM efter bygget, eller hanterar SBOM:er som andra verktyg tar fram. CRACI registrerar en build SBOM medan bygget körs. För SBOM-generatorer och SBOM-hanterare i jämförelse, se SBOM-hantering och SBOM-verktyg i jämförelse. För verktyg byggda kring CRA, se verktyg för CRA-efterlevnad i jämförelse.

Där CRACI passar in

CRACI registrerar SBOM:en medan ditt GitHub Actions-bygge körs. En paketmedveten proxy på runnern registrerar varje paket som jobbet hämtade, inklusive paket som återställs från CI-cachar, så SBOM:en beskriver bygget som tog fram artefakten i stället för en skanning som kördes någonstans i närheten. Varje jobbs SBOM har en fullständighetsstatus, och exporter i CycloneDX och SPDX omfattar transitiva beroenden och varje komponents deklarerade licens.

Efter release fortsätter CRACI att omvärdera bevakade SBOM:er när nya sårbarheter dyker upp, och lämnar in CRA-anmälningarna (tidig varning, anmälan och slutrapport) åt dig. API:t returnerar SBOM:er, nätverksspårningar och proveniens. CRACI sparar byggdata i 180 dagar som standard, med anpassad lagringstid i Enterprise, så exportera det som hör hemma i din tekniska dokumentation för 10 år. CRACI automatiserar en betydande del av den insyn i och de bevis om leveranskedjan som din CRA-process behöver; bedömningen av överensstämmelse och den tekniska dokumentationen förblir tillverkarens ansvar. För varje CRA-krav som en stegvis färdplan, se CRA-guiden. Läs mer om SBOM-generering under bygget, eller boka en demo för att se en SBOM registrerad från ett av dina byggen.

CRACI jämfört med varje verktyg

• CRACI jämfört med Cybeats Ett register över SBOM:er jämfört med SBOM:er som registreras och bevakas.
• CRACI jämfört med FOSSA SBOM-hantering jämfört med bygge, SBOM och bevakning i ett.
• CRACI jämfört med Anchore Skanning av avbilder jämfört med registrering och bevakning av byggen.
• CRACI jämfört med Black Duck Skanning av kod, kodsnuttar och binärer jämfört med underlag från bygget.
• CRACI jämfört med Sonatype Grindkontroll i repot och SCA jämfört med underlag från bygget.
• CRACI jämfört med ONEKEY Binäranalys av firmware jämfört med underlag från bygget.
• CRACI jämfört med Finite State Analys av binärer och leverantörers SBOM:er jämfört med en registrering av bygget.
• CRACI jämfört med Exein Körtidssäkerhet på enheten jämfört med underlag från bygget.

Sida vid sida

Flera verktyg på en sida, för när du väljer en kategori, inte en enskild produkt.

• Verktyg för CRA-efterlevnad jämförda Verktyg som hjälper tillverkare att uppfylla Cyber Resilience Act.

Andra kategorier

• CI/CD-plattformar och runners
• Bygg- och runnersäkerhet
• Software composition analysis
• Säkerhet i mjukvarans leveranskedja
• SBOM-hantering
• Inbyggda system och produktsäkerhet
• PSIRT och produktsäkerhet
• Öppen källkod och gör det själv
• AI och säkerhet