TL;DR: Application security now spans SAST, DAST, SCA, IAST, secrets detection, and ASPM, but Arnica argues that most programmes still manage more noise than true coverage. The broader issue is not tool count alone, but whether controls can keep pace with AI-generated code, overlapping findings, and workflow-driven risk.
At a glance
What this is: This article argues that more AppSec tools are often producing overlapping findings and alert fatigue rather than complete coverage across code, dependencies, runtime behaviour and secrets.
Why it matters: For IAM and security teams, the key issue is whether application controls can keep pace with AI-generated code, secrets exposure and workflow-driven risk without drowning operators in noise.
Context
Application security tooling is supposed to reduce exposure between code creation and production release, but overlapping scanners can obscure more risk than they reveal. When teams add SAST, DAST, SCA, IAST and secrets detection without a governance layer, they often create duplicated findings, false positives and gaps in accountability.
The identity angle is real here because modern application pipelines now include secrets, tokens, service credentials and agentic code generation. That means AppSec governance is no longer just about code quality or vulnerability discovery, but also about who or what is allowed to introduce credentials, generate code and push changes into controlled workflows.
Key questions
Q: Why does AppSec tool sprawl increase risk in modern software environments?
A: Tool sprawl increases risk because fragmented scanners and dashboards weaken context, slow correlation, and create inconsistent policy enforcement. When teams cannot see how findings relate across the SDLC, they miss real exposure and spend time on duplicate alerts. Complexity also raises operational burden, making it harder to maintain expertise, integrate workflows, and respond quickly to emerging threats.
Q: Why does AI-assisted code create more AppSec risk even when the code looks clean?
A: Because the risk is in the review model, not just the syntax. AI-generated code can appear plausible and compile correctly while still embedding subtle flaws that downstream scanning catches too late. The governance gap is the delay between generation, review, and enforcement, not merely the volume of code.
Q: What do security teams get wrong about stack consolidation?
A: Teams often treat consolidation as a licensing decision when it is really a control-design decision. The right question is whether fewer tools will reduce duplicated approvals, improve auditability, and remove manual exception handling. If consolidation does not simplify the workflow, it is unlikely to reduce governance debt.
Q: How should security teams handle secrets found in application code?
A: Treat every secret in code as a governance issue, not just a coding mistake. Security teams should identify whether the secret is still valid, what systems it can reach, and whether it has been used elsewhere. Then rotate or revoke it, remove it from source control, and add build-time scanning so the same exposure does not recur.
Technical breakdown
Why appsec tool overlap creates more noise than coverage
Each AppSec category watches a different layer of the delivery chain. SAST inspects source, DAST probes running applications, SCA checks third-party dependencies, IAST instruments live test traffic, and secrets detection looks for credentials in code history and branches. The overlap starts when those categories flag the same issue from different angles, or when none has enough context to determine whether a finding is actually exploitable. That is why more tools can increase triage effort faster than they improve assurance. The technical problem is not that scanners are wrong, but that they are usually blind to each other’s output.
Practical implication: Treat overlap as a governance problem and normalise findings into one prioritised queue before adding another scanner.
How ASPM changes the control model for application security
Application Security Posture Management sits above individual scanners and tries to turn fragmented findings into a decision layer. Instead of asking only whether a vulnerability exists, ASPM asks how important it is in context, such as whether code is live, who owns the asset, or whether the issue is reachable from production. That does not eliminate scanners, but it changes their role from isolated detectors to input sources for a broader risk model. In practice, ASPM is most useful when it correlates duplicate findings, ranks remediation by business context, and feeds risk back into developer workflows without requiring manual reconciliation.
Practical implication: Use ASPM to prioritise exposure by reachability and ownership, not by scanner severity alone.
Why AI-generated code breaks old AppSec assumptions
Traditional AppSec tooling assumes a human writes code, reviews it, and merges it through a visible workflow. AI-generated and agentic code breaks that assumption because changes can be produced quickly, merged frequently, and created without the same human review path that older controls expect. Existing tools can still scan the output, but they were not designed to reason about provenance, generation context, or the speed of autonomous pipelines. That is the governance gap: the code may be technically scanned, yet the organisation still lacks assurance about who or what introduced it and under what policy boundary.
Practical implication: Extend controls from code content to code provenance so automated generation is visible before merge.
Threat narrative
Attacker objective: The objective is to exploit application weaknesses, exposed secrets or unsafe code paths before security teams can reliably triage and contain them.
- Entry occurs when developers or AI agents introduce code, secrets or dependency changes into repositories and pre-pipeline workflows.
- Credential access happens when secrets detection or repository scanning fails to catch hardcoded keys, tokens or connection strings before exposure.
- Impact follows when overlapping tools create alert fatigue, leaving exploitable application flaws, exposed credentials or unsafe AI-generated code insufficiently governed.
Breaches seen in the wild
- New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
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
AppSec sprawl is now a governance failure, not a tooling preference. Once programmes cross a handful of scanners, the main risk becomes duplicated findings, inconsistent ownership and blind spots between tools. SAST, DAST, SCA and secrets detection each cover part of the attack surface, but none can substitute for a decision layer that tells teams what matters now. The practitioner conclusion is to govern the stack as a programme, not a product list.
Provenance is becoming the missing control plane for AI-generated code. Traditional scanners can inspect the result, but they do not tell you whether the code came from a human, a copiloted workflow or an agentic pipeline. That gap matters because security programmes still certify output while the real risk increasingly sits in how that output was created. The practitioner conclusion is to treat provenance as a first-class control, not a metadata extra.
Secrets detection is still one of the few AppSec controls that directly intersects with NHI governance. Hardcoded credentials, tokens and connection strings are non-human identities in practice, even when teams treat them as just another code issue. The article’s overlap discussion shows why secret exposure cannot be handled only as a developer hygiene problem. The practitioner conclusion is to align appsec telemetry with NHI lifecycle control so exposed credentials are discovered, rotated and revoked as governance actions.
Consolidation only helps when it preserves depth at the highest-risk layer. Bundling tools can reduce noise, but it can also flatten the detail needed to distinguish dead-code issues from live-service exposure. The market is moving toward fewer consoles and more orchestration, yet organisations still need deep detection at the stages where risk is introduced. The practitioner conclusion is to consolidate around workflow and context, not around contract count.
ASPM is becoming the programmatic layer for evidence, not the answer to every AppSec problem. Aggregation and ranking help, but they do not fix poor source controls, weak pipeline governance or unsafe AI code generation. That means teams should use ASPM to improve prioritisation while still maintaining strong controls at code, dependency and secret-issuance points. The practitioner conclusion is to pair orchestration with source-level governance.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Tool sprawl becomes operational debt once it outpaces the team’s ability to correlate findings. AppSec programmes should assume that every extra console adds triage friction unless findings are normalised into a single risk model. The control question is not how many scanners you own, but whether they help you make faster decisions on live exposure.
AI code governance needs to move upstream from scan time to generation time. If a pipeline can emit code faster than a reviewer can inspect it, security cannot rely on post-hoc detection alone. Programmes should watch for provenance controls, policy checks and workflow telemetry that capture who or what created the change before merge.
Secrets hidden in code remain a live credential problem, not a static code-quality issue. According to the State of Secrets Sprawl 2026, internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe. That makes repository scanning and revocation discipline part of NHI governance, not just developer hygiene.
For practitioners
- Consolidate scanner output into one risk queue Map SAST, DAST, SCA, IAST and secrets findings into a single triage model so duplicate alerts are removed before analysts review them.
- Prioritise findings by reachability and ownership Rank issues higher when the vulnerable code is live, exposed or owned by an active service rather than treating every medium or high finding as equal.
- Add provenance checks for AI-generated code Track whether code was written by a human, a copilot or an agentic workflow before merge so security review can follow the creation path.
- Treat exposed secrets as NHI incidents When scanners find hardcoded credentials, tokens or connection strings, route them through revocation and rotation workflows, not just code remediation tickets.
- Measure tool depth before buying more coverage Test whether each platform catches real issues in your own codebase, then compare false positives, workflow fit and remediation speed against current demand.
Key takeaways
- AppSec sprawl creates operational noise when overlapping scanners produce more findings than teams can reconcile into action.
- AI-generated code challenges traditional AppSec assumptions because the risk is no longer only in the code content, but also in the provenance and workflow that created it.
- Secrets detection still matters because repository-stored credentials can turn code exposure into direct access, so revocation and rotation must follow discovery.
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, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Overlapping scanners and blind spots mirror poor security inventory across appsec tooling. |
| Recommendation — Inventory all AppSec controls and remove blind spots where no tool owns a risk class. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Secrets and token exposure in code turns authorization failures into direct access risk. |
| Recommendation — Tighten access permissions around repositories and secret-bearing workflows to reduce credential abuse. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about securing application delivery and reducing vulnerabilities in software workflows. |
| Recommendation — Apply application security controls across the SDLC and validate coverage at each release stage. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets and tokens enable credential access that can be followed by lateral movement. |
| Recommendation — Map exposed secrets and token leakage to TA0006 and hunt for follow-on lateral movement. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hardcoded credentials and tokens in repositories are direct NHI secret leakage risks. |
| Recommendation — Scan repositories continuously for leaked credentials and revoke any exposed non-human secret immediately. | ||
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.
- Source Code Provenance: Source code provenance is the record of where code came from, how it was created and what workflow introduced it into the repository. It matters because security teams increasingly need to know whether a change was written by a person, assisted by AI or generated by an autonomous agent.
- Alert Fatigue: Alert fatigue is the condition where a security team receives so many low-value alerts that important events become harder to notice. In monitoring programs, it usually signals poor rule tuning, weak prioritisation, or a mismatch between detection logic and operational reality.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners connect code, credentials and lifecycle controls across modern delivery pipelines.
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