Your Reachability Just Got a Lot More Accurate. Here's What Changed.
Washington just mandated something most agencies — and many enterprises — can't actually do yet.
The White House's new Executive Order on AI and Cybersecurity directs federal agencies to defend systems containing AI models and components, build a shared vulnerability clearinghouse, develop a benchmarking process for frontier AI models, and expand AI-enabled cybersecurity tools across government and critical infrastructure. Meeting those requirements demands something most agencies don't yet have: a comprehensive and accurate inventory of the software components actually running in their environments.
These are the right requirements. They reflect a serious, operational understanding of where modern software risk actually lives.
But there is a gap between what the EO requires and what most agencies, and most scanning tools, can currently deliver. Understanding that gap is the first step toward closing it.
Meeting the EO means knowing what's actually running, not what vendors declared.
Traditional security scanning works from declared manifests, what vendors say is in the software, what package managers report, what a developer wrote down. That information is useful, but it describes intentions rather than outcomes.
Compiled software tells a different story: firmware, appliances, containers, and applications routinely carry statically linked libraries, embedded dependencies, and inherited frameworks that a third party built into the binary and no one ever declared. Those components execute, they carry vulnerabilities, and they stay invisible to any scanner that stops at the declaration layer.
You can't benchmark what you haven't found. You can't scope blast radius on components you don't know are running.
That gap is exactly where the EO's hardest requirements live. Section 3 directs Treasury, NSA, and CISA to build a classified benchmarking process for frontier AI models, and Section 2(d) creates a shared clearinghouse to coordinate vulnerability scanning, discovery, and patching across environments.
Neither is achievable from a manifest. Both depend on an accurate account of what's actually present and executing, including the AI frameworks and model files that ship inside vendor products without disclosure. In our own analysis of commercial firmware and appliances, we find these embedded AI components regularly — not deployed knowingly, not documented by the vendor, and not surfaced by the tools agencies rely on today. That is precisely the exposure the EO is trying to close.
Why everything depends on an accurate inventory
An accurate, binary-derived inventory isn't the finish line — it's the input that makes every downstream security decision possible, and almost none of those decisions hold up without it.
Take the moment a component, package, or maintainer is compromised, which is the scenario the clearinghouse exists to coordinate. The first question is how far the damage reaches: which libraries, products, and vendors carry the implicated component, whether directly or through the transitive dependencies that chain one package to dozens of others. That's the blast radius, and it can only be calculated against an inventory of what you actually have. The second question is where you specifically are exposed, which means cross-referencing that blast radius against your own environment. The third, the one that separates a mature program from a reactive one, is whether you can keep the next compromised component out before it ever ships, by enforcing policy at procurement and in the build pipeline.
Every one of those steps depends on the same root. Have an incomplete inventory and the blast radius is ineffective, the exposure assessment misses systems, and the policy has nothing accurate to enforce against. Get it right and the EO's harder objectives fall into sequence, which is why the clearinghouse it envisions is, in practice, the software asset inventory the industry has been circling for years. It's also why this maps cleanly onto the order's twin goals: the control to secure AI-era software without slowing the innovation the EO is explicitly designed to protect.
Seeing What's Actually Running — NetRise TurbineⓇ
NetRise Turbine analyzes compiled artifacts across firmware, containers, kernels, operating systems, applications, and embedded systems — no agents, no source code, no vendor cooperation required. It identifies what software is actually executing and maps vulnerable components to the assets carrying them. Across 200+ artifact types, this includes AI frameworks, model files, and AI-adjacent components that were not knowingly deployed and are not disclosed in vendor documentation, the component inventory that Section 3 benchmarking actually requires.
And the risk it surfaces goes well beyond CVEs. Turbine identifies hard-coded secrets, misconfigurations, exposed public and private keys, and unsafe components — the non-CVE exposures that never appear in a vulnerability feed but routinely become the path an attacker actually takes. Execution-aware reachability then narrows the field to what's genuinely exploitable: it traces from system entry points through the binaries that run, the shared libraries they load, and the scripts that execute, and now extends that same analysis to secrets and certificates. That draws a sharp line between a credential merely present on disk and one that running code is actively loading. For a team triaging exposure under time pressure, that distinction is the difference between a finding that demands action and one that's technically present but never reached.
Evaluating Trust and Scoping Blast Radius — NetRise Provenance®
Once that inventory exists, the harder questions begin and they arrive the moment a component is implicated. Should it be trusted at all? When a package, repository, or maintainer is compromised, how far does the risk reach?
NetRise Provenance answers that from a dependency graph built by analyzing tens of millions of packages, libraries, and repositories across ecosystems, mapping both direct and transitive relationships. When a component Turbine has identified is implicated, that graph is what lets Provenance size the blast radius: which libraries, products, and vendors the risk propagates into, including the transitive paths that don't appear in any single binary. From there, you cross-reference against the inventory Turbine maintains to pinpoint exactly where you're exposed, not just where the named component sits directly, but everywhere the risk reaches.
Turbine finds the components the EO needs you to inventory. Provenance determines whether to trust them and how far the risk propagates when something goes wrong.
What this means beyond the federal government
The EO's obligations fall first on federal civilian agencies and critical infrastructure operators, but the operational reality it exposes is universal. Any enterprise running complex vendor software, OT environments, or a third-party risk program faces the same root problem, and benefits from the same starting point: analysis that begins at the compiled artifact rather than the declaration. Closing the gap doesn't require a new program architecture. It requires changing where the program starts.
The right requirements need the right foundation
The White House got the technical framing right. Modern software risk lives inside compiled binaries, in AI frameworks shipped without disclosure, and in open-source components maintained by people no one has vetted, in the dependency chains that turn a single compromised package into an enterprise-wide incident. The EO supplies the urgency to address it. What it can't supply is the inventory agencies need to act, because that only comes from the software itself. For a program still built on vendor declarations, the order is the reason to rebuild on a foundation that can actually carry the weight of what's being asked.
NetRise analyzes compiled software artifacts across firmware, containers, applications, and embedded systems — finding what scanners miss, scoping blast radius in minutes, and providing the provenance intelligence to determine whether software can be trusted.
Need quick help? Chat now with a Real NetRise Expert
Click here➡
No Slack account needed
