Vulnerability Management Architecture

Your queue lies until it knows reachability

September 8, 2026·9 min read·Chris Boker
A left-side input rack of ten faint CVE record bars, four vertical sieve columns in the middle labeled by geometric icons for network, service, code, and identity with each column carrying a green pass slot and a set of rust reject notches, a small dark AND gate diamond on the right that only accepts a candidate that has cleared all four columns, and a small clean right-side working queue of four bright rows each fronted by a mint exposure band chip and a gold owner marker

On June 10, 2026 the U.S. federal civilian executive branch started operating under CISA's Binding Operational Directive 26-04. The directive re-defines what critical means for a vulnerability on a federal system by combining four binary variables: known exploited status, exploit automatability, technical impact, and public exposure. CISA supplies the first three through the Vulnrichment program. It cannot supply the fourth, because public exposure depends on how the asset that carries the vulnerability is deployed inside a particular network, and no external authority can know that. The federal government has now formally stated the argument every remediation team has been living for a decade. The input that decides urgency cannot be bought from a feed; only the organization that owns the asset can answer it.

For private programs the catch is that BOD 26-04 draws the bar at internet facing, yes or no, which is the coarsest useful reading of reachability. This piece is a practitioner definition of reachability across four layers, with a cheap approximation for each built from tooling most teams already own, and a composition rule that turns the four answers into a single re-sort of the queue.

The prior art already covers pieces of three of these layers

The market sells reachability one layer at a time and calls each version reachability, so a buyer ends up believing they have solved the problem when they have coverage of one layer of four. Endor Labs builds call graphs from source and traces data flow into vulnerable methods across Java, JavaScript, Python, Go, Kotlin, .NET, and Rust, and Snyk ships the same concept for Java, JavaScript, and Python (independent comparison from AppSec Santa). Network reachability and attack-path analysis belong to XM Cyber and Wiz on the infrastructure side, and identity attack paths belong to SpecterOps and its BloodHound tool.

Exploit probability is a separate axis that gets conflated with reachability constantly. EPSS from FIRST estimates the probability a CVE will be exploited in the next thirty days, and NIST's LEV metric in CSWP 41 (May 2025) estimates the probability it has already been exploited from the EPSS time series. Neither is reachability. Attackers being active against a class of bug says nothing about whether your instance of it sits on a path they can walk, which is why the same CVE carries different risk in different environments. VEX, covered when we wrote about how SBOMs need runtime exposure, communicates the code-layer conclusion but does not compute reachability on the other three. What is missing is a composed definition across all four layers and cheap approximations for teams that own none of these vendor stacks.

Network reachability, and a firewall diff can approximate it

Network reachability asks whether a packet from outside the asset's boundary can arrive at the port the vulnerability lives on. The cheap approximation is a diff of two things a team already has, the current firewall or security-group configuration and the current load-balancer or ingress configuration. A finding on a service the perimeter denies from every off-host source is a level 1 finding, a finding on a service the perimeter accepts from anywhere is a level 5, with bands in between for "reachable from a peered VPC", "reachable from the corporate VPN", and "reachable behind an authenticated proxy". Static approximations of this kind miss transient rules and NAT games, but they change the shape of the queue on the day they run.

Service exposure, and an external scan diff can approximate it

Service exposure is what the outside actually sees, not what the firewall says it should see. Firewalls lie because rules go stale, load balancers add routes that were meant to be temporary and never removed, and cloud accounts hold shadow services no security team has an inventory of. The cheap approximation is a diff of an external-view scan against the internal asset inventory. Anything the internet sees that the inventory does not name is a first-order problem before any CVE enters the conversation; anything the inventory names but the external scan cannot see confirms the firewall's claim. The Verizon 2026 Data Breach Investigations Report found edge devices and VPNs went from 3 percent to 22 percent of exploitation-driven breaches in a single year, which is why a code-only definition of reachability is insufficient on its own.

Code reachability, and an SCA call graph can approximate it

