Verktyg för CRA-efterlevnad i jämförelse

Vem den här sidan är för

Du tillverkar en produkt med digitala element och släpper ut den på EU-marknaden. Cyber Resilience Act, förordning (EU) 2024/2847, gäller för dig i etapper: rapporteringsskyldigheterna från den 11 september 2026 och huvudbestämmelserna från den 11 december 2027. Du väljer verktyg för de tekniska delarna av det arbetet. Vi bygger CRACI, så väg in det. Vi beskriver varje verktyg utifrån dess egen dokumentation och säger var ett annat verktyg passar bättre.

En regel genomsyrar den här sidan. Efterlevnad är en process som tillverkaren driver, med riskbedömning, dokumentation och bedömning av överensstämmelse. Verktyg tar fram bevis och automatiserar delar av arbetet. Inget av verktygen nedan gör en produkt regelefterlevande på egen hand.

Vad CRA kräver

För programvarans leveranskedja gör fem krav det mesta av jobbet.

1. En SBOM. Tillverkare identifierar och dokumenterar komponenterna i produkten, "bland annat genom att upprätta en programvaruförteckning i ett allmänt använt och maskinläsbart format som åtminstone omfattar produkternas beroenden på högsta nivå" (bilaga I, del II). Bilaga VII placerar den i den tekniska dokumentationen, som en marknadskontrollmyndighet kan begära.
2. Sårbarhetshantering. Hantera och åtgärda sårbarheter utan dröjsmål, bland annat genom säkerhetsuppdateringar, testa regelbundet och tillämpa en policy för samordnat offentliggörande av sårbarheter (bilaga I, del II).
3. Rapportering. Anmäl aktivt utnyttjade sårbarheter och allvarliga incidenter till din CSIRT och till ENISA via CRA:s gemensamma rapporteringsplattform: en tidig varning inom 24 timmar, en anmälan inom 72 timmar och en slutrapport senast 14 dagar efter att en åtgärd eller begränsning finns tillgänglig för en sårbarhet, eller inom en månad för en allvarlig incident (artikel 14).
4. Bevis. Teknisk dokumentation, en bedömning av överensstämmelse och en EU-försäkran om överensstämmelse (artiklarna 28, 31 och 32, bilaga VII), tillgängliga för myndigheterna i minst 10 år efter att produkten släppts ut på marknaden eller under supportperioden, beroende på vilken som är längst (artikel 13).
5. En supportperiod. En period som speglar hur länge produkten förväntas användas, minst fem år om inte den förväntade användningen är kortare, under vilken sårbarheter hanteras effektivt (artikel 13).

Hur du väljer

• Vilken halva av arbetet behöver du hjälp med? Tekniska verktyg tar fram SBOM:en, sårbarhetsregistreringarna och bevisen från bygget. Plattformar för efterlevnadshantering kopplar krav till kontroller, tar fram utkast till policyer och håller koll på processen. De flesta verktyg är starka i en halva, så avgör vilken lucka som är störst.
• Bygger du programvaran, eller integrerar du den? Om en stor del av produkten kommer från chipleverantörer och andra leverantörer som binärer är binäranalys sättet att se in i den. Om du bygger den själv är bygget den mest direkta källan till bevis.
• Var kommer din SBOM ifrån, och hur vet du att den är komplett? Skannrar, frågor till byggverktyg och registrering av bygget kan ge olika svar för samma release.
• Kan du hitta berörda releaser inom några timmar? En tidig varning inom 24 timmar förutsätter en inventering per release som du litar på.
• Behöver du ett auktoritativt register? Med många produkter och leverantörer blir SBOM-hantering med VEX och delning ett eget jobb.

I korthet

Två tabeller: först verktyg för SBOM, SCA och SBOM-hantering, sedan verktyg byggda för firmware och enheter. Raderna följer kraven ovan. "Ej angivet" betyder att leverantörssidorna vi hänvisar till inte säger något åt något håll.

SBOM, SCA och SBOM-hantering

Firmware och enheter

CRACI

