> cat finding_{1..5}.yml | chain --impact_
A professional services firm is breached. The attacker exfiltrates 200,000 client records, deploys ransomware across the domain, and demands seven figures. The post-incident investigation traces the attack path through five separate weaknesses — none of which, individually, would have been rated higher than medium severity.
A verbose error message revealed the internal IP of the application server. A server-side request forgery (SSRF) in a PDF export function allowed requests to internal addresses. The application server had access to the cloud metadata service running IMDSv1. The metadata service returned temporary AWS credentials. Those credentials had permissions to read every S3 bucket in the account — including the one containing nightly database backups.
Five findings. Five medium-or-lower severities. One catastrophic outcome. The firm's previous pen test had identified three of the five findings individually — and deprioritised all three because their CVSS scores suggested they were acceptable risks.
This is what chaining looks like. And it is, by a wide margin, how real breaches actually happen.
Attackers don't exploit vulnerabilities. They exploit chains of vulnerabilities. A security programme that assesses each finding in isolation — rating it, prioritising it, remediating it based solely on its individual severity — will consistently deprioritise the weaknesses that, combined, deliver the most devastating outcomes.
The Common Vulnerability Scoring System (CVSS) is the industry standard for rating vulnerability severity. It assigns a numerical score from 0 to 10 based on factors like attack complexity, required privileges, and potential impact. It's widely used, well-understood, and embedded in every vulnerability scanner, pen test report, and risk register.
It also has a fundamental limitation: CVSS rates each vulnerability independently. It has no mechanism for assessing how vulnerabilities interact with each other, how they chain together, or how a finding's severity changes when it exists alongside other findings in the same environment.
| Finding | CVSS Score | Standalone Risk | Risk in the Chain |
|---|---|---|---|
| Verbose error message disclosing internal IP | 3.7 (Low) | Information disclosure. No direct exploitation path. | Critical enabler — provides the internal target address for the SSRF attack. Without this, the attacker doesn't know where to aim. |
| SSRF in PDF export function | 5.3 (Medium) | Server can be made to issue internal requests. Limited impact in isolation. | Pivot point — turns an external attacker into an internal one. The SSRF reaches the metadata service that the attacker can't reach directly from the internet. |
| IMDSv1 enabled on cloud instance | 5.4 (Medium) | Metadata service accessible without session tokens. Requires existing access to the instance network. | Credential source — returns temporary AWS credentials to any internal request. The SSRF provides that internal request. |
| Over-permissive IAM role | 6.5 (Medium) | The instance role has read access to all S3 buckets. Excessive, but no exploitation path without credentials. | Access amplifier — the stolen credentials inherit this role's permissions. Every S3 bucket in the account is now readable. |
| Unencrypted database backups in S3 | 4.3 (Medium) | Backups stored without server-side encryption. Requires bucket read access to exploit. | Objective achieved — 200,000 client records exfiltrated from unencrypted backups using the stolen credentials. |
The highest individual CVSS score in this chain is 6.5 — solidly medium severity. No finding individually would appear in a "critical items to fix immediately" list. But the chain, end to end, constitutes a complete breach with regulatory, financial, and reputational consequences measured in millions.
CVSS isn't wrong — it's doing what it was designed to do: rate individual vulnerabilities in isolation. The problem is using it as your only lens for prioritisation. If your remediation backlog is sorted by CVSS and nothing else, the chain links will sit in the middle of the list while genuinely critical attack paths go unfixed.
The SSRF-to-cloud-compromise chain above is one pattern. Here are five more — all composites drawn from real engagements, all built from findings that would individually be rated medium or lower.
Every one of these chains was built from findings rated low or medium in isolation. Every one resulted in a high or critical outcome. And every one would have been deprioritised — or never discovered at all — in a process that evaluates findings independently.
Vulnerability scanners are designed to detect individual vulnerabilities. They test each input, each service, each configuration against a database of known patterns and report whatever matches. They do this at tremendous speed and scale — and they do it with zero understanding of how their findings relate to each other.
Chaining requires something scanners don't possess: a mental model of the entire environment, the ability to reason about cause and effect across systems, and the creativity to ask "what if I take the output of this finding and use it as the input for that one?"
| What Chaining Requires | Why Scanners Can't Do It |
|---|---|
| Cross-system reasoning — understanding that a finding on System A enables an attack on System B | Scanners assess each target independently. They don't know that the SSRF on the web server can reach the metadata service on the cloud instance, or that the credentials from the metadata service grant access to the storage bucket. |
| Contextual impact assessment — recognising that a finding's severity depends on what else is present in the environment | CVSS is calculated per-vulnerability using a fixed formula. The score for LLMNR poisoning is the same whether the network has one machine or ten thousand — even though the real-world risk scales dramatically with environment size. |
| Creative hypothesis formation — asking "what if?" in ways nobody has codified into a detection rule | Scanners test for what they've been programmed to test for. The question "what happens if I combine this error message with this SSRF and this metadata endpoint?" is not a test case in any scanner's database — it's an insight that requires adversarial reasoning. |
| Sequential exploitation — using the output of one exploit as the input for the next | Scanners don't exploit in sequence. They don't take the credentials extracted from Step 2 and use them as authentication for Step 3. Each scan is self-contained; chains, by definition, are not. |
| Business logic understanding — knowing what the application is supposed to do and recognising when a chain enables something it shouldn't | A scanner has no concept of business rules. It can't recognise that combining a negative quantity with a missing server-side validation and a credit memo function allows unlimited money generation — because it doesn't know what a credit memo is. |
This is the gap that human testers fill. Not by running better tools — by thinking. Holding the full environment in their head, forming hypotheses about how weaknesses interact, and testing those hypotheses with the creativity and persistence that define adversarial reasoning.
Finding chains isn't accidental. Experienced testers actively look for them by categorising every finding by its role in a potential chain — not just its standalone severity.
| Chain Role | What It Does | Examples |
|---|---|---|
| Enabler | Provides information or access that makes a subsequent step possible. Doesn't constitute a vulnerability on its own but is essential to the chain. | Verbose error messages revealing internal IPs. Directory listings exposing file paths. Version numbers in HTTP headers confirming a specific CVE is applicable. |
| Pivot | Allows the attacker to move from one context to another — external to internal, unauthenticated to authenticated, low privilege to high privilege, one system to another. | SSRF reaching internal services. Credential capture enabling authentication. Lateral movement from a workstation to a server. VPN access bridging external and internal. |
| Amplifier | Expands the scope or impact of the access already gained. Turns a limited foothold into a broad compromise. | Over-permissive IAM roles granting access to all resources. Domain Admin granting control over all machines. Shared credentials that work across multiple systems. Flat network segmentation allowing unrestricted lateral movement. |
| Objective | The final step that delivers the attacker's goal — data exfiltration, ransomware deployment, financial fraud, persistent access. | Accessing the customer database. Reaching the file server containing board documents. Deploying a payload across the domain via Group Policy. Intercepting payment communications. |
When we report findings, each one is tagged with its chain role. A finding that's an enabler in a critical chain is more important than a standalone high-severity finding that doesn't connect to anything — even though the CVSS score says otherwise.
Notice the break_chain_at line. You don't have to fix every link to eliminate the risk — you have to break the chain at one point. This is where chain-aware reporting transforms remediation: instead of fixing five medium-severity findings across five different backlogs, you fix one finding that neutralises the entire attack path. That's efficient, targeted risk reduction.
Even when chains are discovered, the standard pen test report format often obscures them. Findings are listed individually, sorted by severity, each on its own page with its own CVSS score and its own remediation advice. The chain — the relationship between findings that creates the real risk — is invisible in this format.
| Traditional Report | Chain-Aware Report | |
|---|---|---|
| Finding structure | Each vulnerability on a separate page. Sorted by CVSS: critical first, informational last. | Individual findings documented, but chains presented as dedicated sections: "Attack Path 1: SSRF to Cloud Credential Theft" with each link explained in sequence. |
| Severity rating | Each finding rated by individual CVSS. The SSRF is 5.3. The error message is 3.7. Both sit in the middle of the report. | Each finding retains its individual CVSS, but the chain receives an aggregate severity rating based on the end-to-end impact. CHAIN-001 is rated Critical regardless of individual scores. |
| Remediation priority | Fix all criticals, then all highs, then all mediums. The chain links sit in the medium queue behind standalone highs. | Break the most dangerous chains first. The IMDSv2 upgrade (10-minute configuration change that breaks a critical chain) is the highest-priority remediation item — even though its standalone CVSS is 5.4. |
| Executive summary | "12 medium findings and 3 low findings were identified. No critical or high issues." | "A chain of five medium-severity findings enables complete exfiltration of the client database (200,000 records) from an unauthenticated internet position. The chain can be broken by a single configuration change." |
| Board reaction | "No critical findings — we're in good shape. Move the security budget to other priorities." | "Our client database is exposed through a chain of individually-moderate weaknesses. One configuration change eliminates the path. Do it today." |
The findings are identical. The report format determines whether anyone takes action. A chain-aware report ensures that the most dangerous attack paths are visible, prioritised, and communicated in terms that drive remediation.
Once you start thinking in chains rather than individual findings, remediation strategy changes fundamentally. Instead of fixing every finding from most severe to least severe, you identify the chains that present the greatest risk and break each one at its weakest link.
| Strategy | How It Works | When to Use It |
|---|---|---|
| Fix the quickest link | Identify the chain link that can be fixed fastest — often a configuration change rather than a code rewrite — and fix it immediately. The chain is broken even though other links remain. | When one link in a critical chain is a simple configuration change (e.g. upgrading IMDSv1 to IMDSv2, disabling LLMNR, enforcing DMARC). Delivers maximum risk reduction with minimum effort. |
| Fix the pivot | The pivot point — the finding that allows the attacker to move from one context to another — is often the most impactful link to remove. Without the pivot, the chain can't cross boundaries. | When the chain crosses a trust boundary (external → internal, user → admin, IT → OT). Fixing the SSRF prevents the entire internal exploitation path even if the metadata service and IAM role remain misconfigured. |
| Fix the amplifier | Reduce the blast radius by constraining what the attacker can reach after the pivot. Least-privilege IAM roles, network segmentation, restricted file share permissions. | When the pivot is difficult to fix (e.g. a zero-day, a business-critical function that can't be easily modified). Limiting the damage of a successful exploit is the next best thing to preventing it. |
| Add detection | If the chain can't be immediately broken, add monitoring at each link: SIEM rules for the SSRF pattern, CloudTrail alerts for metadata credential usage, GuardDuty for anomalous S3 access. | As a compensating control while remediation is in progress. Detection doesn't prevent the chain but ensures the organisation knows when it's being exploited. |
| Defence in depth | Fix multiple links in the same chain, so that breaking one doesn't rely on a single point of failure. True resilience comes from eliminating several links, not just the most convenient one. | For your most critical chains — the ones that lead to crown jewels. Defence in depth ensures that if one fix is bypassed, regresses, or has an implementation flaw, the chain is still broken elsewhere. |
Shifting from finding-level thinking to chain-level thinking doesn't require a new toolset. It requires asking different questions — of your pen test provider, your vulnerability management process, and your reporting.
The most devastating compromises are rarely caused by a single critical vulnerability. They're caused by chains of low- and medium-severity findings that, individually, look manageable — and collectively, deliver catastrophic outcomes.
A security programme that evaluates vulnerabilities in isolation will consistently deprioritise the findings that matter most. CVSS is a useful input but a dangerous sole decision-maker. The real risk lives in the relationships between findings — in the chains that turn five medium-severity issues into a complete organisational compromise.
Finding chains requires human reasoning: the ability to hold the full environment in mind, to hypothesise about how weaknesses interact, and to test those hypotheses with creativity and persistence. It's the highest-value activity in a penetration test, and it's the one that no scanner, no automated tool, and no CVSS calculator can replicate.
When you read your next pen test report, don't just look at the severity column. Look at the chains. That's where the real risk lives.
Our reports don't just list findings — they map attack paths, document chains, and prioritise remediation by real-world impact rather than generic severity scores.