See What Changed. Prove What Improved. Fix Real Risk.
Knowing a vulnerability exists is not the same as knowing it can execute.
Every firmware image and software package you analyze contains hundreds — sometimes thousands — of components. Those components carry CVEs. Most security platforms surface all of them. Teams sort by severity, filter by CVSS score, and try to work through the list. But the question that actually matters — which of these vulnerabilities can be reached and executed in this environment — rarely gets answered with precision.
Last year, we introduced reachability in the NetRise platform to start closing that gap. It traced execution from system entry points — the services that auto-run at boot, the cron jobs that fire on schedule — through the scripts and binaries they invoke, and connected that chain to the vulnerable components at the end of it. If something running on the device eventually touched a vulnerable library, the CVE was reachable. If no path existed, it wasn't.
That was a real improvement. But the execution graph only went so far.
Today, we're releasing a significant upgrade. Reachability in the NetRise platform now traces deeper into the execution graph — from executing binaries into the shared libraries they load and from running scripts to the credentials and certificates they reference. Across 48 production assets analyzed side-by-side against the previous version, this upgrade surfaces approximately 3 times more reachable vulnerabilities, roughly 2 times more reachable files, and approximately 27 times more reachable shared libraries. Not because there is more risk — because the analysis now sees more of the paths that actually exist.
Reachability also extends beyond vulnerabilities for the first time. Secrets, certificates, and components now carry reachability context in the platform.
The Original Analysis Traced from the OS Into Code. This One Goes Further.
The first version of reachability answered this question well: does any auto-running service on this device eventually invoke a component with this CVE?
It did that by following script command chains from system entry points — systemd, cron — to the components identified at the end of those chains. A three-hop limit kept the analysis tractable. The result was a usable filter: collapse a vulnerability table from hundreds of findings to the ones where execution was at least plausible.
But the graph stopped at the component boundary. Once a library appeared at the end of a script chain, the analysis was done. It couldn't see what that library imported. It had no way to tell whether a credential sitting in the filesystem was referenced by anything that runs.
The upgrade removes those limits. It also expands entry point coverage to include init.d services and OCI container entrypoints — meaning devices that don't use systemd, which previously showed nothing reachable regardless of what was actually running, are now correctly analyzed.
What a More Complete Execution Graph Reveals
Shared libraries that executing binaries actually load. Nearly every firmware image contains shared libraries — across production assets analyzed by NetRise, 98.8% include them. Binaries dynamically link to those libraries at runtime. The upgraded analysis resolves those relationships directly, tracing from executing binaries to the libraries they import, and from those libraries to the ones they import in turn. If a binary is reachable from a system entry point and loads a library containing a CVE, that vulnerability inherits reachability from the binary that loads it. The chain has no depth limit. In practice, this expansion accounts for most of the ~27x increase in reachable shared libraries compared to the previous version — a category of exposure that the original script-chain analysis simply couldn't see.
Credentials referenced by reachable code, not just present on disk. Scripts and configuration files reference certificates, secrets, and keys by explicit file path or identifier. The upgrade detects those references and traces them through the execution graph: if a reachable script or configuration file explicitly loads a credential, that credential inherits reachability from the code that references it. This is intentionally precise — the analysis catches explicit file path references in scripts, not every credential a binary might load from a default directory. That precision is a feature. The credentials and certificates that do get flagged as reachable are high-confidence findings: something that is actively running on the device is explicitly loading them. That's a very different signal than presence alone.
The platform now classifies findings across three states that flow through the vulnerability, secrets, and cryptography views:
Exists — the component or artifact is present in the image.
Reachable — a traceable path connects a system entry point to the artifact through the dependency or import graph.
Executes — the artifact is directly invoked from a system entry point.
An SBOM View With a Reachability Filter
Teams can toggle the component listing to show only components that are reachable from a system entry point — independently of whether those components carry a CVE. This matters because reachability at the component level tells you which parts of your software composition are actively loaded and running, not just present. A component with no known vulnerabilities today can acquire one tomorrow. Knowing it's reachable before that happens means teams aren't starting from zero when a new CVE drops against something already executing in their environment.
Reachability Is Prioritization. The CVEs Are Real Either Way.
The upgrade does not remove CVEs from the platform. A finding classified as Exists is still a real CVE against a real component. The component is present. The association is accurate. If your environment changes — a new entry point is added, a script starts referencing a previously orphaned credential — the reachability classification updates accordingly.
What reachability does is add execution context to every finding. It gives security teams a defensible answer to the question that CVSS scores alone can't answer: which of the vulnerabilities in this image represent exploitable exposure in this device, in this configuration, running this software?
The answer is now traceable through shared library dependency chains and script-to-credential reference paths — and it extends to secrets and certificates for the first time.
What's Next
This release is the second major step in how NetRise traces execution context through firmware and software. The next phase will add Python module import chain analysis — tracing reachability through transitive Python dependencies to the specific modules where vulnerable code lives — with function-level reachability to follow.
The direction is consistent: presence-based reporting describes the software that is in your image. Execution-aware analysis describes the software that actually runs — and now, the dependencies and imports that running software can actually reach.
Need quick help? Chat now with a Real NetRise Expert
Click here➡
No Slack account needed
