DedSec Application Security
Every scoring framework in common use rates a finding in isolation. What is the impact of this issue, on this asset, assuming nothing else. It is a reasonable way to make a single number comparable across organisations, and it is close to useless for predicting how you get breached.
Attackers do not exploit findings. They compose them. The interesting property of a chain is that it is worth more than the sum of its parts, and the parts are routinely things a triage queue filed as "informational" and "medium, no fix planned".
The example below is constructed to show the shape of the problem. It is not drawn from a customer engagement.
Start with a verbose error page. It appears in the queue as informational: a stack trace on an unhandled exception, disclosing the framework and its version, plus a couple of internal class names. Nobody is going to prioritise it.
Second link: composition analysis reports a deserialisation vulnerability in a library the application depends on. It is a known CVE, it is not directly in your code, and on a normal week it sits in the dependency backlog. But the version disclosed by the error page tells an attacker exactly which library and which version they are dealing with, so they are not guessing — and reachability analysis says the vulnerable path is reachable from a request handler, which is why it should not have been in the backlog.
Third link: a missing authorisation check on an internal endpoint. Filed as medium because the endpoint is not linked from anywhere and takes an opaque identifier. The class names in the stack trace suggest the route naming convention, and the identifier format is guessable from a valid one.
Individually: an info, a backlog CVE, and a medium that nobody could see a path to. Together: an unauthenticated request reaches a reachable deserialisation flaw whose exact version is known, and the resulting access is not constrained by the authorisation check that was never applied. Nothing in that sequence is exotic, and no single item in it would have been prioritised on its own.
Chains also cross the boundary between what you build and what you expose.
A staging host survives a project and stays on the internet, which is exactly the class of asset that external discovery exists to find. Meanwhile a credential was committed to a repository eighteen months ago and removed a week later, which is why secret detection reads the whole git history rather than the diff. The credential still works, because rotation never happened — nobody knew it had leaked. The staging host accepts it, and staging shares a database with something that matters.
Neither half is remarkable. An old host, an old commit. The chain is the whole finding, and it is only visible if somebody is looking at both halves.
Three structural reasons, all fixable:
Isolation is the scoring assumption. The framework explicitly asks you to rate the issue on its own. Chain value is therefore invisible by construction, not by oversight.
Information disclosure is systematically underrated. Version banners, stack traces, verbose errors, predictable identifiers and directory listings have no impact by themselves. Their entire value is as an input to the next step, and no per-finding model prices that.
Findings live in separate systems. This is the practical blocker in most organisations. If SAST output is in one tool, dependency findings in another and dynamic results in a third, no analysis can relate them, because they do not share identity. You cannot chain across systems that cannot name the same thing the same way.
AppSecD's AI layer assembles attack chains across findings and assesses business impact, as part of the 27 configurable AI features. What makes that possible is not the model; it is the substrate underneath it:
Chains change the remediation conversation, and mostly for the better.
You do not have to fix every link. Breaking one usually collapses the path, so the question becomes which link is cheapest to break — often the informational one, because suppressing a stack trace is a configuration change while patching a deep transitive dependency is a release. Fix the cheap link today and the expensive one on schedule.
You do have to file the chain as its own thing. If the chain exists only in an analyst's head, the three constituent findings get triaged separately again next month by someone who has never seen it, and the informational one gets closed. In AppSecD the constituent findings carry ageing, an SLA and an owner, and closing one requires maker-checker approval — which is the mechanism that stops a link being quietly dismissed while the chain it belongs to stays open.
And it is worth taking chains back to the design stage. Threat modelling maps components, trust boundaries and data flows before the code exists, and the chains you keep finding are evidence about which boundaries are not real. Repeatedly discovering paths that cross from an unauthenticated surface into an internal service says something about the architecture that no individual finding will ever say.
Look at your lows. Not all of them — the ones that disclose something. Versions, internal names, identifier formats, error detail, anything that tells an attacker where to aim. They are the joints in almost every chain, they are cheap to fix, and they are the findings your process is most reliably built to ignore.