Application layer risk outpaces infrastructure-first AppSec strategies

At a glance

What this is: OXSecurity argues that application-layer risk is more prevalent than infrastructure-first AppSec strategies assume, and that most scanner output is noise rather than actionable exposure.

Why it matters: For IAM, PAM, NHI and software security teams, the practical question is not how many findings exist, but which ones are reachable, exploitable and traceable back to the code or control that created them.

By the numbers:

• 82% of known vulnerabilities originate in the application layer, according to OXSecurity.
• OXSecurity analysed 101+ million findings across 178 organisations.
• Only 2 to 5% of alerts were truly high-risk, according to OXSecurity.

Context

Application security fails when teams treat the infrastructure layer as the main risk surface and leave application-layer flaws to noisy after-the-fact scanning. In practice, the problem is not only the presence of vulnerabilities, but whether findings can be tied to runtime reachability, exploitability and the business systems they can actually affect.

That gap matters to identity security as soon as application flaws expose tokens, secrets, session paths or delegated access flows. It also matters to NHI governance because build pipelines, service accounts and agentic development tooling can turn code-level weaknesses into credential exposure, privileged misuse or supply-chain compromise.

Key questions

Q: What breaks when AppSec teams rely on severity scores without identity context?

A: Severity scores break down when they are used without ownership, reachability, and delivery context. A critical flaw in unreachable code is not the same as a moderate flaw in a live service with active deployment paths. Without identity context, teams spend time on findings that no current owner can fix quickly, while easier-to-exploit issues stay in the queue.

Q: Why do application-layer flaws create more practical risk than infrastructure-only scans suggest?

A: Application-layer flaws often sit closer to authentication logic, session handling, business flows and secrets use, which means they can turn directly into account abuse or sensitive data exposure. Infrastructure scans may miss those paths entirely or overstate issues that cannot be reached. That is why application context changes the security decision, not just the report format.

Q: What are the signs that an AppSec program is struggling to separate real risk from noise?

A: Common warning signs include too many findings scattered across disconnected tools, slow triage, and developers being overwhelmed by alerts that are not clearly prioritized. When security teams cannot correlate findings into a single risk picture, true issues get buried. Strong programs reduce noise, consolidate signals, and help teams focus on the vulnerabilities that matter most.

Q: How should teams respond when application findings cannot be traced to the code that caused them?

A: They should treat that as a governance failure, not a reporting inconvenience. If a production issue cannot be tied to the file, commit, dependency or pipeline stage that introduced it, teams cannot assign accountability or prevent recurrence. Provenance and pipeline metadata are essential for moving from detection to remediation.

Technical breakdown

Why reachability changes AppSec prioritisation

Reachability asks whether a vulnerable code path can actually be invoked from an exposed entry point under current deployment conditions. A scanner may find thousands of issues, but many are dead code, unreachable libraries, or defects behind controls that block exploitation. Prioritisation improves when static findings are joined to runtime context, because the question shifts from whether a flaw exists to whether an attacker can use it. That is why code-to-runtime correlation matters more than raw severity scores in mature AppSec programmes.

Practical implication: Use reachability to decide which findings enter the remediation queue and which remain informational.

How exploitability and business impact narrow the noise

Exploitability adds the attacker’s effort, preconditions and likely chain of actions to the assessment. Business impact then separates a technically real issue from one that would have limited operational effect even if exploited. In application security, these two lenses are critical because not every injection flaw, misconfiguration or weak dependency leads to meaningful compromise. The source article’s central point is that legacy scanners over-report without enough context, so teams end up triaging quantity instead of consequence.

Practical implication: Tune prioritisation around exploit paths and asset criticality rather than severities that are only loosely correlated with risk.

Why source-to-runtime traceability matters in modern SDLCs

Source-to-runtime traceability connects a production issue back to the exact file, commit, dependency, pipeline stage or AI-assisted code change that introduced it. This is increasingly necessary when code is produced faster than humans can review it and when multiple tools observe different parts of the lifecycle. Without traceability, teams can detect a vulnerability in production but still miss the control failure that allowed it through. The article’s PBOM concept is essentially an operational answer to that governance gap.