CRACI är en runner för GitHub Actions. För programvara du bygger registrerar den vad varje jobb hämtade, inklusive paket som återställs från CI-cachar, och tar fram en SBOM i CycloneDX eller SPDX med en fullständighetsstatus per jobb och per cache. Den fortsätter att omvärdera SBOM:erna för det som levererats, har stöd för VEX och lämnar in CRA-anmälningarna åt dig när en aktivt utnyttjad sårbarhet måste rapporteras. För Yocto registrerar den det som Yoctos egen SPDX-utdata utelämnar. Hjälper med: SBOM-generering, sårbarhetshantering, CRA-anmälningar, bevis. Tänk på: den analyserar inte binärer som du inte har byggt, saknar koppling till kontroller och policyhantering och har i dag stöd för GitHub Actions (GitLab CI och Jenkins finns på roadmapen). CRA-efterlevnad med CRACI

SBOM-hantering

Cybeats

Cybeats SBOM Studio kallar sig "the SBOM system of record". Det lagrar SBOM:er från dina produkter och leverantörer i SPDX 2.2 till 3.0.1 och CycloneDX 1.2 till 1.7, validerar dem med en Quality Score före import, matchar varje komponent mot sårbarhetsinformation, utfärdar VEX och delar SBOM:er med kunder, även via Transparency Exchange API. Dess guide om regelverk beskriver CRA:s tidslinje med 24 timmar, 72 timmar och 14 dagar. Hjälper med: SBOM-hantering, sårbarhetshantering, bevis. Tänk på: för genereringen hänvisar det till leverantörer i sin Marketplace, så själva SBOM:en kommer från ett annat verktyg. CRACI vs Cybeats och alternativ till Cybeats

FOSSA

FOSSA började med licensefterlevnad och täcker nu hela livscykeln för SBOM:er. Det genererar SBOM:er i SPDX och CycloneDX, valfritt med VDR- eller VEX-utlåtanden, importerar leverantörers SBOM:er med policyer för NTIA:s och FDA:s minimielement, bevakar dem för sårbarheter och delar dem via en SBOM Portal i Enterprise. Per september 2026 finns en gratisplan, och Business kostar $20 per projekt och månad vid årsfakturering. Hjälper med: SBOM, delning med myndigheter, licenser. Tänk på: FOSSA CLI analyserar projektet via dess byggverktyg eller härleder från källkoden, i stället för att registrera bygget. CRACI vs FOSSA

Anchore

Anchore Enterprise bygger på Syft och Grype med öppen källkod. Det skannar containeravbilder, filsystem och importerade SBOM:er, skannar om lagrade SBOM:er utan den ursprungliga artefakten, tillämpar policypaket som FedRAMP och NIST och körs självhostat, även i isolerade miljöer. Dess CRA-material täcker SBOM-hantering, bevakning mot källor som CISA KEV, stöd för tidsfönstren på 24 och 72 timmar, VEX-anteckningar och granskningsspår. Hjälper med: SBOM, sårbarhetshantering, bevis. Tänk på: dess SBOM:er beskriver vad en skanner hittar i en avbild eller katalog, inte vad bygget hämtade och lämnade efter sig. CRACI vs Anchore

SCA-sviter

Black Duck

Black Duck SCA kombinerar skanning av pakethanterare, signaturer, kodsnuttar och binärer, så det hittar öppen källkod som ingen deklarerat, och dess KnowledgeBase håller reda på mer än 2 750 licenser. Binary Analysis undersöker firmware utan källkod, Coverity står för SAST med ett CRA-anpassat kontrollalternativ som tillkännagavs i juli 2026, och Defensics gör fuzztestning. Black Duck hävdar att CRA kräver flera lager av testning, inte bara SCA. Hjälper med: SBOM, sårbarhetshantering för komponenter och din egen kod, testning. Tänk på: priserna är offertbaserade, och varje teknik granskar kod eller resultat i stället för bygget. CRACI vs Black Duck

Sonatype

Sonatype Lifecycle tillämpar policyer för öppen källkod med data om nåbarhet och uppgraderingar och öppnar Golden Pull Requests. Repository Firewall sätter komponenter som inte klarar policyn i karantän innan de når dina förråd. SBOM Manager importerar, bevakar och delar SBOM:er med ett VEX-arbetsflöde, och Sonatype positionerar det som sin CRA-produkt; företagets guide pekar också på Nexus Repository som uppdateringsplats för säkerhetsuppdateringar. Hjälper med: sårbarhetshantering, SBOM-hantering, att hålla dåliga komponenter ute. Tänk på: paketeringen håller på att ändras (nya kunder köper Sonatype Guide), och Lifecycle analyserar vad bygget producerade i stället för vad det hämtade. CRACI vs Sonatype

