Every security leader has had a version of this conversation. After a breach review someone lays out the chain: a public service, a library nobody had patched, a cloud role with far more permission than it needed, and a storage bucket full of customer data. Then someone asks why none of it was on the priority list. The honest answer is usually that every link was on a list. They were on four different lists, owned by four different teams, and none of them looked critical on its own.
In short
- Breaches follow paths, but scanners report points. A vulnerability scanner, a cloud posture tool and an IAM review each see one link. None of them sees the chain.
- The chain is what deserves the priority. An exposed service, an exploitable weakness, an over-privileged identity and sensitive data together are critical, even when each part on its own is not.
- You only need to break one link. The cheapest fix is often not the vulnerability. It may be a single permission or a network rule.
- Every link must be evidence, not inference. A path built from guesses will be dismissed. One built from scan results, IAM policies and the data owner’s own labels will not.
The situation
The scenario below is illustrative, built on InsightFortify’s demo estate, but its shape is one
every cloud-native organisation will recognise. A payments team runs acme/payments-api
as a container behind a public load balancer. The image, version 1.4.2, ships an old version of a
small JavaScript utility, minimist 1.2.5, which carries
CVE-2021-44906, a prototype-pollution flaw rated 9.8. The container runs as an AWS
role, payments-api-task, which was given broad S3 read access during a migration and
never trimmed back. One of the buckets that role can read, acme-payments-exports,
holds the nightly settlement exports, and the data owner has labelled it sensitive.
Now look at how each of those facts shows up in a typical toolset.
| Link | Which tool sees it | How it is reported | Who owns it |
|---|---|---|---|
| Service is internet-facing | Cloud posture (CSPM) | Often not a finding at all: a public load balancer is how the service is meant to work | Platform team |
| CVE-2021-44906 in the image | SCA / container scanner | One critical among hundreds in the backlog | Payments developers |
| Role can read every bucket | IAM review or CIEM | “Over-privileged role”: medium, queued for the next access review | Cloud / IAM team |
| Bucket holds settlement data | Data catalogue, or nobody | A label, not a finding | Data owner in finance |
Four facts, four teams, and only one of them is labelled critical, the CVE, which is competing with a few hundred other criticals for a developer’s attention. Nobody is negligent. The system is simply organised around tools, and attackers are not.
data
Exploitation of vulnerabilities as the initial way into an organisation rose sharply in recent years, and the use of stolen or misused credentials remains one of the most common actions in breaches. The pattern an attack path describes, getting in through an exposed weakness and then moving with a legitimate identity, is the combination those reports keep finding.
Sources: Verizon Data Breach Investigations Report, 2024 and 2025 editions; MITRE ATT&CK techniques T1190 (Exploit Public-Facing Application) and T1078.004 (Valid Accounts: Cloud Accounts).
Why existing tooling misses it
The problem is not detection. Every link above was detected. The problem is that each tool scores its own link in isolation, and a link’s isolated score says nothing about where it sits in a chain.
- The vulnerability scanner knows the CVE and its CVSS score. It does not know the image is deployed behind a public load balancer, or which role the container runs as.
- The cloud posture tool knows the role has
s3:GetObjecton*. It does not know a vulnerable, internet-facing workload is using that role. - The data catalogue knows the bucket is sensitive. It has no opinion on who can reach it from the internet.
- The SIEM would see the theft, afterwards.
A critical CVE in a long backlog, a medium IAM finding queued for the quarterly review, a public endpoint that is working as designed, and a data label nobody reads. Each team fixes in its own order.
A single P1 finding that names every link, cites the evidence for each, and says that removing any one of them closes the path. One owner, one SLA, one decision.
How InsightFortify builds the path
InsightFortify keeps code findings, container images and the cloud inventory in one place, so it can join them. The rule for a path is deliberately strict: every link must be something InsightFortify has evidence for, not something it assumes.
acme/payments-api:1.4.2
exposure: internet"] W --> V["Weakness
CVE-2021-44906 in minimist
open P1 or P2"] V --> R["Runs as
payments-api-task"] R --> D["Can reach
acme-payments-exports
marked sensitive"] style I fill:#fee2e2,stroke:#ef4444 style D fill:#fee2e2,stroke:#ef4444 style V fill:#fef3c7,stroke:#f59e0b
The five nodes of the demo path. Fix the weakness, take the workload off the internet, or narrow the role: any one closes it.
- Entry. An image registered as internet-facing, or a public compute resource in the cloud inventory, with an open P1 or P2 finding in the image or in the repository it is built from.
- Identity. The cloud role the workload runs as, either recorded on the image or taken from the resource’s instance profile.
- Reach. What that role’s effective permissions, folded from every attached
and inline policy, allow on resources marked sensitive. If the role is an administrator, or can make
itself one through a route such as
iam:PassRole, the reach is the whole account.
Each path becomes one finding of its own, with the kind “attack path”, scored critical and tagged with the MITRE ATT&CK techniques it represents. It is triaged like anything else: confirmed, assigned, linked to a ticket, snoozed or dismissed with a reason. Paths are re-evaluated after every cloud scan, image registration and code scan of a linked repository, and a path whose link is gone closes itself with the note “a link in the path is gone”.
Who does what
The sequence below is how the path is found and closed in practice. Notice that the security team does not fix anything itself. Its job is to put one well-evidenced decision in front of the people who can make the cheapest change.
Marking the bucket sensitive is the step that turns three ordinary findings into one critical one.
When an image is registered or deployed, record whether it faces the internet and which role it runs as. This is usually one line in the deployment pipeline.
Mark the buckets and databases that hold regulated or confidential data. Paths end only at resources a person has called sensitive, so this is the step that gives a path its meaning.
Confirm the path, check each link against its evidence, and look at the identity’s blast radius to see what else the role can reach.
Upgrading minimist may need a release and regression testing. Removing s3:* on * from the role may be a ten-line policy change. Either closes the path.
Ship the fix through the normal release or infrastructure pipeline. InsightFortify does not change cloud resources itself.
The next scan re-evaluates the path. If the link is gone the finding closes with the reason recorded; if not, it stays open against its SLA.
Choosing which link to break
This is where the path view earns its keep with management. Without it, the conversation is “please patch this critical CVE”, which competes with feature work. With it, the conversation is “here are three ways to close a route to settlement data. Which is cheapest for you this week?”
| Option | Typical effort | What else it fixes | Watch out for |
|---|---|---|---|
| Upgrade minimist and redeploy | A release cycle | Every other path through that CVE | Transitive dependency: may need the parent package upgraded |
| Narrow payments-api-task | A policy change | Every other route through that role | Use what the role actually used, so nothing breaks |
| Take the workload off the internet | Rarely practical for a public API | All entry through this service | Usually not an option for customer-facing services |
| Unmark the bucket | — | Nothing | Only if the label was wrong. This is not a fix. |
In the demo, the role is the cheap link. The identity page shows the role’s blast radius, meaning every inventoried resource it can act on with the actions that apply, and where access-advisor data is available, a least-privilege starting policy built from the services it actually used.
What it means for each audience
For the CISO
Paths are the language of the board’s actual question: “could someone get to our customer data?” A count of open paths to sensitive data is a risk measure that does not need translating.
It also changes the remediation economics. You can close critical exposure with configuration changes while the slower code fixes go through normal release cycles.
For the AppSec lead
One finding replaces four tickets in four queues. The evidence for every link is on the finding, so the conversation with the platform team starts from facts, not from a scanner’s opinion.
Paths re-evaluate on every scan, so closure is verified, not asserted.
For the board
“How many routes exist from the internet to our regulated data, and how quickly do we close a new one?” is a question with a number for an answer, and that number should trend to zero.
It is also the question regulators and cyber insurers increasingly ask.
Outcome metrics to track
What to be careful about
- Labels drive everything. If nobody marks data as sensitive, no path ends anywhere. Make labelling part of how a data store is created, not an annual exercise.
- Exposure must be current. An image recorded as internal that has since been put behind a public load balancer is a path InsightFortify cannot see. Record exposure in the deployment pipeline, not in a spreadsheet.
- Scope today. Identity analysis, and therefore cloud paths, currently covers AWS. Azure and Google Cloud posture findings are scored and queued, but they do not yet form paths.
- A path is a hypothesis an attacker could test, not proof of compromise. Treat it as a high-priority exposure, not an incident, unless runtime evidence says otherwise.
Attackers do not read your backlog in priority order. They walk the shortest path to something valuable.
Rank the path, not the parts, and close it with whichever single change is cheapest this week.