CRACI vs. NetRise

Det korte svaret

NetRise er et selskap som driver med binæranalyse. Produktet Turbine analyserer firmware, container-images og applikasjonsbinærfiler for å produsere en SBOM fra den kompilerte koden og finne risiko i den, inkludert sårbarheter, eksponerte hemmeligheter, feilkonfigurasjoner og kryptografi. Dragos kunngjorde 21. september 2026 at selskapet hadde kjøpt NetRise. CRACI er en GitHub Actions-runner som registrerer hva hvert bygg henter inn mens det kjører, produserer SBOM-en fra den registreringen og overvåker den etter utgivelse. NetRise analyserer resultatet, også programvare du ikke har bygget; CRACI tar vare på dokumentasjon fra byggene du kjører. For et PSIRT dekker de to ulike områder.

Oversikt

Hva NetRise gjør bra

SBOM-er fra den kompilerte koden. NetRise Turbine produserer "a complete, binary-derived SBOM from the software itself," inkludert statisk lenkede og innebygde avhengigheter. Det dekker firmware, container-images og applikasjonsbinærfiler, helt ned til kjerner, RTOS, drivere og firmware under applikasjonslaget. Det er måten å se inn i programvare fra brikkeleverandører, modulleverandører og andre leverandører hvis bygg du aldri ser.

Risiko som en CVE-skanning ikke viser. Turbine rapporterer hemmeligheter, offentlige og private nøkler, sertifikater og feilkonfigurasjoner som følger med inne i artefakten, sammen med lisensproblemer og et kryptografi-inventar med tanke på post-kvante-beredskap. NetRise ZeroLens ser etter svakheter i kompilert programvare før de blir utnyttet.

Prioritering. Turbine sjekker om en sporbar kjøringssti forbinder et kjørende inngangspunkt med en sårbar komponent, og viser signaler om utnyttbarhet som CISA KEV-status. NetRise sier at plattformen kontinuerlig skanner NVD, CISA KEV-katalogen, trusselaktørgrupper og botnett for å gi innsikt i utnyttbarhet.

SBOM-er fra leverandører og integrasjoner. NetRise støtter import, berikelse, normalisering og eksport av SPDX og CycloneDX, så SBOM-er fra flere kilder kan kombineres. Selskapet tilbyr et GraphQL API for CI/CD og oppgir integrasjoner med Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub og Google Cloud.

Opphav for åpen kildekode. NetRise Provenance ser på opphav, vedlikeholdere og repositoriets helse for komponenter med åpen kildekode, og blokkerer ondsinnede pakker og pakker som bryter policy der utviklere henter dem, også i CI/CD og AI-kodeassistenter.

Nå en del av Dragos. Kunngjøringen fra Dragos sier at NetRise tilfører innsyn i firmware og programvare som kjører på enheter for operasjonell teknologi, og at NetRise-ledelsen vil integrere det i Dragos Platform og samtidig fortsette å betjene eksisterende kunder. Ingen økonomiske vilkår ble offentliggjort.

Der CRACI skiller seg ut

En binæranalyse jobber seg bakover fra det som ble levert. CRACI jobber fremover fra bygget, fordi bygget kjører på CRACI.

Bygget er sannhetskilden

Workflowen din kjører på CRACI-runnere med en endring på én linje i runs-on. Mens en jobb kjører, registrerer en pakkebevisst proxy hva den laster ned fra pakkekilder, og pakker gjenopprettet fra CI-cacher blir ført videre. Hver SBOM angir hvor fullstendig den er, per jobb og per cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. For Yocto kjører CRACI BitBake på runnere med opptil 32 vCPU og 96 GB RAM. I et sammenlignende bygg av core-image-sato inneholdt SBOM-en fra CRACI alle komponentene i Yoctos egne SPDX-utdata, 88 til, blant annet vertspakker og GitHub Actions, og en pakke-URL for hver av de 653 Rust-crate-versjonene Yocto lister opp uten en slik.

Kontroll over hva bygget kan nå

En egress-policy på runneren avgjør hvilke verter en jobb kan koble seg til. Den valideres før jobben starter, blokkerer ved feil (fail closed) og sender et varsel ved et brudd. En skanning av resultatet kan ikke endre hva bygget kunne nå.

Fra en CVE til de berørte produktene

