Notifications
Clear all
Topic starter
02/08/2026 11:25 am
TL;DR: Application vulnerability exploitation now accounts for 31% of initial access vectors, overtaking credential abuse at 13%, while 82% of organisations report security debt and 66% of critical long-lived flaws originate in third-party code, according to the 2026 Verizon DBIR and Veracode research. Continuous, risk-based detection across code, dependencies, containers, and runtime is now a core control, not a development extra.
NHIMG editorial — based on content published by Veracode: What is Application Threat Detection and How Does it Work?
By the numbers:
- Exploitation of vulnerabilities now accounts for 31% of initial access vectors, overtaking credential abuse at 13%.
- 66% of the most critical, long-lived vulnerabilities originate from third-party code.
- Security debt now affects 82% of organizations.
Questions worth separating out
A: Prioritise by exploitability, exposure, and business impact, not by severity alone.
Q: Why do third-party libraries create so much application risk?
A: Because teams often depend on code they did not write, fully review, or even know is present in production.
Q: What breaks when application threat detection is only run before release?
A: Point-in-time testing misses flaws introduced after the scan, especially in fast-moving pipelines, runtime conditions, and dependency updates.
Practitioner guidance
- Gate code changes on security findings that are exploitable in context Tie CI/CD blocking rules to exposure, exploitability, and application criticality so teams do not ship high-risk flaws into production.
- Treat dependency inventory as a live control Track third-party and transitive components continuously, not as a periodic audit task, and require ownership for each high-risk package before release.
- Scan containers for secrets as well as vulnerabilities Include base image packages, Dockerfile misconfigurations, and embedded credentials in every image scan so secrets do not become persistent access paths.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- How the vendor layers SAST, DAST, SCA, and container scanning into a single application threat detection workflow
- Examples of risk-based prioritisation logic for exploitability, exposure, and business impact
- The article's breakdown of where security debt accumulates across the SDLC and why remediation stalls
- Practical guidance on using detection results to guide developer fixes and release decisions
👉 Read Veracode's analysis of application threat detection and security debt →
Application threat detection and security debt: are your controls keeping up?
Explore further
02/08/2026 12:42 pm
Application threat detection has become an identity-adjacent control, not just an AppSec function. When code flaws expose secrets, tokens, or service accounts, the security problem moves directly into NHI governance. That means application security teams and identity teams need a shared view of where credentials live, how they are used, and how quickly they can be abused. The practical conclusion is that application-layer detection must feed identity and secret governance workflows.
A question worth separating out:
Q: How do organisations know if application threat detection is actually reducing risk?
A: Look for fewer exploitable findings in public-facing services, shorter time to remediation for high-risk issues, and a decline in security debt over time. Scan counts alone do not prove progress. The right measure is whether the programme is shrinking the set of flaws an attacker can realistically use.
👉 Read our full editorial: Application threat detection now starts at the code layer
