Chain analysis is the best tool we've gained in recent years. It turns a list of vulnerabilities into a map of attacks. It shows how LOW and MEDIUM findings together become CRITICAL. It closes the gap between what defenders see and what attackers build.
But every model has limits.
If you don't know them, you'll end up with a false sense of security. Worse — you'll start making decisions based on an incomplete picture.
This article covers three scenarios where chain analysis does not give you an answer. Not because it's bad. Because it's static analysis, and attacks often happen in dynamics.
Boundary 1. The Chain Exists — But It Doesn't Connect at Runtime
Chain analysis finds paths in code. It sees that a token flows into an eval(), and the result of that eval() flows into a shell_exec(). Correct. Chain built.
Problem: at runtime, there may be defenses between those steps that static analysis cannot see.
Examples:
- A check like
if (user.role != 'admin') { return; }before the dangerous operation - A variable that passes validation in one thread but not another (a race condition static can't detect)
- A value that comes from a database, not from user input — but static analysis cannot prove that
Chain analysis will say: "path exists." In reality, the path is blocked.
What to do about it?
Chain analysis should estimate probability, not assert "exploitable." Flags like EXPLOITABLE, TRACED, STATIC_SAFE, UNKNOWN are honest admissions that static analysis has limits.
And crucially: chain analysis is not a replacement for runtime testing. It's a filter. It says: "look here." Not "this will definitely be compromised."
Boundary 2. The Chain Exists — But Privileges Prevent Completion
A classic example from real audits.
Chain analysis builds a path: user input → API request → command execution on the server. Everything lines up. CRITICAL.
But the context missing from analysis: the API endpoint requires the system_admin role. The user has viewer. The privilege check exists in the code. It's just in a different file. Static analysis didn't trace that far.
Result: the chain exists. Exploitation is impossible.
Why is this dangerous?
Because if you trust chain analysis as truth, you'll start fixing things that don't need fixing. You'll burn engineering hours closing a path that was never open.
What to do about it?
Chain analysis needs to be able to read access policies. Not just code. Roles, permission matrices, middleware. Without that, any path through an admin endpoint will look CRITICAL.
But the honest answer: static analysis will never be perfect at this task. Because access policies often live at runtime — in databases, configuration files, external systems.
So you need a hybrid model: static builds candidates. Runtime confirms or rejects.
Boundary 3. No Chain in Code. But an Attack Still Happened.
This is the most painful boundary.
You scanned everything. Chain analysis found nothing. The posture index is high. The gate is green. A week later — incident.
What happened?
The attack left no traces in your code. Because it happened outside your repository.
Examples:
- Supply chain: a dependency with no known CVE, but its maintainer was compromised. Code didn't change. Chain analysis sees no threat.
- Social engineering: a developer received an email from "IT support" asking to install an update. They did. Nothing in code.
- Configuration: an S3 bucket is open. The code never mentions that bucket. Chain analysis doesn't see it.
- CI/CD pipeline: a GitHub Actions token leaked. The attacker ran their own workflow. The repository code never changed.
Chain analysis analyzes your code. Attacks often happen outside your code.
What to do about it?
Chain analysis is a necessary layer — but not sufficient.
It needs neighbors:
- SCA (dependency scanning) — even without known CVEs, based on behavior
- CI/CD analyzer — because pipelines are code that executes code
- Infrastructure as Code scanning — configuration is attack surface
- Secrets detection — not just in code, but in logs, env, history
And most importantly: chain analysis must be able to correlate signals across layers. A leaked CI token + an open S3 bucket + a dependency with suspicious updates — that's a chain. But it doesn't live inside src/.
What This Means for Your Security Program
Three takeaways you cannot ignore.
1. Chain analysis does not replace runtime. It narrows the suspect list.
Mistake: "We have no chains → we are secure."
Truth: "We have no visible static chains → we don't know about runtime."
Runtime testing, fuzzing, penetration testing are still required. Chain analysis doesn't make them unnecessary. It makes them more targeted.
2. Chain analysis must be honest about uncertainty.
The best chain analysis is one that says "I don't know" instead of inventing an answer.
Flags like TRACED (path traced but exploitability unknown), UNKNOWN (insufficient information) — these are not weaknesses. They are engineering honesty.
False certainty is more dangerous than no analysis.
3. If the attack left no traces in code — chain analysis won't help.
This is not a problem with chain analysis. It's a problem with assuming all security lives in the repository.
Attacks through CI/CD, dependencies, configuration, people — they are just as dangerous. And they don't look like eval($_GET['input']).
Your security program must include:
- Pipeline security (who can run what)
- Dependency integrity (not just CVEs, but behavior)
- Secrets detection and rotation (everywhere, not just in code)
- Infrastructure drift detection (configuration that diverged from declared)
Chain analysis is a compass. But a compass doesn't show obstacles. It shows direction.
Conclusion
Chain analysis is the best tool for one class of problem: finding paths in code that connect multiple vulnerabilities into a single attack.
It is not the best tool for:
- proving a path does not exist (because static can't know runtime)
- detecting attacks outside code (because they're not there)
If you build a security program on chain analysis alone — you've built a house without walls or a roof. You have a compass. You don't have protection from the wind.
Chain analysis should be the core — not the entire program.
And a core without a shell is just a pretty rock.
Top comments (0)