Sammenligning
CRACI vs NetRise
NetRise ser ind i den kompilerede software, der kører på enheder, uanset hvor den kom fra. CRACI registrerer, hvad dine egne builds trak ind, mens de kørte. Et produktsikkerhedsteam har som regel brug for begge svar, til forskellige dele af det, teamet leverer.
Opdateret
Det korte svar
NetRise er en virksomhed inden for binæranalyse. Dets produkt Turbine analyserer firmware, container-images og applikationsbinærfiler for at producere en SBOM ud fra den kompilerede kode og finde risici i den, herunder sårbarheder, eksponerede secrets, fejlkonfigurationer og kryptografi. Dragos meddelte den 21. september 2026, at det havde opkøbt NetRise. CRACI er en GitHub Actions-runner, der registrerer, hvad hvert build trækker ind, mens det kører, producerer SBOM'en ud fra den registrering og overvåger den efter release. NetRise analyserer outputtet, også software, du ikke selv har bygget; CRACI gemmer dokumentation fra de builds, du kører. For et PSIRT dækker de to forskellige områder.
Overblik
| Funktion | CRACI | NetRise |
|---|---|---|
| Kører dine CI-builds | Jobs kører på CRACI-runnere | Analyserer det kompilerede artefakt |
| Registrerer, hvad buildet hentede | Observeret af runneren under hvert job | Arbejder ud fra den leverede software |
| SBOM fra den færdige binærfil eller firmware | Inkluderer statisk linket og indlejret kode | |
| Virker på firmware, du ikke selv har bygget | Kræver, at buildet kører på CRACI | Software, du bygger, køber og kører |
| Fund ud over kendte CVE'er | Secrets, nøgler, certifikater, fejlkonfigurationer | |
| Reachability-analyse | Eksekveringssti til den sårbare komponent | |
| SBOM i CycloneDX og SPDX | Fra buildet, med en fuldstændighedsstatus | Import, berigelse og eksport af begge formater |
| Leverandørers SBOM'er | Leverandørers SBOM'er kan tilføjes | Upload, kombinér og berig |
| Overvågning efter release | Genvurderer løbende overvågede SBOM'er | Tjekker løbende NVD, CISA KEV og trusselsdata |
| Sårbarhedstriage og VEX | Triage, videresendelse til teams og VEX | Workflows i Jira og ServiceNow; VEX ikke oplyst |
| Egress-politik, mens buildet kører | Kontrolleres før jobbet, blokerer ved fejl (fail closed) | Ikke oplyst; Provenance blokerer pakker efter politik |
| CI-systemer | GitHub Actions i dag; GitLab CI og Jenkins på roadmappen | GraphQL API til CI/CD; GitHub angivet som input |
| Priser | Betal pr. build-minut: $0.004 pr. minut for 2 vCPU, målt pr. sekund. Intet månedligt gebyr og ingen betaling pr. SBOM. | Ikke offentliggjort |
- Inkluderet
- Delvist
- Ikke inkluderet
Hvad NetRise gør godt
SBOM'er fra den kompilerede kode. NetRise Turbine producerer "a complete, binary-derived SBOM from the software itself," inklusive statisk linkede og indlejrede afhængigheder. Det dækker firmware, container-images og applikationsbinærfiler, helt ned til kerner, RTOS, drivere og firmware under applikationslaget. Sådan ser du ind i software fra chipleverandører, modulleverandører og andre leverandører, hvis builds du aldrig ser.
Risici, som en CVE-scanning ikke viser. Turbine rapporterer secrets, offentlige og private nøgler, certifikater og fejlkonfigurationer, der følger med i artefaktet, sammen med licensproblemer og et kryptografi-inventar til post-kvante-parathed. NetRise ZeroLens leder efter svagheder i kompileret software, før de bliver udnyttet.
Prioritering. Turbine tjekker, om en sporbar eksekveringssti forbinder et kørende indgangspunkt med en sårbar komponent, og viser signaler om udnyttelighed såsom CISA KEV-status. NetRise siger, at platformen løbende scanner NVD, CISA KEV-kataloget, trusselsaktørgrupper og botnets for indsigt i udnyttelighed.
Leverandørers SBOM'er og integrationer. NetRise understøtter import, berigelse, normalisering og eksport af SPDX og CycloneDX, så SBOM'er fra flere kilder kan kombineres. Det tilbyder et GraphQL API til CI/CD og angiver integrationer med Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub og Google Cloud.
Open source-oprindelse. NetRise Provenance ser på oprindelse, maintainers og repository-sundhed for open source-komponenter og blokerer ondsindede pakker og pakker, der overtræder politikker, dér hvor udviklere henter dem, også i CI/CD og AI-kodeassistenter.
Nu en del af Dragos. Dragos' meddelelse siger, at NetRise tilføjer synlighed i den firmware og software, der kører på enheder til operationel teknologi, og at NetRises ledelse vil integrere det i Dragos Platform og samtidig fortsætte med at betjene eksisterende kunder. Der blev ikke oplyst nogen finansielle vilkår.
Hvor CRACI er anderledes
En binæranalyse arbejder baglæns fra det, der blev leveret. CRACI arbejder forlæns fra buildet, fordi buildet kører på CRACI.
Buildet er sandhedskilden
Dit workflow kører på CRACI's runnere med en ændring på én linje af runs-on. Mens et job kører, registrerer en pakkebevidst proxy, hvad det downloader fra pakkekilder, og pakker gendannet fra CI-caches føres videre. Hver SBOM angiver, hvor komplet den er, pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Til Yocto kører CRACI BitBake på runnere med op til 32 vCPU og 96 GB RAM. I et sammenlignende build af core-image-sato indeholdt CRACI's SBOM alle komponenter i Yoctos eget SPDX-output, 88 flere, såsom værtspakker og GitHub Actions, og en package URL for hver af de 653 versioner af Rust-crates, som Yocto lister uden en.
Kontrol over, hvad buildet kan nå
En egress-politik på runneren afgør, hvilke hosts et job må oprette forbindelse til. Den valideres, før jobbet starter, blokerer ved fejl (fail closed) og sender en advarsel ved en overtrædelse. En scanning af outputtet kan ikke ændre, hvad buildet kunne nå.
Fra en CVE til de berørte produkter
CRACI samler sårbarheder på tværs af builds og repositories og bliver ved med at genvurdere overvågede SBOM'er, efterhånden som advisories dukker op. Build-historikken viser, hvilke builds der indeholdt en sårbar afhængighed, direkte eller transitiv, så du ved, i hvilken periode du var berørt, og inventaroversigten viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter. Sikkerhedsteams triagerer fund og sender hvert enkelt videre til det team, der ejer rettelsen, VEX understøttes, og policy gates kan blokere et build, der indeholder en bestemt CVE. API'et returnerer SBOM'er, netværkstraces og provenance.
Det, CRACI ikke gør, er lige så vigtigt. Det analyserer ikke binærfiler, så det kan ikke se ind i firmware, du ikke selv har bygget, eller en leverandør-blob, dit build downloader; det ser kun, at buildet hentede den, og hvorfra. Du kan tilføje leverandørers SBOM'er, så deres komponenter overvåges, men uden en SBOM har du brug for et værktøj til binæranalyse som NetRise. CRACI har ingen reachability-analyse og leder ikke efter secrets eller fejlkonfigurationer i outputtet.
Hvad et PSIRT har brug for fra hver
Et product security incident response team skal vide, hvad der følger med i hvert produkt, inklusive tredjepartsfirmware, finde de berørte produkter, når en sårbarhed lander, blive ved med at overvåge efter release, triagere fund og sige, hvilke produkter der ikke er berørt, ofte med VEX.
- Tredjepartsfirmware og binærfiler, du modtager. NetRise. Binæranalyse er den eneste måde at se ind i dem på, når leverandøren ikke sender en SBOM.
- Firmware og software, du bygger i GitHub Actions. CRACI registrerer hvert build, mens det kører, og gemmer historikken over, hvilke builds der indeholdt en komponent.
- Prioritering af en lang liste af fund. NetRises signaler om reachability og udnyttelighed. CRACI viser, at en sårbar pakke var med i buildet, ikke om din kode kalder den.
- Videresendelse af et fund til det team, der ejer rettelsen. CRACI's triage og videresendelse virker på de builds, det registrerer; NetRise forbinder sig til Jira og ServiceNow.
Se CRACI til PSIRT-teams og PSIRT-værktøjer sammenlignet.
Hvornår du skal bruge hvilken, og hvornår du skal bruge begge
- Det meste af det, du leverer, kommer fra leverandører. NetRise. Det analyserer software, du køber, såvel som software, du bygger.
- Du bygger dit eget Linux-image eller dine egne apps i GitHub Actions. CRACI kører buildet og registrerer dets input. Analyserer du det samme image i NetRise, får du et ekstra, uafhængigt billede af det, der blev leveret.
- Du driver flåder af operationel teknologi. NetRise, nu inde i Dragos, er rettet mod den firmware og software, der kører på de enheder. CRACI er til teams, der bygger softwaren.
- Du vil begrænse, hvad builds kan downloade. CRACI. Den kontrol findes kun dér, hvor buildet kører.
Til CRA
Cyber Resilience Act kræver, at producenter dokumenterer komponenterne i deres produkter, herunder med en SBOM, håndterer sårbarheder gennem supportperioden og siden 11. september 2026 rapporterer aktivt udnyttede sårbarheder. NetRise tager fat på CRA med SBOM'er for release-builds fra det kompilerede artefakt, sårbarhedshåndtering og verificering af patches på tværs af versioner samt rapporteringsoutput til dokumentation af overensstemmelse. CRACI producerer dokumentation pr. build for, hvad der gik ind i den software, du bygger, overvåger den og indsender CRA-underretningerne på dine vegne. CRACI automatiserer en væsentlig del af den synlighed i og dokumentation for softwareforsyningskæden, som producenter har brug for i deres bredere CRA-compliance-proces; det gør ikke et produkt compliant alene. Læs hvad CRA kræver.
Tilføj CRACI ved siden af NetRise
Intet behøver at flyttes væk fra NetRise. Flyt build-jobbet til en CRACI-runner ved at sætte runs-on: craci, så bliver det samme workflow ved med at køre i GitHub Actions, mens CRACI registrerer buildet. Yocto-eksemplet i CRACI's dokumentation viser et komplet BitBake-workflow. CRACI understøtter kun GitHub Actions i dag, med GitLab CI og Jenkins på roadmappen. Se, hvordan CRACI fungerer til industriel IoT.
Overvejer du mere end to værktøjer? Alternativer til NetRise sammenligner syv muligheder side om side.
Tag et firmware-build med til demoen
Book en demo, så kører vi et af dine GitHub Actions-builds på CRACI og gennemgår, hvad det hentede.
Book en demo