From vulnerability to architectural impact

When a new advisory lands, most teams look at its severity first. The CVSS base score is useful for what it is: a standard description of how bad a vulnerability is in general, assuming the vulnerable code is present, reachable and running with meaningful privileges. Your system decides whether any of those assumptions hold.

A critical remote code execution flaw in a library that ships in your image but is never loaded is not your most urgent problem. A medium-severity flaw in an internet-facing service that runs with a role able to read every customer's files may be. CVSS version 4 acknowledges this with environmental and threat metrics, but those only help if someone fills them in with facts about the deployment. That is architectural work, and it is where prioritisation is won or lost.

For each vulnerability, establish four things in order. Each answer can end the inquiry early.

1. Present: is the vulnerable version actually in something you deploy, and is the vulnerable code loaded?
2. Reachable: can an attacker get input to the vulnerable code, from where, and with what authentication?
3. Consequential: if exploited, what identity, network position and data does the attacker gain?
4. Likely: is it being exploited, or likely to be soon?

Answering the first question quickly requires knowing what you shipped. A software bill of materials generated for each built artifact, keyed by its digest, lets you go from "library X before version Y is affected" to "these four images in production contain it" in minutes rather than days.

Presence in an image is not the end of it. A dependency may be included but never imported, or the vulnerable function may sit in a feature you do not use. When you establish that, record it: a VEX (vulnerability exploitability exchange) statement says, in a machine-readable form, that a product is not affected by a vulnerability and why. That record saves the next person, and your customers, from repeating the analysis.

Reachability is an architecture question. Is the workload exposed to the internet, to partners, or only to other internal services? Does the path to the vulnerable code require authentication, and whose? Can the input that triggers the flaw actually arrive through that path, or is it a file format or protocol the service never accepts?

Map this from evidence rather than assumption: load balancer and gateway configuration, network policies, the routes the service registers, and the trust boundaries on the way. An internal service is not unreachable; it is reachable from whatever can reach it, which may include a compromised neighbour.

Exploitation hands the attacker the vulnerable process's position. That means its workload identity and permissions, the secrets it can read, the networks it can talk to and the data it touches. Two identical vulnerabilities in two services can differ enormously here, which is why identity and privilege chains and failure containment matter for vulnerability management as much as for design.

Write down the blast radius in concrete terms: "the role can read the uploads bucket for all tenants" is actionable; "high impact" is not.

Two public signals help with the fourth question. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation in the wild; anything on it that is present and reachable in your estate deserves immediate attention. FIRST's Exploit Prediction Scoring System estimates the probability that a vulnerability will be exploited in the coming weeks, which helps order the long tail.

Decision models such as CISA's Stakeholder-Specific Vulnerability Categorization combine exploitation status, exposure and impact into a small number of actions, which is easier to run consistently than a numeric threshold.

Doing this analysis by hand for every advisory does not scale; doing it for none of them leaves you sorting by score. A sustainable process automates the first two questions and saves people for the last two.

• Inventory automatically. Generate an SBOM for every build and match new advisories against it, so presence is known within minutes of publication.
• Know exposure in advance. Keep a current map of which workloads are reachable from where. When a match arrives, reachability is a lookup, not an investigation.
• Route by owner. Every deployed artifact should have an owning team, so a confirmed finding reaches people who can fix it.
• Set response times by decision, not by score. For example: act within days on anything known exploited, present and reachable; plan within a release cycle for reachable but unexploited; record and monitor what is present but unreachable.
• Re-evaluate when the architecture changes. A "not reachable" conclusion is only as good as its facts. A new route, a widened role or a new data flow should reopen it.

The output of this work should read like a description of your system, not a copy of the advisory:

The vulnerable parser is present in the orders image (current production digest), reachable from the internet without authentication through the upload endpoint, and the service's role can read every tenant's documents. It is listed as known exploited. Fix now.

Or, just as valuable:

The library is present in the reporting image but the affected function is never called; the service is internal-only and its role is read-only on aggregated data. Recorded as not affected, with the evidence; revisit if the service gains an external route.

The second statement is what lets a team say no to an urgent-looking score with confidence, and what tells them exactly when that answer would change.