TL;DR: AppSec now spans SAST, DAST, SCA, secrets detection, and IAST, but no single control covers the full attack surface, according to Arnica. With AI-generated code, fragmented coverage, and noisy findings, ASPM is becoming a baseline requirement rather than a premium add-on.
At a glance
What this is: Arnica argues that modern AppSec requires coverage across five disciplines, and that Application Security Posture Management is now the baseline way to correlate them.
Why it matters: For IAM and security teams, the issue is not just code scanning but governance over how findings, ownership, and remediation flow across the software supply chain.
By the numbers:
- AI-assisted repositories grew by over 50% year-over-year, according to GitHub's 2025 Octoverse report cited by Arnica.
Context
Application security posture management is a governance problem as much as a tooling problem. When code is produced faster than security can review it, point-in-time scanners leave gaps between detection, prioritisation, and remediation. The practical question is no longer whether teams scan, but whether they can maintain continuous visibility across repositories, dependencies, secrets, and runtime exposure.
That question matters because the software supply chain now includes human-written and AI-generated code, third-party packages, and pipeline configuration decisions that all influence exposure. In identity-heavy environments, application findings often intersect with secrets, API credentials, and service access, which makes AppSec a control issue that extends beyond engineering alone.
Key questions
Q: How should security teams implement ASPM alongside DAST in modern application security programs?
A: Security teams should use ASPM as the orchestration layer and DAST as the runtime testing layer. ASPM centralises findings from multiple tools, correlates risk, and prioritises remediation. DAST adds evidence from running applications, especially for API flaws, authorization issues, and business logic problems that static tools can miss. The combination improves coverage without forcing teams to choose one control over the other.
Q: Why do fragmented AppSec tools struggle with AI-generated code?
A: Fragmented tools struggle because they each see only one part of the risk path. A code scanner may find a weakness, a supply chain tool may inspect dependency trust, and posture management may flag runtime exposure, but none of them alone can explain exploitability. AI-generated code increases the number of possible issues faster than teams can correlate them.
Q: What breaks when application security testing is fragmented across multiple tools?
A: Fragmentation creates overlapping findings, inconsistent policy enforcement, and slow triage because no single system can correlate code, dependency, secrets, and runtime context. The result is not just more noise, but weaker accountability for remediation. Mature teams reduce that problem by centralising ownership, normalising results, and tying each issue to the workflow where it can actually be fixed.
Q: Should AppSec leaders treat posture management as a baseline control or an advanced capability?
A: It should be treated as a baseline control whenever software is shipped at speed, because raw scan output is not enough to manage risk. If teams cannot correlate, prioritise, and route findings quickly, the programme creates alert fatigue instead of reducing exposure.
Technical breakdown
Why point-in-time AppSec controls leave blind spots
SAST, DAST, SCA, secrets detection, and IAST each inspect a different layer of the application lifecycle. SAST looks at source code, DAST observes the external attack surface, SCA maps dependency risk, secrets tools detect embedded credentials, and IAST instruments live execution. The problem is coverage fragmentation: each method sees only part of the failure path, and findings often arrive in separate tools with no shared priority model. That is why a vulnerability can be discovered multiple times, or not at all, without telling teams what actually matters first.
Practical implication: Practitioners need a unified risk view that correlates findings across tools before they decide what to fix first.
How ASPM changes the security operating model
ASPM turns application security from a sequence of isolated scans into a continuous posture model. Instead of asking whether a scanner found a flaw, teams ask whether the organisation can rank, track, and remediate exposure over time across repositories, pipelines, and services. That shift matters because the same vulnerability has very different risk depending on business context, exposure path, and whether the code is customer-facing or internal. In practice, ASPM is less about adding another scanner and more about giving security leaders a control plane for AppSec governance.
Practical implication: Use posture management to prioritise remediation by business context, not by raw scanner volume.
Why AI-generated code raises the floor for baseline controls
AI-generated code increases the volume and speed of application change, but it does not change the underlying security problem: insecure patterns can be reproduced at scale. When repositories grow quickly and code review cycles stay human-bounded, controls designed for slower development lose effectiveness. The result is that teams need earlier detection, better correlation, and developer-native delivery of findings. The baseline is no longer a single best-in-class scanner, but an operating model that can absorb high-code-volume environments without drowning engineers in noise.
Practical implication: Adopt controls that surface issues inside developer workflows and reduce the gap between code creation and security review.
Threat narrative
Attacker objective: Exploit fragmented application security coverage to preserve vulnerable code paths, exposed credentials, or dependency weaknesses until production.
- Entry begins when insecure code, vulnerable dependencies, or hardcoded secrets enter the repository or build pipeline.
- Escalation follows as those flaws move through staging and release workflows without being correlated into a single risk picture.
- Impact occurs when high-severity issues remain buried in alert noise or reach production before remediation ownership is clear.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
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
ASPM is becoming the control plane for AppSec governance: the article shows why isolated scanners no longer give security teams enough context to manage risk. When findings arrive from SAST, DAST, SCA, and secrets tools separately, the programme needs posture management to decide what matters first. The discipline is shifting from detection to governed prioritisation, which is the right response to code velocity and mixed human plus AI-generated development.
AI-generated code raises the baseline, not just the volume: the real issue is not simply more code, but more code produced faster than traditional review and tuning cycles can handle. That pushes teams toward controls that can correlate findings early in the SDLC and route them into the developer workflow. For AppSec leaders, this means the standard for acceptable coverage is now continuous repository visibility rather than periodic scan completeness.
Finding volume is not a security outcome: the article correctly separates scan quantity from signal quality. Security programmes fail when they treat more findings as better coverage, because raw output without prioritisation just creates triage debt. The practical lesson is to measure whether the programme reduces exposure time and remediation ambiguity, not whether it produces more alerts.
AppSec governance now intersects with identity and secrets control: secrets detection is no longer a narrow code hygiene task when API keys, tokens, and service credentials can become immediate access pathways. That means application security decisions increasingly influence NHI exposure, credential hygiene, and downstream access governance. Teams should treat AppSec posture as part of the broader identity security surface, not as a separate engineering-only concern.
From our research library:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Read next: Identity Security Posture Management (ISPM) Guide
What this signals
Application security posture now has to be governed, not just scanned: teams that rely on separate scanner outputs end up managing triage debt instead of reducing exposure. The practical change is to measure how quickly findings become decisions, not how many findings the platform can produce.
AI-assisted development makes continuous repository visibility the new floor: AI-generated and AI-assisted code increases the odds that vulnerabilities arrive faster than security review can keep up. That pushes AppSec closer to identity security because secrets, tokens, and service credentials can become operational access paths, not just code defects.
Finding volume is not a proxy for security maturity: programmes that celebrate alert counts often miss the more important question of whether the right issues are reaching the right owner. The control objective is to shorten exposure time and reduce ambiguity, especially when code is changing faster than governance can review it.
For practitioners
- Correlate scanner output into one posture view Aggregate SAST, DAST, SCA, secrets detection, and IAST results so teams can rank exposure by business context instead of triaging duplicate alerts in multiple consoles.
- Prioritise by exposure and business context Score findings in customer-facing services, critical dependencies, and credential-bearing code higher than issues in low-impact internal repositories.
- Shift secrets findings into access control workflows Treat hardcoded API keys, tokens, and credentials as active identity risk, then route remediation to the owners who can revoke or rotate access immediately.
- Measure developer friction alongside coverage Track false positive rates, time to fix, and how often findings reach the developer in workflow, because noisy controls are usually bypassed.
Key takeaways
- AppSec now has too many control layers for single-tool thinking to work, especially when development is accelerated by AI-assisted code.
- ASPM matters because it turns fragmented scanner output into an actionable risk picture that security teams can govern over time.
- For practitioners, the priority is not more findings but faster prioritisation, clearer ownership, and lower exposure time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AppSec findings now include secrets and service access paths that need governed authorization. |
| Recommendation — Apply PR.AA-05 to ensure application credentials and related access paths are tightly authorised and reviewed. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is centred on application security testing, scanning, and remediation governance. |
| Recommendation — Use CIS-16 to standardise secure application testing and remediation across the development lifecycle. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article explicitly covers API security and exposed application surface as part of AppSec coverage. |
| Recommendation — Use API8 to find and correct misconfigurations that expose application and API attack paths. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | The article focuses on testing methods and posture management across the SDLC. |
| Recommendation — Apply SA-11 to embed security testing and evaluation into development and release workflows. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Secrets detection exists to stop credentials becoming an attacker entry point. |
| Recommendation — Map exposed secrets to TA0006 and prioritise revocation before those credentials are abused. | ||
Key terms
- Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
- Secrets detection: Secrets detection is the identification of credentials such as API keys, tokens, certificates, and passwords in code, configuration files, or pipelines. In mature programmes, detection is paired with rotation, revocation, and ownership so exposed secrets do not remain usable.
- Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to connect application risk to identity control. It is suitable for security and identity teams building stronger governance across software and access pathways.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org