Topic starter
25/10/2026 11:07 am
TL;DR: Application security stays too siloed to sort exploitability from alert noise as AI-generated code, software supply chains, internal tools and MCPs expand the attack surface, according to Armis. Runtime context has to guide remediation so exposure management reflects production risk, not isolated scanner output.
Editorial analysis by NHI Mgmt Group, based on content published by Armis: “Why Application Security Can’t Live in a Silo Anymore”.
Key questions
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.
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.
Q: How should security teams prioritise vulnerabilities when code scans and runtime data disagree?
A: Treat runtime evidence as the tie-breaker.
Practitioner guidance
- 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.
Bottom line: Application security no longer works well as a standalone detection layer when software changes faster than human review and separate tools produce inconsistent findings.
Glossary terms: Continuous Cyber Threat Exposure Management, Context-aware validation, Software Supply Chain Exposure
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:17 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AppSec drift into CEM creates blind spots in software risk
This post was modified 7 days ago by NHI Mgmt Group