Practical implication: Maintain artefact, pipeline and change provenance so each issue can be assigned and fixed at its origin point.

Threat narrative

Attacker objective: The attacker aims to convert an overlooked application-layer flaw into practical access, data exposure or control over application behaviour.

1. Entry occurs when vulnerable application code, insecure dependencies or misconfigured build logic reaches production without enough contextual review.
2. Escalation follows when an attacker can reach the vulnerable path, abuse a token or session flow, or pivot from the application layer into deeper trust relationships.
3. Impact is realised as exposed data, account compromise, or control over application behaviour that traditional scanner noise failed to surface in time.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application-layer risk is now the control problem, not a side effect of infrastructure weakness. The article’s core finding is that most known vulnerabilities originate in application code, which means perimeter and cloud-first controls will always miss part of the real exposure picture. For identity programmes, that shifts attention toward session handling, token logic and delegated access paths that live inside the application itself. Practitioners should treat application-layer governance as a primary security domain, not a downstream hygiene task.

Noise reduction is a governance capability, not just a product feature. If 95% of findings are low value, the real issue is not scan volume alone but whether the organisation can separate signal from false urgency fast enough to act. That is why reachability, exploitability and business impact belong in the same prioritisation model. Teams that cannot do this will continue to confuse alert generation with risk reduction.

Source-to-runtime traceability is the named concept this market needs to internalise. Code, pipeline and cloud telemetry only become useful when they form one evidentiary chain from commit to production exposure. This matters for NHI governance because the same traceability model is what exposes where secrets, service identities and automated workflows were introduced. Security leaders should insist on provenance that can survive both AppSec and identity review.

AI-speed development collapses the review window that older AppSec models assumed. When coding assistants can create working code faster than security teams can inspect it, after-the-fact scanning becomes a compensating control rather than a primary one. That does not make scanning obsolete, but it does make prevention at creation and continuous validation more important. Practitioners should rework AppSec governance around where code is created, changed and deployed, not only where it is scanned.

What this signals

Source-to-runtime traceability is becoming the practical dividing line between AppSec programmes that reduce risk and programmes that merely collect findings. When teams can link a defect to the commit, dependency or pipeline stage that introduced it, remediation becomes an ownership problem instead of a scavenger hunt.

For identity-heavy applications, scanner output alone is not enough because the highest-value exposures often sit in session logic, token flows and delegated access paths. Security leaders should expect AppSec governance to converge with identity governance wherever code can create trust relationships.

The next maturity step is to treat exploitability as a control input, not a post-facto label. That changes what gets fixed first, what gets deferred, and what executives should see on risk reporting.

For practitioners

• Prioritise application-layer findings by reachability Classify issues by whether the vulnerable path is actually reachable in the deployed environment, then triage only those findings that can be exercised by a realistic attacker.
• Correlate findings with exploitability and business impact Add exploit preconditions, affected assets and likely blast radius to the triage workflow so severity alone does not drive remediation order.
• Tie every production finding back to source provenance Require file, commit, dependency and pipeline-stage attribution for each issue so the owner and fix point are unambiguous.
• Track application secrets and token paths as first-class risk Review where secrets, sessions and delegated access flows are introduced, stored and reused because application-layer flaws often become identity exposure.

Key takeaways

• Application-layer weaknesses create more practical exposure than infrastructure-first strategies assume, because the business logic that attackers actually exploit lives there.
• Most scanner output is low-value noise unless teams can separate reachable issues from theoretical ones.
• AppSec programmes now need provenance, exploitability and business impact to decide what gets fixed first.

Key terms

• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
• Code-to-runtime traceability: The ability to follow a change from source creation through pipelines and into the deployed environment. In practice, this lets teams understand whether a code path is merely theoretical or can actually reach credentials, data, or privileged services in production.
• Application Security Testing Service: A managed or platform-based delivery model for finding and prioritising software vulnerabilities across code, dependencies, secrets, containers, and infrastructure. It combines scanning with workflow integration and often adds remediation support, reporting, and governance features for enterprise development teams.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management for practitioners who need identity controls to keep pace with modern application delivery. It gives security and identity teams a common language for governing credentials, access and lifecycle risk across the stack.