Opinion

Jan 21, 20266 mins

The common vulnerability scoring system (CVSS) has long served as the industry’s default for assessing vulnerability severity. It has become one of the few “sources of truth” for cybersecurity professionals.

And, you know the drill. A new CVE drops; it gets a CVSS score; teams rush to patch the items with the biggest numbers.

It all feels logical, scientific — even objective. But in practice, it often fails us.

In the cases of Equifax, SolarWinds and Log4Shell, a similar pattern has emerged: the actual damage did not stem solely from the technical severity of the flaws, but rather from the manner in which those flaws propagated through interconnected systems. High CVSS scores did not always correlate with high operational impact. Low-scoring assets triggered the cascading failures. Often, a “medium” vulnerability can have the most significant impact due to its location and the systems it interacts with.

CVSS scores have enormous value as a starting point. They do not capture the relational dynamics. They do not demonstrate how one vulnerability’s exploitation may amplify or propagate risk through dependencies, shared credentials or inherited configurations.

We have historically treated vulnerabilities as isolated points on a list, yet the actual risk lies in their connections.

Why the CVSS score isn’t the whole story

The CVSS rating system focuses on the characteristics of a single asset — how easy a flaw is to exploit, whether a patch exists and the potential confidentiality or availability impact. That’s important, and it’s a solid starting point. But it doesn’t account for something crucial: context.

A vulnerability in a tightly isolated sandbox may score a 9.8 but never affect anything else. Meanwhile, a 5.2 in a single sign-on service, the system that every other system trusts, can become a blast radius multiplier. The score alone tells us nothing about how that flaw might ripple across the enterprise.

In the real world, vulnerabilities don’t stay put. They move. They inherit privileges. They hitch rides through pipelines. They land in places no one expected.

Risk isn’t only about severity. It’s about propagation.

A different way to look at vulnerabilities

This is where the unified linkage model (ULM) comes in. Instead of asking, “How bad is this vulnerability on its own?” ULM asks, “What can this vulnerability affect once it starts moving?”

It focuses on three kinds of relationships:

Adjacency: Systems that sit side by side and can influence each other, even without direct data exchange.

Inheritance: Flaws that travel downstream — like a vulnerability hidden inside an open-source library embedded in dozens of applications.

Trust: Systems that depend on each other’s integrity — like identity providers, update services or CI/CD tools.

When you map these relationships, you stop seeing a list of vulnerabilities and start seeing a network of pathways. Suddenly, a seemingly minor flaw can reveal a much larger story.

How vulnerabilities really move

Modern development pipelines make it incredibly easy for vulnerabilities to spread unnoticed. A flawed library pulled into a build is included in a Docker image. That image gets promoted to production. The container gains new permissions. And eventually, an external endpoint exposes it to the internet. By the time someone sees the CVE notification, the vulnerability may already be alive inside mission-critical systems.

The question isn’t just “What’s the score?” — it’s “Where can this go?”

Revisiting Log4Shell through a linkage lens

Log4Shell didn’t become historic because it was technically severe. Hundreds of vulnerabilities are rated critical every year. It became historic because it was everywhere. Log4j was inherited through nested dependencies, embedded in countless libraries and trusted by systems that consumed untrusted data.

It was a perfect storm of inheritance, adjacency and trust.

Log4Shell taught us that a vulnerability’s true danger lies not only in what it is, but in where it lives.

What happens when we score based on linkage?

ULM doesn’t replace CVSS scores. It enhances them. It forces us to think about depth, reach and influence.

A vulnerability in a retired development VM might score 9.8. However, if nothing depends on it, its real-world priority may be low.

Meanwhile, a flaw in a GitHub runner that feeds production builds could score much higher when evaluated through linkage. It sits in a trusted pipeline, inherits credentials and can influence downstream systems. In a ULM view, its urgency skyrockets.

A number alone can mislead. A narrative reveals risk.

How organizations can start using ULM today

This doesn’t require a massive overhaul. It starts with a mindset shift:

• Map how systems connect, not just what systems exist.
• Look for shared components, shared identities, shared pipelines.
• Ask which systems others trust, depend on or inherit from.

Then prioritize vulnerabilities based on where they sit in that network — especially those near identity systems, CI/CD pipelines or widely used shared services. These are the silent amplifiers.

Start small. Focus on the systems with the most downstream influence. The picture will come into focus quickly.

The bottom line

Vulnerability management isn’t a numbers game. It’s a relationship game.

CVSS tells us, in theory, how severe a vulnerability is. ULM helps us understand how dangerous it could be in practice. And in a world of accelerating complexity, automation and interconnected systems, that context is no longer optional.

To defend our environments, we have to stop seeing vulnerabilities as dots. We have to start seeing the lines between them.

That’s where the real risk lives.

This article is published as part of the Foundry Expert Contributor Network. Want to join?

SUBSCRIBE TO OUR NEWSLETTER

From our editors straight to your inbox

Get started by entering your email address below.

Contributor

Henry J. Sienkiewicz is a seasoned cybersecurity strategist, educator and author with over three decades of experience in the public and private sectors. He currently is on faculty at Georgetown University and George Washington University, where he teaches graduate courses in cybersecurity, information assurance and applied intelligence. His academic work focuses on trust architectures, cyber risk frameworks and digital sovereignty.

Henry previously served as the CIO and designated authorizing official for the Defense Information Systems Agency (DISA), where he led transformative cloud and cybersecurity initiatives for the US Department of Defense. He previously held multiple positions in the commercial industry at the CEO and CIO level, notably in the travel industry. His expertise in secure digital transformation and enterprise architecture continues to influence public policy and commercial practices.

More from this author