Firmware och enheter

ONEKEY

ONEKEY analyserar kompilerad firmware utan att "källkod eller nätverksåtkomst behövs". Det genererar en SBOM från binären, importerar leverantörers SBOM:er, letar efter troliga nolldagssårbarheter som hårdkodade inloggningsuppgifter och analyserar om firmware dagligen. Dess Compliance Wizard leder team genom CRA, IEC 62443-4-2, ETSI EN 303 645 och radioutrustningsdirektivet. Hjälper med: SBOM för firmware du inte har byggt, sårbarhetshantering, guidade kontroller. Tänk på: det arbetar på avbilden efter bygget, så det registrerar inte vad bygget hämtade. CRACI vs ONEKEY och alternativ till ONEKEY

Finite State

Finite State analyserar firmware, binärer, källkod och leverantörers SBOM:er, med stöd för mer än 50 instruktionsuppsättningar för binärer, och samlar dem i en produktregistrering. Det rangordnar fynd efter nåbarhet och information om exploateringar, registrerar VEX-beslut, och dess efterlevnadsarbetsflöde täcker koppling av CRA-kontroller och granskningsklara rapporter med SBOM- och VEX-artefakter. Hjälper med: SBOM över leverantörer, triage av sårbarheter, bevis. Tänk på: det utgår från artefakter, så att styra vad ditt eget bygge kunde nå ligger utanför dess område. CRACI vs Finite State och alternativ till Finite State

Exein

Exein arbetar på enheten. Exein Runtime använder eBPF för att övervaka och blockera skadligt beteende på inbyggda Linux-system, och Yocto-lagret meta-exein med öppen källkod lägger in Pulsar-agenten i din avbild. Exein Analyzer skannar firmware före release, eller din SBOM när binären inte finns tillgänglig, prioriterar med nåbarhetspoäng och kopplar fynd till CRA:s krav. Hjälper med: sårbarhetshantering i fält, SBOM för firmware, koppling till CRA. Tänk på: Yocto-lagret ändrar vad som körs på enheten; det kör eller registrerar inte ditt bygge. CRACI vs Exein

Plattformar för efterlevnadshantering

De här verktygen genererar inte SBOM:er och skannar inte kod. De arbetar med styrningshalvan: att koppla CRA:s krav till kontroller, ta fram utkast till policyer och hålla koll på tidsfrister och godkännanden. De behöver tekniska bevis från annat håll.

Venvera

Venvera är en efterlevnadsplattform byggd i EU som täcker CRA bredvid NIS2, DORA, ISO 27001 och SOC 2. För CRA håller den koll på rapporteringsfristerna på 24 och 72 timmar, sårbarhetshanteringen, SBOM:en som ett krav som ska underhållas, vägen till bedömning av överensstämmelse per produktklass samt den tekniska dokumentationen enligt bilaga VII och EU-försäkran om överensstämmelse. Hjälper med: koppling till kontroller, rapporteringsfrister, uppföljning av processen för överensstämmelse. Tänk på: den håller koll på att en SBOM finns och underhålls; själva SBOM:en kommer från ett annat verktyg.

ZeroRisk

ZeroRisk är en agentbaserad efterlevnadsplattform som täcker GDPR, ISO 27001, SOC 2, NIS2, DORA och CRA. För CRA kopplar dess agent kraven till din organisation, fyller i förväg i en beredskapsbedömning, tar fram utkast till saknade kontroller och policyer och bevakar leverantörerna i dina produkter, med ny kontroll var 24:e timme och mänskligt godkännande av varje slutsats. Hjälper med: beredskap, policyer, leverantörssäkring. Tänk på: dess CRA-sida nämner inte SBOM-generering eller sårbarhetsbevakning av dina egna byggen.

Rapportera inom tidsfristerna

Artikel 14 lägger anmälan på tillverkaren, och den har gällt sedan den 11 september 2026, även för produkter som redan finns på marknaden. Det verktyg kan göra är att korta tiden mellan "den här sårbarheten utnyttjas" och "vi vet vilka produkter och releaser som innehåller den". Det förutsätter inventeringar per release som du litar på, löpande bevakning och en koppling från varje levererad artefakt till dess komponenter. Anchore och Cybeats beskriver rapporteringsfönstren i sitt CRA-material, Venvera håller koll på fristerna, och binäranalys från ONEKEY, Finite State eller Exein täcker leverantörskod som du inte kan bygga om. CRACI:s API returnerar SBOM:er, nätverksspårningar och proveniens, och CRACI lämnar in den tidiga varningen, anmälan och slutrapporten för tillverkarens räkning.

