CRACI vs NetRise

The short answer

NetRise is a binary analysis company. Its Turbine product analyzes firmware, container images and application binaries to produce an SBOM from the compiled code and to find risk in it, including vulnerabilities, exposed secrets, misconfigurations and cryptography. Dragos announced on September 21, 2026 that it had acquired NetRise. CRACI is a GitHub Actions runner that records what each build pulls in while it runs, produces the SBOM from that record, and monitors it after release. NetRise analyzes the output, including software you did not build; CRACI keeps evidence from the builds you run. For a PSIRT the two cover different ground.

At a glance

What NetRise does well

SBOMs from the compiled code. NetRise Turbine produces "a complete, binary-derived SBOM from the software itself," including statically linked and embedded dependencies. It covers firmware, container images and application binaries, down to kernels, RTOS, drivers and firmware beneath the application layer. That is the way to see inside software from chip vendors, module suppliers and other vendors whose builds you never see.

Risk that a CVE scan does not show. Turbine reports secrets, public and private keys, certificates and misconfigurations that ship inside the artifact, along with license issues and a cryptography inventory for post-quantum readiness. NetRise ZeroLens looks for weaknesses in compiled software before they are exploited.

Prioritization. Turbine checks whether a traceable execution path connects a running entry point to a vulnerable component, and shows exploitability signals such as CISA KEV status. NetRise says the platform continuously scans the NVD, the CISA KEV catalog, threat actor groups and botnets for insight into exploitability.

Supplier SBOMs and integrations. NetRise supports import, enrichment, normalization and export of SPDX and CycloneDX, so SBOMs from several sources can be combined. It offers a GraphQL API for CI/CD and lists integrations with Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub and Google Cloud.

Open-source provenance. NetRise Provenance looks at the origin, maintainers and repository health of open-source components and blocks malicious and policy-violating packages where developers pull them, including in CI/CD and AI coding assistants.

Now part of Dragos. The Dragos announcement says NetRise adds visibility into the firmware and software running on operational technology devices, and that NetRise leadership will integrate it into the Dragos Platform while continuing to serve existing customers. No financial terms were disclosed.

Where CRACI is different

A binary analysis works backward from what shipped. CRACI works forward from the build, because the build runs on CRACI.

The build is the source of truth

Your workflow runs on CRACI's runners with a one-line change to runs-on. While a job runs, a package-aware proxy records what it downloads from package sources, and packages restored from CI caches are carried forward. Each SBOM states how complete it is, per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. For Yocto, CRACI runs BitBake on runners of up to 32 vCPUs and 96 GB of RAM. In a side-by-side build of core-image-sato, CRACI's SBOM had every component in Yocto's own SPDX output, 88 more such as host packages and GitHub Actions, and a package URL for each of the 653 Rust crate versions Yocto lists without one.

Control over what the build can reach

An egress policy at the runner decides which hosts a job may connect to. It is validated before the job starts, fails closed, and sends an alert on a violation. A scan of the output cannot change what the build was able to reach.

From a CVE to the affected products

CRACI aggregates vulnerabilities across builds and repositories and keeps re-evaluating monitored SBOMs as advisories appear. Build history shows which builds contained a vulnerable dependency, direct or transitive, so you know the period you were affected, and the inventory view shows exactly which software versions are deployed to which products. Security teams triage findings and route each one to the team that owns the fix, VEX is supported, and policy gates can block a build that contains a specific CVE. The API returns SBOMs, network traces and provenance.

What CRACI does not do matters just as much. It does not analyze binaries, so it cannot see inside firmware you did not build or a supplier blob your build downloads, only that the build fetched it and from where. You can add vendor SBOMs so their components are monitored, but without an SBOM you need a binary analysis tool such as NetRise. CRACI has no reachability analysis and does not look for secrets or misconfigurations in the output.

What a PSIRT needs from each

A product security incident response team has to know what ships in every product, including third-party firmware, find the affected products when a vulnerability lands, keep monitoring after release, triage findings and say which products are not affected, often with VEX.

• Third-party firmware and binaries you receive. NetRise. Binary analysis is the only way to see inside them when the supplier sends no SBOM.
• Firmware and software you build in GitHub Actions. CRACI records each build as it runs and keeps the history of which builds contained a component.
• Prioritizing a long list of findings. NetRise's reachability and exploitability signals. CRACI shows that a vulnerable package was in the build, not whether your code calls it.
• Routing a finding to the team that owns the fix. CRACI's triage and routing work on the builds it records; NetRise connects to Jira and ServiceNow.

See CRACI for PSIRT teams and PSIRT tools compared.

When to use which, and when to use both

• Most of what you ship comes from suppliers. NetRise. It analyzes software you buy as well as software you build.
• You build your own Linux image or apps in GitHub Actions. CRACI runs the build and records its inputs. Analyzing the same image in NetRise gives a second, independent view of what shipped.
• You run operational technology fleets. NetRise, now inside Dragos, is aimed at the firmware and software running on those devices. CRACI is for teams that build the software.
• You want to limit what builds can download. CRACI. That control only exists where the build runs.

For the CRA

The Cyber Resilience Act asks manufacturers to document the components in their products, including an SBOM, to handle vulnerabilities through the support period, and, since September 11, 2026, to report actively exploited vulnerabilities. NetRise addresses the CRA with release-build SBOMs from the compiled artifact, vulnerability handling and patch verification across versions, and reporting outputs for conformity evidence. CRACI produces per-build evidence of what went into the software you build, monitors it, and submits the CRA notifications on your behalf. CRACI automates a significant part of the software supply chain visibility and evidence that manufacturers need for their wider CRA compliance process; it does not make a product compliant on its own. Read what the CRA requires.

Adding CRACI alongside NetRise

Nothing needs to move out of NetRise. Move the build job to a CRACI runner by setting runs-on: craci, and the same workflow keeps running in GitHub Actions while CRACI records the build. The Yocto example in the CRACI docs shows a full BitBake workflow. CRACI supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap. See how CRACI works for industrial IoT.

Weighing more than two tools? NetRise alternatives compares seven options side by side.