123% flere rapporterede CVE'er pr. dag i 2026 end sidste år.

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

Hjemmesiden for NetRise
netrise.io

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