Hur CRACI passar in

CRACI är en runner för GitHub Actions. För programvara du bygger registrerar den vad varje jobb hämtade, inklusive paket som återställs från CI-cachar, och tar fram en SBOM i CycloneDX eller SPDX med en fullständighetsstatus per jobb och per cache. Den upprätthåller en egress-policy för bygget, fortsätter att omvärdera SBOM:erna för det som levererats, har stöd för VEX och exporterar SBOM:er i CycloneDX eller SPDX, inklusive sårbarheter, för dina CRA-bevis. När en aktivt utnyttjad sårbarhet måste rapporteras lämnar CRACI in CRA-anmälningarna åt dig. För Yocto kör den BitBake på runners med upp till 32 vCPU och 96 GB RAM och registrerar det som Yoctos egen SPDX-utdata utelämnar, som värdsystemets paket och paket-URL:er för Rust-crates. CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt. CRACI automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som företag behöver för sitt bredare arbete med CRA-efterlevnad.

Den räcker inte ensam om större delen av din produkt kommer från leverantörer som binärer, eller om du behöver guidade kontroller mot standarder, koppling till kontroller och policyhantering, skydd på enheten eller andra CI-system än GitHub Actions i dag (GitLab CI och Jenkins finns på roadmapen). För de byggen du äger täcker CRACI SBOM:en, bevakningen och CRA-anmälningarna i en produkt; för firmware du inte kan bygga om ser binäranalys det som ditt bygge aldrig såg. Se vad CRA är, CRA-efterlevnad och industriell IoT.

Verktyg för CRA-efterlevnad: vanliga frågor

Vad programvara för CRA-efterlevnad gör, och vad som ligger kvar hos tillverkaren

Vad är programvara för CRA-efterlevnad?

Programvara som hjälper en tillverkare att uppfylla Cyber Resilience Act. Den finns i två slag: tekniska verktyg som tar fram SBOM:en, sårbarhetsregistreringarna och bevisen från bygget, och plattformar för efterlevnadshantering som kopplar kraven till kontroller och håller koll på rapporteringsfristerna, riskbedömningen och bedömningen av överensstämmelse. Ingen av dem gör en produkt regelefterlevande på egen hand.

Vilka CRA-skyldigheter kan ett verktyg automatisera?

Främst sårbarhetshanteringen: att generera SBOM:en, bevaka den för nya sårbarheter, hitta berörda releaser, registrera triage- och VEX-beslut, förbereda och lämna in anmälningarna enligt artikel 14 och exportera bevis för den tekniska dokumentationen. Riskbedömningen, den säkra designen, bedömningen av överensstämmelse och försäkran om överensstämmelse förblir tillverkarens beslut.

Behöver jag ett verktyg eller flera?

Oftast fler än ett. Ett tekniskt verktyg ger dig SBOM:en och bevisen om sårbarheter; en plattform för efterlevnadshantering eller en konsult täcker kontroller, policyer och vägen till överensstämmelse. För firmware som du får från leverantörer som binärer tillför binäranalys det som ditt eget bygge inte kan se.

Vilken är tidsfristen för CRA-rapportering?

Artikel 14 har gällt sedan den 11 september 2026: en tidig varning inom 24 timmar från att du fått kännedom om en aktivt utnyttjad sårbarhet, en anmälan inom 72 timmar och en slutrapport senast 14 dagar efter att en åtgärd eller begränsning finns tillgänglig. Den omfattar produkter som redan finns på marknaden. Resten av CRA gäller från den 11 december 2027.

Lämnar CRACI in CRA-anmälningar?

Ja. CRACI lämnar in den tidiga varningen, anmälan och slutrapporten för tillverkarens räkning. Rapporteringsskyldigheten ligger kvar hos tillverkaren.

Utför något verktyg CRA:s bedömning av överensstämmelse?

Inget programvaruverktyg ersätter den. Tillverkaren genomför bedömningen, genom intern kontroll eller, för viktiga och kritiska produkter, med ett anmält organ eller en certifieringsordning där CRA kräver det. Verktygen levererar bevisen som bedömningen använder.