Code reachability is the layer the SCA vendors ship. The question is whether the vulnerable function is invoked, or transitively reachable, from any entry point of the application. If the vendor supports the language and the finding is in a dependency, the approximation is close to free, turn on the call-graph output and read the reachable or not-reachable flag. Endor Labs has published a customer case that cut developer-facing findings by 95 percent, and a typical Java service that generates 500 or more CVE alerts under generic SCA surfaces under 50 actionable findings under function-level reachability. Those numbers are vendor-published, so treat them as an upper bound. For languages the vendor does not cover, the coarser binary answer (does the vulnerable package appear in the shipped artifact) still re-sorts the queue on the first pass.

Identity reachability, and an edge review can approximate it

Identity reachability asks who can invoke the code path if the network layer allowed it. A privilege-escalation CVE that requires an authenticated admin identity behaves differently on a machine three humans can reach than on one hundreds of accounts and service principals can reach. The cheap approximation is a review of the identity edges into the affected asset, drawn from the IAM system's audit or resource-policy exports and joined against roles and service accounts. That is an upper bound on who could reach the vulnerable function, not a full identity attack path; treat it accordingly.

How the four layers compose under the AND rule

Reachability across a stack is not a scalar. The dominant layer is the one that says NO. A finding unreachable at the network layer is not reachable, whatever the identity graph says, and if the code path is dead, the network exposure does not matter. Composition is the AND of the four layers. Any single NO drops the finding out of the working queue, and the queue keeps only findings where every layer says YES or UNKNOWN.

The UNKNOWN case matters most, because approximations produce unknowns constantly (the SCA vendor does not cover this language; the identity graph does not cover this SaaS). Treat unknowns as YES for the initial sort and mark them as work for the discovery backlog, which keeps the queue conservative in the direction that costs work rather than the direction that costs an incident. It also explains why one layer alone never re-sorts the queue; code reachability will happily deprioritize an internet-facing bug on the argument that the vulnerable function is not called, when the attacker can still reach the service through a code path the call graph did not model.

Static approximations rot; validation is the tie-break

Every layer above is a static approximation, and static approximations start rotting the moment they are computed. Firewall rules change on Wednesday afternoon, a demo IAM role gets provisioned and never removed, an SCA scan runs on last Friday's source tree and misses Monday's hotfix. The tie-break is running the exploit. Breach-and-attack simulation, covered in our writeup of the top BAS tools, turns a modeled path into a demonstrated one against the actual environment. The Picus 2026 blue-report study found CVSS flagged 63 percent of findings as critical while validation showed 9 to 10 percent were reproducibly exploitable, and that gap is the reachability question measured from the other side. Modeled reachability tells you what to try, validation tells you what to fix, and the right cadence is a rolling re-sort against every inventory delta with validation runs aimed at the layer that most often produces a mistaken YES in that environment.

A ten-item queue, before and after

Consider a queue of ten findings, all rated CVSS 9.0 or higher, sorted by CVSS alone.

  • Two are in Java dependencies of an internal payroll service; the SCA call graph shows the vulnerable functions are never invoked.
  • Three are in an internet-facing VPN appliance, and the KEV catalog lists all three.
  • One is a privilege-escalation CVE on a build server; only two humans and one CI role can reach the machine.
  • Two are in a marketing CMS that lives on an isolated VLAN with no ingress from anywhere else in the environment.
  • One is in a container base image, but the image is used only by a batch job that runs from a cron account inside a private subnet.
  • One is in a public GraphQL endpoint whose vulnerable resolver is directly reachable and whose entitlement check has a known bypass.

Under CVSS, all ten sit at the top of the queue and remediation triages the wrong three first. Composed reachability drops the two payroll findings out of the working queue, moves the two CMS findings into a network-remediation backlog, moves the container base image into a build-hardening backlog, and puts the three VPN findings and the GraphQL finding at the top, with the build-server finding in the middle because identity reachability is narrow but nonzero. Remediation gets four items to work today instead of ten, and the four are the ones that would carry an incident if exploited.

That is what BOD 26-04 formalized for federal systems and what a private program can compute against its own environment starting the week after it reads this. The layers do not require any single vendor, and the composition rule does not require a new tool; what it requires is treating reachability as four questions and refusing to sort the queue until at least a coarse answer exists for each. CVEasy AI's CTEM is the local-first control loop that computes exactly that composition against the environment it lives inside, and TRIS is the score that reads the composed output into a single ordering for the working queue.