From Gaps to Pathways: Rethinking Vulnerability Assessments

Most organizations don’t have a visibility problem. They have a perspective problem. Security programs today generate enormous volumes of data from scan results, audit artifacts, control validations to compliance reports. On the surface, this creates a sense of maturity. Coverage appears broad. Risks appear cataloged. Controls appear mapped.

But beneath that structure lies a fundamental flaw:

The Structural Problem: Vulnerability Assessments Mirror Org Charts, Not Attack Paths

Security assessments are typically scoped around how organizations are structured, not how attacks actually unfold.

Each function operates within its own boundary, with its own tools, timelines, and success criteria. This creates rigor, but not cohesion.

An attacker, by contrast, does not recognize organizational ownership, network segmentation as a stopping point or contractual boundaries with vendors. They recognize only one thing: pathways. And those pathways almost always cut across the exact boundaries assessments are designed to respect.

The False Comfort of “Complete Coverage”

It’s common to hear:

Each of these statements may be true. Individually. But risk does not materialize within individual truths. It emerges from how those truths interact.

For example:

Yet when combined:

Now a single compromise, anywhere in that chain can propagate across all three. No individual Vulnerability assessment would flag this as critical. But the system, as a whole, is exposed.

Where Fragmentation Creates Blind Spots

The traditional assumption is that IT and OT environments are separate, with segmentation acting as a security boundary. In practice, that boundary is increasingly permeable. Operational requirements have introduced:

These integrations are necessary. But they also create transitive trust. An attacker does not need to break into the OT environment directly. Instead, they can compromise an IT asset, identify a legitimate pathway into OT, and then abuse that pathway under the guise of normal operations, allowing them to move across environments without triggering traditional security controls.

This is precisely why frameworks like CISA emphasize validating not just segmentation, but access pathways and trust relationships.

External attack surface management has matured significantly, with organizations investing heavily in perimeter defenses, exposure monitoring, and rigorous testing of internet-facing assets. However, once initial access is achieved through phishing, credential reuse, or supply chain compromise, the nature of the attack fundamentally changes and becomes internal.

At that point, flat networks accelerate lateral movement, over-permissioned accounts expand the attacker’s reach, and implicit trust begins to replace active verification. According to IBM’s 2024 Cost of a Data Breach Report, the average time to identify and contain a breach still exceeds 200 days, driven far more by lateral movement and internal complexity than by the initial point of entry.

This highlights a critical reality:

Most organizations treat vendors as external entities that are periodically assessed. In reality, vendors are embedded into the operational fabric of the environment.

They often have:

This creates a paradox: The most trusted entities often have the least scrutinized pathways.

As explored in Aerstone’s earlier post, organizations often overlook how third-party access behaves under real attack conditions. Vendor relationships introduce trusted pathways into the environment, yet these pathways are rarely tested in a way that reflects how an attacker would actually exploit them.

How Risk Propagates in a Connected Environment

To understand why siloed assessments fail, you have to shift from thinking in terms of assets to thinking in terms of relationships. Risk moves through connections.

Modern architectures rely on deep system integration including ERP, cloud platforms, ICS environments, analytics layers. Each integration assumes:

But these assumptions are rarely revalidated under adversarial conditions. A compromised system can inject malicious data into trusted workflows, trigger unintended actions in downstream systems, and escalate privileges indirectly through integration logic. The vulnerability is not in the system itself but in the trust between systems.

APIs are often secured at the surface level through authentication, rate limiting, and input validation. What is less frequently tested is how APIs interact with underlying business logic, whether authorization models hold under chained requests, and how API access can be combined across services. As a result, an attacker does not need to exploit a single API.

They can:

This is why API security failures often bypass traditional vulnerability scanning. They are not technical flaws, but logic flaws across systems.

Vendors often provide the most direct and reliable path into critical systems, not because they are weak, but because they are deeply embedded into day-to-day operations. Their access is intentionally designed to be seamless. They are whitelisted at the network level, trusted at the identity level, and relied upon for maintenance, support, and system continuity. Over time, this access tends to expand in scope, persist longer than intended, and operate with limited scrutiny.

As a result, vendor access is optimized for availability and efficiency rather than resistance to adversarial use. Security controls that are rigorously applied to employees are often relaxed for vendors to avoid operational friction. Monitoring is lighter, permissions are broader, and access pathways are more stable.

If that access is compromised, the attacker inherits those same advantages. They can move quickly without the need for reconnaissance, bypass segmentation through pre-approved channels, and operate within normal traffic patterns that are unlikely to trigger alerts. In many environments, vendor pathways effectively function as pre-established lateral movement routes.

This is what makes vendor risk particularly dangerous. It is not just another external threat vector, but a structurally efficient and often invisible extension of the internal environment.

The Missing Layer: System-Level Visibility

Most organizations never answer a critical question: if an attacker gains a foothold anywhere in the environment, what is the full path to impact? Instead, they focus on answering a series of fragmented questions such as whether a specific system is vulnerable, whether a control has been implemented, or whether a vendor meets compliance requirements.

These questions are necessary, but they are not sufficient to understand real risk. They evaluate components in isolation rather than how those components behave together under adversarial conditions. For example:

Each of these provides a partial signal, but none explain how risk actually moves.

What is often missing is a system-level perspective that includes end-to-end attack path mapping, cross-domain testing across IT, OT, and vendor environments, and validation of how controls interact when they are exercised together. Without this, security programs tend to optimize for coverage rather than coherence, creating the appearance of control without a clear understanding of how risk propagates through the environment.

What Changes with a System-Oriented Assessment

A system-level approach fundamentally shifts how assessments are conducted. It moves from:

This means changing how vulnerabilities are evaluated. Instead of simply asking whether a vulnerability exists, the question becomes whether an attacker could use that vulnerability, along with existing conditions in the environment, to gain access, move through systems, or cause real impact.

Why Compliance Alone Cannot Solve This

Closing the Gap

Organizations do not struggle because they lack tools. They struggle because their assessments are not aligned with how risk actually behaves. In practice, risk is non-linear, crosses domains, and depends on relationships between systems rather than individual components. To address this, security programs must evolve beyond siloed validation and move toward a system-level understanding of how risk propagates across the environment

If your assessments are structured around systems, teams, or compliance scopes, you are seeing only part of the picture. Attackers don’t operate in parts. They operate across connections.

To move beyond this, organizations need to intentionally model how risk flows:

This is not about replacing vulnerability assessments, but about elevating them, turning static findings into dynamic scenarios.

It also requires bringing different perspectives together. Security, IT, and operations must align around a shared understanding of risk, rather than operating within their own scopes. Because risk does not respect organizational boundaries. And perhaps most importantly, it requires challenging assumptions.

The environment you think you understand may only exist that way on paper. Architecture diagrams are often simplified. Documentation reflects intended design, not actual state. Over time, systems evolve, integrations expand, and exceptions accumulate. What was once a clean, well-defined environment becomes layered and complex—often without a corresponding update in how it is assessed.

A system-level approach forces visibility into that reality.