CRACI vs NetRise

Det korta svaret

NetRise är ett företag inom binäranalys. Produkten Turbine analyserar firmware, containeravbilder och applikationsbinärer för att ta fram en SBOM från den kompilerade koden och hitta risker i den, bland annat sårbarheter, exponerade hemligheter, felkonfigurationer och kryptografi. Dragos meddelade den 21 september 2026 att företaget har förvärvat NetRise. CRACI är en GitHub Actions-runner som registrerar vad varje bygge drar in medan det körs, tar fram SBOM:en från den registreringen och bevakar den efter release. NetRise analyserar resultatet, även programvara du inte har byggt; CRACI sparar bevis från byggena du kör. För ett PSIRT täcker de två olika områden.

I korthet

Vad NetRise gör bra

SBOM:er från den kompilerade koden. NetRise Turbine tar fram "a complete, binary-derived SBOM from the software itself," inklusive statiskt länkade och inbäddade beroenden. Det täcker firmware, containeravbilder och applikationsbinärer, ner till kärnor, RTOS, drivrutiner och firmware under applikationslagret. Det är sättet att se inuti programvara från kretsleverantörer, modulleverantörer och andra leverantörer vars byggen du aldrig ser.

Risker som en CVE-skanning inte visar. Turbine rapporterar hemligheter, publika och privata nycklar, certifikat och felkonfigurationer som levereras inuti artefakten, tillsammans med licensproblem och en kryptografiinventering för postkvantberedskap. NetRise ZeroLens letar efter svagheter i kompilerad programvara innan de utnyttjas.

Prioritering. Turbine kontrollerar om en spårbar exekveringsväg kopplar en körande ingångspunkt till en sårbar komponent och visar exploateringssignaler som status i CISA KEV. NetRise säger att plattformen löpande skannar NVD, CISA KEV-katalogen, hotaktörsgrupper och botnät för insikt i exploaterbarhet.

Leverantörers SBOM:er och integrationer. NetRise har stöd för import, berikning, normalisering och export av SPDX och CycloneDX, så att SBOM:er från flera källor kan kombineras. Det erbjuder ett GraphQL-API för CI/CD och listar integrationer med Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub och Google Cloud.

Ursprung för öppen källkod. NetRise Provenance tittar på ursprung, underhållare och repohälsa för komponenter med öppen källkod och blockerar skadliga paket och paket som bryter mot policyn där utvecklare hämtar dem, bland annat i CI/CD och AI-kodassistenter.

Nu en del av Dragos. Enligt Dragos meddelande ger NetRise insyn i firmware och programvara som körs på enheter för operativ teknik, och NetRises ledning ska integrera det i Dragos-plattformen samtidigt som befintliga kunder fortsätter att få service. Inga ekonomiska villkor har offentliggjorts.

Där CRACI skiljer sig

En binäranalys arbetar bakåt från det som levererades. CRACI arbetar framåt från bygget, eftersom bygget körs på CRACI.

Bygget är sanningskällan

Ditt arbetsflöde körs på CRACI:s runners med en ändring på en rad i runs-on. Medan ett jobb körs registrerar en paketmedveten proxy vad det laddar ner från paketkällor, och paket som återställs från CI-cachar följer med. Varje SBOM anger hur komplett den är, per jobb och per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. För Yocto kör CRACI BitBake på runners med upp till 32 vCPU och 96 GB RAM. I ett bygge av core-image-sato sida vid sida hade CRACI:s SBOM varje komponent i Yoctos egen SPDX-utdata, 88 till, som värdsystemets paket och GitHub Actions, och en paket-URL för var och en av de 653 versioner av Rust-crates som Yocto listar utan någon.

Kontroll över vad bygget kan nå

En egress-policy på runnern avgör vilka värdar ett jobb får ansluta till. Den valideras innan jobbet startar, blockerar vid fel och skickar en varning vid en överträdelse. En skanning av resultatet kan inte ändra vad bygget kunde nå.

Från en CVE till de berörda produkterna

