Reference · Application security
Application security risk in the code you didn’t write
An application is the code your team writes and the open-source code it is built from. AppSec programmes grew up around the first half. The second half is now most of what ships, and it carries its own kinds of risk, each with a clear question and a clear answer.
Updated 8 Nov 2026 · by the depproof team
In one sentence: application security risk is the chance that what you ship can be used against you or your customers, and in a modern application most of what you ship is dependencies, so most of the work is knowing them completely and deciding about them deliberately.
This page is the hub of the depproof AppSec risk guide. Every page in the guide is listed below.
Two halves of every application
The first half is the code you wrote. SAST, code review, DAST and secrets scanning exist for it, and most teams have a mature answer for each.
The second half is the code you didn’t: libraries you declared, and the far larger set they bring in. Black Duck’s 2026 audit of commercial codebases found open source in 98% of them, with a mean of 1,180 open-source components per application. Most of those are transitive dependencies that nobody on the team selected, and they are part of the product all the same.
That is why AppSec risk and dependency risk have converged. The OWASP Top 10:2025 ranks Software Supply Chain Failures third, and half of the community survey respondents ranked it first. The category started in 2013 as “Using Components with Known Vulnerabilities”; OWASP notes it has since grown to cover supply chain failures of every kind.
The six application security risks in your dependencies
“Vulnerable dependencies” is one row of six. Each row is a question a security owner, an auditor or a customer will eventually ask, and each has an answer you can have ready.
| Risk | What good looks like | Go deeper |
|---|---|---|
| Known vulnerabilities Does any component we ship have a published advisory? | Every component in the resolved graph matched against open advisory data, with the CVE ID reported. | OSV vs CVE |
| Exploitation Which of those findings are being used by attackers right now? | Exploitation evidence (KEV, EPSS) ranked above severity alone, so the first fix is the one that matters. | CVSS vs EPSS vs KEV |
| License obligations Can we distribute what we ship, on the terms it carries? | A license for every component, direct and transitive, checked against the policy you set. | Which licenses you can ship |
| Maintenance Is anyone still shipping fixes for this? | End-of-life and unmaintained components visible with the evidence behind each call, before a fix is needed. | End-of-life dependencies |
| Malicious packages Did anything hostile arrive through the registry? | Known-malicious package versions flagged the same way a vulnerability is. | Supply chain security |
| Blind spots Did the scan see everything we ship? | A scan that states how much of the graph it resolved, and says so when it could not see all of it. | Zero findings is not zero risk |
For scale, from the same public sources: the 2026 OSSRA found license conflicts in 68% of audited codebases, which it attributes to growth in transitive dependencies, and components with no development in two or more years in 93%. Sonatype identified more than 454,600 new malicious packages in 2025. None of these is rare, so each deserves a standing answer rather than a scramble.
Posture, not a findings count
A findings count goes up when you scan more and down when you scan less, so on its own it says little about whether you are safer. Risk posture is the set of numbers that do move with real improvement:
- Coverage. How many repositories are scanned, and how much of each dependency graph the scan actually resolved. A clean result is worth most when you know the scan saw the whole graph.
- Exposure. How many findings in shipped code carry evidence of exploitation. CISA’s Known Exploited Vulnerabilities catalog is the authoritative list of vulnerabilities exploited in the wild, and CISA recommends it as an input to prioritisation. Findings in dev-only dependencies belong in a different queue from the ones in what you ship.
- Decisions. How many accepted risks have an owner, a reason and an expiry. A recorded waiver, and VEX for customers, turn “we looked at it” into something you can show.
- Response. How long it takes to answer “are we affected, and where?” when an advisory lands. Across every repository, that is a lookup rather than a project when the inventory already exists.
These four are also what the outside data points at. Verizon’s 2026 Data Breach Investigations Report found that exploitation of vulnerabilities is now the most common initial access vector for breaches, at 31%, that breaches involving third parties reached 48%, and that only 26% of KEV-listed vulnerabilities were fully remediated during 2025. Exposure and response are the two numbers that change that picture.
What the frameworks ask for
- OWASP Top 10:2025, A03. Software Supply Chain Failures: track the versions of every component you use, including nested (transitive) dependencies, and whether any of them is vulnerable, unsupported or out of date.
- NIST SSDF (SP 800-218). PW.4.4 asks you to verify that open-source and other third-party components comply with your requirements throughout their life cycles, and gives building automatic detection of known vulnerabilities into the toolchain as an example.
- Customer and auditor evidence. An SBOM per release, and a ready answer to an SBOM request. The SBOM is the artifact; the assurance comes from the decisions behind it.
Where to start
- 1 · A complete inventory. The full resolved graph of every repository, from a scan that says how much it saw.
- 2 · Rank on exploitation. KEV and EPSS alongside severity, applied to what you ship first.
- 3 · Set policy once. The licenses you allow, the findings that stop a merge, and who can accept a risk.
- 4 · Record the decisions. Waivers with an owner and an expiry, and VEX for customers who scan your artifacts.
- 5 · Watch posture across the estate. Coverage, exposure, decisions and response, tracked over time in one place.
Where depproof fits
depproof covers the dependency half of application security risk, and works alongside the SAST, DAST and secrets tools you use for the code your team writes.
- Know. The full resolved graph for Maven, Gradle, npm, Python and Go, checked for known vulnerabilities, license obligations, maintenance status and known-malicious packages. When a scan could not see the whole graph, it says so.
- Prove. A CycloneDX SBOM from every scan. With the hub: exploitation evidence (KEV and EPSS) on every finding, posture across every repository, waivers with an owner and an expiry, and an audit trail of each decision.
- On your terms. It runs on your own infrastructure; your source and findings never leave it.
The AppSec risk guide, page by page
Foundations
- What is software composition analysis?: The AppSec practice for the dependency half.
- Transitive dependency risk: Why the full graph is the inventory worth having.
- Software supply chain security: Where dependencies meet the build and the artifact.
Vulnerabilities and exploitation
- OSV vs CVE: Which data can be matched against your dependency tree.
- CVSS vs EPSS vs KEV: Which findings to fix first.
- Why npm and pnpm audit miss vulnerabilities: The limits of built-in audit commands.
- Are dev dependencies a security risk?: Telling what ships from what only builds it.
Maintenance and blind spots
- End-of-life dependencies: The risk with no CVE.
- Zero findings is not zero risk: When a clean report means the scan did not see everything.
- The part of SCA that never finishes: Keeping up once the first scan is done.
Decisions and evidence
- VEX and vulnerability waivers: Recording what you decided, and telling customers.
- Dependency governance: Posture across every repository.
- Self-hosted SBOM generation: The inventory as an artifact you can hand over.
- Responding to an SBOM request: What a customer or auditor asks for.
License obligations
- The License Guide: Which open-source licenses you can ship, license by license.
Our research
- Findings that never ship: How many vulnerabilities sit in dev-only dependencies.
- Nobody left to fix it: How many dependencies have no maintainer.
- What your SBOM cannot say: Whether your SBOM can tell shipped packages from test tooling.
- Shipped versus source: An install-time risk a CVE scanner does not see: do packages match their source?
Frequently asked questions
What is application security risk?
Application security (AppSec) risk is the chance that the software you build and ship can be used against you or your customers: a vulnerability an attacker can exploit, a component you are not allowed to distribute, or a gap you cannot see. It spans the code your team writes and the open-source and third-party code it is built from. For most modern applications the second part is the larger one.
What is the difference between AppSec risk and software supply chain security?
They overlap in the middle. AppSec risk is about the application: the code you wrote and the dependencies inside it. Software supply chain security is about everything that carries the application to the customer: the dependencies, where they come from, how the build runs, and whether the artifact you ship is the one you built. Dependency risk is the part both disciplines share, which is why it is usually where a programme starts.
How do you measure AppSec risk posture?
With a few numbers you can track over time rather than a single findings count. Coverage: how many of your repositories are scanned, and how much of each dependency graph the scan resolved. Exposure: how many findings in shipped code carry exploitation evidence such as a CISA KEV listing. Decisions: how many accepted risks have an owner, a reason and an expiry. Response: how long it takes to answer “are we affected, and where?” when a new advisory lands.
Is SCA enough for application security?
No, and it is not meant to be. SCA covers the dependencies: their known vulnerabilities, license obligations, maintenance status and known-malicious versions. SAST and code review cover the code your team writes, DAST covers the running application, and secrets scanning covers credentials. A complete AppSec programme uses each for the part it was built for; SCA is the one that covers most of the code by volume.
Where does an SBOM fit in AppSec risk?
An SBOM is the inventory that AppSec decisions rest on, and the artifact you hand to a customer or auditor to show them. It is one output of managing dependency risk rather than the goal: the value is in what the inventory lets you answer — which products contain a vulnerable package, which licenses you ship, what you decided about each finding.
Why does OWASP now call this “software supply chain failures”?
Because the risk outgrew its old name. The OWASP Top 10:2025 lists Software Supply Chain Failures at A03, and notes that the category began in 2013 as “Using Components with Known Vulnerabilities” and has grown to cover all supply chain failures, not only known vulnerabilities. That matches the six kinds of dependency risk on this page: vulnerabilities are one of them, not all of them.
Sources
- Black Duck — Open Source Security and Risk Analysis (OSSRA) 2026: open-source prevalence, component counts, license conflicts, maintenance.
- Verizon — 2026 Data Breach Investigations Report, executive summary: initial access vectors, third-party involvement, KEV remediation.
- OWASP Top 10:2025 — A03 Software Supply Chain Failures.
- CISA — Known Exploited Vulnerabilities catalog.
- Sonatype — 2026 State of the Software Supply Chain, open-source malware.
- NIST SP 800-218, Secure Software Development Framework, practice PW.4.4.
Figures are dated because they change. Last checked 28 September 2026 — verify against the sources above before relying on them.
Where to go next
- What is software composition analysis? The practice that covers the dependency half.
- Software supply chain security: where the dependency half meets the build and the artifact.
- Transitive dependency risk: why the full graph is the inventory worth having.
depproof is a self-hosted SCA tool for Maven, Gradle, npm, Python and Go. The Scanner is free for open source and organizations under $1M revenue; see pricing. Product, standard and organisation names are used nominatively; depproof is not affiliated with them.