Notifications
Clear all
Topic starter
02/08/2026 11:35 am
TL;DR: OX Security says 82% of known vulnerabilities originate in application code, while analysis of 101+ million findings across 178 organisations found only 2 to 5% were truly high risk, underscoring how legacy scanners bury actionable issues under noise. The practical shift is toward reachability, exploitability, and source-to-runtime context rather than severity alone.
NHIMG editorial — based on content published by OXSecurity: Top application security testing tools and AppSec risk analysis
By the numbers:
- OX Security analyzed 101+ million security findings across 178 organizations.
- Only 2 to 5% of alerts were truly high-risk.
Questions worth separating out
Q: How should security teams prioritise application security findings in cloud environments?
A: Security teams should prioritise application findings by combining severity with exposure, reachability, ownership, and business impact.
Q: Why do AppSec tools generate so much noise in mature environments?
A: Because many tools detect isolated technical flaws without understanding whether the weakness is exposed, reachable, or operationally important.
Q: What breaks when AppSec is treated as a late-stage scan?
A: Late-stage scanning misses the point where insecure code, hardcoded secrets, and risky dependencies enter the system.
Practitioner guidance
- Prioritise reachable and exploitable findings Tune AppSec workflows so remediation queues are driven by reachable code paths, exploitable conditions, and business impact rather than aggregate severity counts.
- Map findings to source ownership Require every high-risk finding to resolve to a repository, file, commit, or pipeline stage so the fix can be assigned to the team that introduced it.
- Shift security left on AI-assisted code Embed review and policy checks into developer workflows that use AI coding tools, because post-merge scanning is too late for fast-moving code generation.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Tool-by-tool comparisons of SAST, DAST, IAST, and SCA approaches across the SDLC.
- Hands-on test results showing how findings were correlated to specific files, commits, and repositories.
- Examples of alert triage and risk reduction across code, pipeline, and runtime exposure.
- Workflow detail on how the platform ties AI-native development activity back to source risk.
👉 Read OXSecurity's analysis of top application security testing tools and AppSec noise →
AppSec noise and reachability: are your controls keeping up?
Explore further
02/08/2026 12:49 pm
Application-layer risk is now an identity problem as much as a code problem. The article shows that exploitable exposure often starts where code, secrets, and authentication logic intersect. That is exactly where NHI governance becomes relevant, because API keys, service accounts, and tokens are often embedded in application workflows long before infrastructure teams see them. Practitioners should treat application security as part of identity control design, not a separate downstream activity.
A question worth separating out:
Q: How do identity teams fit into application security governance?
A: Identity teams need to care because many application risks are really credential and privilege risks in disguise. API keys, service accounts, tokens, and CI/CD credentials often move through code and pipeline stages before infrastructure controls can intervene. IAM and NHI ownership should therefore be part of the remediation path for high-risk application findings.
👉 Read our full editorial: Application layer risk outpaces infrastructure-first AppSec strategies