CRACI sammanställer sårbarheter över byggen och repon och fortsätter att omvärdera bevakade SBOM:er när nya säkerhetsmeddelanden dyker upp. Bygghistoriken visar vilka byggen som innehöll ett sårbart beroende, direkt eller transitivt, så att du vet under vilken period du var berörd, och inventeringsvyn visar exakt vilka programvaruversioner som är driftsatta i vilka produkter. Säkerhetsteam triagerar fynd och skickar vart och ett till teamet som äger åtgärden, VEX stöds, och policyspärrar kan blockera ett bygge som innehåller en viss CVE. API:t returnerar SBOM:er, nätverksspårningar och proveniens.

Vad CRACI inte gör är lika viktigt. Det analyserar inte binärer, så det kan inte se inuti firmware du inte har byggt eller en leverantörsblob som ditt bygge laddar ner, bara att bygget hämtade den och varifrån. Du kan lägga till leverantörers SBOM:er så att deras komponenter bevakas, men utan en SBOM behöver du ett binäranalysverktyg som NetRise. CRACI har ingen reachability-analys och letar inte efter hemligheter eller felkonfigurationer i resultatet.

Vad ett PSIRT behöver från vart och ett

Ett team för incidenthantering inom produktsäkerhet måste veta vad som levereras i varje produkt, inklusive firmware från tredje part, hitta de berörda produkterna när en sårbarhet dyker upp, fortsätta att bevaka efter release, triagera fynd och säga vilka produkter som inte är berörda, ofta med VEX.

• Firmware och binärer från tredje part som du tar emot. NetRise. Binäranalys är det enda sättet att se inuti dem när leverantören inte skickar någon SBOM.
• Firmware och programvara du bygger i GitHub Actions. CRACI registrerar varje bygge medan det körs och sparar historiken över vilka byggen som innehöll en komponent.
• Prioritera en lång lista med fynd. NetRises signaler för reachability och exploaterbarhet. CRACI visar att ett sårbart paket fanns i bygget, inte om din kod anropar det.
• Skicka ett fynd till teamet som äger åtgärden. CRACI:s triage och routning fungerar på byggena det registrerar; NetRise ansluter till Jira och ServiceNow.

Se CRACI för PSIRT-team och PSIRT-verktyg i jämförelse.

När du ska använda vilket, och när du ska använda båda

• Det mesta du levererar kommer från leverantörer. NetRise. Det analyserar programvara du köper likaväl som programvara du bygger.
• Du bygger din egen Linux-avbild eller dina egna appar i GitHub Actions. CRACI kör bygget och registrerar det som går in i det. Om du analyserar samma avbild i NetRise får du en andra, oberoende bild av vad som levererades.
• Du driver flottor av operativ teknik. NetRise, nu inom Dragos, riktar sig till firmware och programvara som körs på de enheterna. CRACI är till för team som bygger programvaran.
• Du vill begränsa vad byggen kan ladda ner. CRACI. Den kontrollen finns bara där bygget körs.

För CRA

Cyber Resilience Act kräver att tillverkare dokumenterar komponenterna i sina produkter, bland annat med en SBOM, hanterar sårbarheter under supportperioden och, sedan den 11 september 2026, rapporterar aktivt utnyttjade sårbarheter. NetRise tar sig an CRA med SBOM:er för release-byggen från den kompilerade artefakten, sårbarhetshantering och verifiering av patchar över versioner, och rapportunderlag som bevis på överensstämmelse. CRACI tar fram bevis per bygge om vad som ingick i programvaran du bygger, bevakar den och lämnar in CRA-anmälningarna åt dig. CRACI automatiserar en betydande del av den insyn i och de bevis om programvarans leveranskedja som tillverkare behöver för sitt bredare arbete med CRA-efterlevnad; det gör inte en produkt regelefterlevande på egen hand. Läs vad CRA kräver.

Lägg till CRACI bredvid NetRise

Inget behöver flyttas från NetRise. Flytta byggjobbet till en CRACI-runner genom att sätta runs-on: craci, så fortsätter samma arbetsflöde att köras i GitHub Actions medan CRACI registrerar bygget. Yocto-exemplet i CRACI:s dokumentation visar ett komplett BitBake-arbetsflöde. CRACI har i dag stöd för enbart GitHub Actions, med GitLab CI och Jenkins på roadmapen. Se hur CRACI fungerar för industriell IoT.

Väger du fler än två verktyg? Alternativ till NetRise jämför sju alternativ sida vid sida.