TL;DR: Application security remains siloed from Cyber Exposure Management even as AI-generated code, software supply chains, internal tools and MCPs expand the attack surface, according to Armis. Detection without runtime context leaves teams triaging noise instead of prioritising exploitable risk, so AppSec now has to function as risk management rather than a separate scanner backlog.
At a glance
What this is: This is an argument that application security can no longer sit apart from Cyber Exposure Management because code volume, AI-assisted development and supply-chain risk have outgrown isolated scanning.
Why it matters: IAM, PAM and security teams should care because application risk increasingly determines where credentials, tokens and privileged workflows can be abused in production.
Context
Application security becomes a governance problem when teams can no longer tell which findings are exploitable, where they live, or who owns the fix. That gap widens as AI-generated code, internal tools, scripts and MCP-driven workflows increase the volume and speed of software change.
The practical failure is not simply too many alerts. It is that separate scanners, separate dashboards and separate ownership models make security and engineering work from different risk pictures, which is exactly where control gaps persist.
Key questions
Q: How should security teams prioritise vulnerabilities when code scans and runtime data disagree?
A: Treat runtime evidence as the tie-breaker. If a vulnerability appears in static analysis but the vulnerable function is never executed, it should not compete with issues that are both present and reachable. The right process combines advisory enrichment, code-path validation, and runtime confirmation before remediation is escalated.
Q: Why do AI-generated code and microservices make AppSec harder to govern?
A: They increase the number of code paths, dependencies and ownership boundaries that security has to understand at once. That creates more opportunities for subtle variants, supply-chain issues and misrouted findings to slip through. Governance becomes harder because the question is no longer just whether code is vulnerable, but whether the organisation can interpret and act on that vulnerability quickly.
Q: What breaks when application security stays separate from exposure management?
A: Findings lose the business context needed for prioritisation, so teams end up with long backlogs of alerts that are technically accurate but operationally unhelpful. The result is slower remediation, duplicated scanning and a weaker link between engineering work and actual risk reduction. In practice, that means the organisation cannot tell which issues matter now and which can wait.
Q: How do teams know if a vulnerability is truly exploitable?
A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it. Scanner data alone cannot answer that question reliably. Validation gives defenders evidence they can use to separate theoretical issues from immediate response priorities.
Technical breakdown
Why siloed AppSec tools fail to produce risk context
Traditional AppSec tooling is designed to detect patterns, not to interpret business impact. That works when software changes slowly and known issues dominate, but it breaks down when AI-assisted development, microservices and supply-chain dependencies generate new variants faster than static signatures can adapt. The result is a high-volume finding stream with little clarity on exploitability, runtime exposure or business reach. In practice, this means teams waste time ranking issues without knowing whether the weakness is theoretical or immediately actionable. See the Secure Coding Guide.
Practical implication: Correlate findings with runtime exposure and asset criticality before routing them into remediation queues.
How AI-generated code and supply-chain components change the attack surface
AI-assisted coding increases throughput, but it also expands the number of code paths, dependencies and generated variants that must be assessed. That makes the software supply chain part of the application attack surface, not a separate concern. Build systems, plugins and third-party components can introduce risk even when the developer-written code is clean. Security programmes that stop at static code review miss the operational reality that modern application compromise often arrives through composition, not just direct source code flaws. See the Application Security Guide.
Practical implication: Treat build provenance, dependency trust and component inventory as part of application security governance.
Why runtime-aware validation matters more than template matching
Template-based detection only works when a flaw resembles something already known. That model is brittle against subtle code variants, custom business logic and AI-generated patterns that do not match prior signatures. Runtime-aware validation adds a different question: does this issue exist in a live, reachable, exploitable path? That shift matters because context determines urgency. A vulnerability that is present in code but unreachable in production has a different governance answer from one exposed in an active workflow with business impact.
Practical implication: Use validation signals to separate exploitable issues from static findings that do not change production risk.
NHI Mgmt Group analysis
Application security has become an exposure management problem, not a scanner problem. The article describes a real governance shift: security value now comes from correlating application findings with exploitability, runtime behaviour and business criticality. Separate dashboards and siloed ownership make that impossible at scale. Practitioners should treat AppSec as part of enterprise risk prioritisation, not as a standalone defect pipeline.
Context is now the control boundary for modern software risk. AI-generated code and rapidly changing dependencies create findings that mean very different things depending on where they live and how they are used. That is why asset criticality, reachability and runtime validation matter more than raw detection volume. Teams that cannot attach context to findings will keep mistaking noise for risk.
Software supply chain exposure is now inseparable from application security. Build systems, plugins and dependencies have become part of the attack surface, so code review alone is no longer enough. The security programme has to govern provenance, trust and ownership across the full delivery path. For identity teams, that same lesson applies to tokens, service accounts and MCP-connected workflows that move software from build time into production.
The naming gap is the hidden operational failure. When teams cannot determine who owns a vulnerability, remediation slows even when the issue is clear. That is not a tooling nuisance, it is an accountability failure created by disconnected operating models. The practical conclusion is that application risk needs routing logic tied to ownership, service context and production dependency.
Modern AppSec has to align to how engineering actually works. If security guidance does not fit developer workflows, it will be bypassed or ignored. The article’s core message is that context-rich, embedded controls outperform detached review loops. Practitioners should build security into the delivery path so remediation happens where code is already moving.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: API Security Buyer's Guide
What this signals
Exposure management will increasingly absorb application security. The organisations that get ahead will stop treating code findings as a separate queue and start treating them as one input to enterprise exposure decisions. That means security, engineering and platform teams need a shared view of what is reachable, exploitable and owned.
Software supply chain trust will become a first-class governance issue. As AI accelerates code creation and dependency usage, the issue is no longer just defective code but untrusted composition. That is where application security intersects with identity governance, because build systems, service accounts and automation paths determine who and what can move software into production.
Contextual triage is the new control plane for AppSec. Static findings alone will keep producing backlog inflation, while production context will separate genuine risk from noise. Practitioners should expect their operating model to shift toward richer validation, ownership routing and decision support rather than raw detection volume.
For practitioners
- Embed exploitability context into triage Score vulnerabilities using runtime exposure, reachability and asset criticality before they enter remediation queues.
- Unify application findings across the delivery chain Connect code, build and dependency signals so the same issue can be traced from source to production without separate dashboards.
- Route findings to accountable owners automatically Map each application issue to a service owner, product team or platform owner so triage does not stall on handoffs.
- Validate AI-generated code paths in production context Test whether generated or modified code is reachable and exploitable in the environments where it will actually run.
Key takeaways
- Application security no longer works well as a standalone detection layer when software changes faster than human review and separate tools produce inconsistent findings.
- The most important governance change is context, because exploitability, reachability and ownership now matter more than raw alert volume.
- Practitioners should connect AppSec to exposure management so remediation decisions reflect production risk instead of isolated scanner output.
Related NHI Mgmt Group resources: Application Security Guide · Secure Coding Guide · API Security Buyer's Guide · AI Security Maturity Model
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, OWASP SAMM, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | The article focuses on secure coding context, code variants and architecture-level application risk. |
| Recommendation — Use V15 to embed security requirements into application design, review and remediation workflows. | ||
| OWASP SAMM | Governance — Governance | The piece argues that AppSec needs operating-model alignment and ownership rather than isolated detection. |
| Recommendation — Assess whether application security governance is embedded across engineering and risk decisions. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and recorded | The article is about identifying and contextualising application vulnerabilities across the enterprise. |
| Recommendation — Record application vulnerabilities in a risk model that includes exploitability, reachability and business impact. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | CIS Control 16 directly fits the article's focus on application security integrated into software delivery. |
| Recommendation — Strengthen application software security by embedding reviews, testing and context into delivery pipelines. | ||
Key terms
- Continuous Cyber Threat Exposure Management: Continuous cyber threat exposure management is a programme for discovering, validating, analysing, and remediating security exposure on an ongoing basis. It focuses on what is actually exploitable, not just what is theoretically vulnerable. The value comes from combining exposure data, control testing, threat intelligence, and business context into one prioritised workflow.
- Context-aware validation: Context-aware validation is the practice of evaluating code together with the circumstances that produced it. It looks at origin, intent, dependency choice, policy alignment, and assistant behaviour so security can judge whether a change is not only syntactically safe but also governance-compliant.
- Software Supply Chain Exposure: Software supply chain exposure is the risk that a trusted software component, update, dependency, build step, or delivery path can be altered or abused before it reaches production. It includes compromised code, poisoned packages, insecure CI/CD, stolen signing keys, and tampered artifacts that can introduce hidden access, malware, or data loss.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management for practitioners working across identity and security operations. It helps teams connect identity controls to the broader programmes that depend on them.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org