CRACI samler sårbarheter på tvers av bygg og repositorier og fortsetter å vurdere overvåkede SBOM-er på nytt etter hvert som advisories dukker opp. Byggehistorikken viser hvilke bygg som inneholdt en sårbar avhengighet, direkte eller transitiv, så du vet i hvilken periode du var berørt, og inventarvisningen viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter. Sikkerhetsteam triagerer funn og sender hvert av dem til teamet som eier rettingen, VEX støttes, og policy gates kan blokkere et bygg som inneholder en bestemt CVE. API-et returnerer SBOM-er, nettverksspor og provenance.

Det CRACI ikke gjør, er like viktig. Det analyserer ikke binærfiler, så det kan ikke se inn i firmware du ikke har bygget eller i en leverandørs binærblob som bygget ditt laster ned, bare se at bygget hentet den og hvor fra. Du kan legge til SBOM-er fra leverandører slik at komponentene deres overvåkes, men uten en SBOM trenger du et verktøy for binæranalyse som NetRise. CRACI har ingen reachability-analyse og ser ikke etter hemmeligheter eller feilkonfigurasjoner i resultatet.

Hva et PSIRT trenger fra hver av dem

Et PSIRT, et team for håndtering av produktsikkerhetshendelser, må vite hva som leveres i hvert produkt, inkludert firmware fra tredjeparter, finne de berørte produktene når en sårbarhet dukker opp, fortsette å overvåke etter utgivelse, triagere funn og si hvilke produkter som ikke er berørt, ofte med VEX.

• Firmware og binærfiler du mottar fra tredjeparter. NetRise. Binæranalyse er den eneste måten å se inn i dem på når leverandøren ikke sender noen SBOM.
• Firmware og programvare du bygger i GitHub Actions. CRACI registrerer hvert bygg mens det kjører, og tar vare på historikken over hvilke bygg som inneholdt en komponent.
• Prioritering av en lang liste med funn. Signalene om reachability og utnyttbarhet i NetRise. CRACI viser at en sårbar pakke var i bygget, ikke om koden din kaller den.
• Å sende et funn til teamet som eier rettingen. Triage og ruting i CRACI fungerer på byggene det registrerer; NetRise kobler seg til Jira og ServiceNow.

Se CRACI for PSIRT-team og PSIRT-verktøy sammenlignet.

Hva du bør bruke når, og når du bør bruke begge

• Det meste av det du leverer, kommer fra leverandører. NetRise. Det analyserer programvare du kjøper, i tillegg til programvare du bygger.
• Du bygger ditt eget Linux-image eller dine egne apper i GitHub Actions. CRACI kjører bygget og registrerer det som går inn i det. Å analysere samme image i NetRise gir et ekstra, uavhengig bilde av hva som ble levert.
• Du drifter enhetsparker med operasjonell teknologi. NetRise, nå en del av Dragos, er rettet mot firmware og programvare som kjører på slike enheter. CRACI er for team som bygger programvaren.
• Du vil begrense hva bygg kan laste ned. CRACI. Den kontrollen finnes bare der bygget kjører.

For CRA

Cyber Resilience Act ber produsenter dokumentere komponentene i produktene sine, inkludert en SBOM, håndtere sårbarheter gjennom støtteperioden og, siden 11. september 2026, rapportere aktivt utnyttede sårbarheter. NetRise tar for seg CRA med SBOM-er for utgivelsesbygg fra den kompilerte artefakten, sårbarhetshåndtering og verifisering av patcher på tvers av versjoner, og rapportering som dokumentasjon på samsvar. CRACI produserer dokumentasjon per bygg på hva som gikk inn i programvaren du bygger, overvåker den og sender CRA-varslene på dine vegne. CRACI automatiserer en betydelig del av innsynet i programvareleverandørkjeden og dokumentasjonen som produsenter trenger for sin bredere CRA-samsvarsprosess; det gjør ikke et produkt samsvarende på egen hånd. Les hva CRA krever.

Slik legger du til CRACI ved siden av NetRise

Ingenting trenger å flyttes ut av NetRise. Flytt byggejobben til en CRACI-runner ved å sette runs-on: craci, så fortsetter samme workflow å kjøre i GitHub Actions mens CRACI registrerer bygget. Yocto-eksempelet i CRACI-dokumentasjonen viser en komplett BitBake-workflow. CRACI støtter bare GitHub Actions i dag, med GitLab CI og Jenkins på veikartet. Se hvordan CRACI fungerer for industriell IoT.

Vurderer du mer enn to verktøy? NetRise-alternativer sammenligner sju alternativer side om side.