TL;DR: By the end of 2024, 30% of production code was AI-generated and 97% of commercial codebases contained open-source components, which makes coverage-first security harder to sustain, according to Apiiro. The practical shift is toward tools that understand runtime exposure, business impact, and developer workflow, because raw finding volume no longer maps cleanly to real risk.
At a glance
What this is: Apiiro argues that modern DevSecOps programs should prioritise contextual risk reduction over raw vulnerability counts.
Why it matters: That matters to IAM and security practitioners because software delivery now depends on controlling secrets, access, and runtime exposure across code, dependencies, and infrastructure.
By the numbers:
- By the end of 2024, 30% of production code was AI-generated, widening the review gap for security teams.
- 97% of commercial codebases contain open-source components, so one compromised dependency can spread risk across portfolios.
- 77% of engineering leaders already use AI for coding, which increases code volume faster than teams can review it.
👉 Read Apiiro's analysis of DevSecOps tool selection and risk-based application security
Context
Modern DevSecOps programmes fail when they optimise for coverage instead of business-relevant risk. The result is more findings, more noise, and less confidence that security teams are addressing the issues that actually affect delivery, runtime exposure, and trust in the software supply chain. In this context, application security has become tightly linked to identity and secrets governance because leaked credentials, overexposed service access, and poorly controlled build-time permissions can turn a code issue into an access problem.
That shift is visible in the way teams now evaluate security tooling. Context matters more than raw scan depth when code changes quickly, dependencies multiply, and developers work across IDEs, pull requests, and CI/CD pipelines. For identity practitioners, this is the same lifecycle problem seen in NHI governance: if ownership, scope, and runtime exposure are not understood, controls become noisy without becoming effective.
Key questions
Q: How should teams prioritise DevSecOps findings when scan volume is overwhelming?
A: Prioritise findings by whether they are reachable in production, exposed to attack, or connected to sensitive business services. Generic severity scores are useful only as a starting point. Teams get better results when they correlate scan output with runtime context, so the highest-risk issues are the ones that receive human attention first.
Q: Why do secrets and credentials need governance inside application delivery pipelines?
A: Because secrets are not static configuration. They move through source control, collaboration systems, build jobs, and runtime services, which means exposure can happen at multiple points in the lifecycle. Without ownership, rotation, and revocation discipline, a leaked secret becomes a persistent identity risk rather than a one-time defect.
Q: What breaks when application security tools generate too much noise for developers to act on?
A: When AppSec tooling produces too many false positives and disconnected alerts, developers lose trust in the findings and stop prioritising them. That creates backlog growth, slower fixes, and weaker collaboration between security and engineering. The control gap is not only detection quality, but the ability to translate findings into clear, owner-specific remediation.
Q: How do security teams know whether DevOps security tooling is working?
A: Security teams know DevOps security tooling is working when exposed secrets are blocked before merge, high-risk pipeline roles are constrained, and findings are reduced to a small set of identity-driven issues with clear owners. If alerts keep surfacing without revocation or policy enforcement, the tool is detecting risk but not controlling it.
Technical breakdown
Why runtime exposure changes DevSecOps prioritisation
Runtime exposure is the difference between a theoretical flaw and a reachable one. Static scanners can identify insecure patterns, but they do not know whether the vulnerable path is deployed, internet-facing, or behind compensating controls. Risk-based AppSec platforms try to connect source code, infrastructure, and runtime context so findings can be judged against actual exploitability. That is especially useful where containerised services, ephemeral workloads, and frequent releases make point-in-time review obsolete. In practice, the key technical shift is correlation, not more findings: map code signals to live architecture before deciding what matters.
Practical implication: Use runtime correlation to suppress findings that cannot be reached in production and focus remediation on exposed paths.
How software architecture mapping improves security decisions
Software architecture mapping creates a relationship model between code components, dependencies, and runtime services. Instead of treating each scanner output as a separate alert, the platform can show where a weakness sits in the broader application graph, what it connects to, and how it might be abused. This matters because one insecure dependency can affect many services, and one service can expose many internal trust relationships. For teams dealing with secrets, credentials, and service access, the architectural view also reveals where identity controls are implicit rather than enforced, which is often where governance breaks down.
Practical implication: Map application dependencies and service relationships before deciding which findings deserve blocking treatment.
Why secrets detection is still an operational problem
Secrets detection is not just about finding hardcoded credentials. It also has to account for git history, collaboration tools, pipelines, and duplicated secret stores that create long-lived exposure windows. Traditional workflows often discover leaks late, then route them through manual triage that delays revocation and increases blast radius. The article’s focus on secrets management reflects a broader governance issue: a secret is not secure because it is stored somewhere central. It is secure only when ownership, rotation, revocation, and deployment paths are all controlled consistently across the delivery chain.
Practical implication: Treat secrets as lifecycle-managed identity material and test whether discovery, rotation, and revocation are actually linked.
Threat narrative
Attacker objective: The attacker wants to turn development-side exposure into runtime access that can be used for theft, tampering, or downstream compromise.
- Entry begins when hardcoded secrets, exposed tokens, or vulnerable dependencies enter the delivery chain through source control, AI-assisted code generation, or third-party libraries.
- Escalation follows when those leaked credentials or reachable flaws let an attacker move from code exposure to runtime access, cloud resource abuse, or privileged service impersonation.
- Impact occurs when the exposed access is used to tamper with builds, exfiltrate data, or pivot through trusted application and supply-chain paths.
NHI Mgmt Group analysis
Coverage-first AppSec is no longer sufficient. The article correctly points to a problem many teams still avoid naming: scan volume is not the same as risk reduction. Modern engineering environments generate findings faster than people can triage them, which means the security function needs architecture-aware prioritisation rather than a bigger backlog. The practitioner conclusion is simple: if the tool cannot explain reachability and business impact, it is adding noise, not control.
Secrets management has become an identity governance problem inside delivery pipelines. When credentials, tokens, and API keys move through code, collaboration tools, and CI/CD, the question is no longer just whether a scanner can detect them. The real issue is whether the organisation can assign ownership, enforce rotation, and revoke access before exposure becomes abuse. In NHI terms, this is lifecycle governance for machine credentials, not just secret storage. The practitioner conclusion is to treat secrets as governed identities with expiry, scope, and offboarding.
Context-aware ASPM is the strongest answer to AppSec fragmentation. The named concept here is risk-context security: the ability to rank findings by deployment reality, exposure, and architectural importance rather than by generic severity. That concept matters because fragmented tools often produce incompatible signals that cannot be reconciled into a decision. A mature programme should therefore reduce overlap across scanners, not increase it. The practitioner conclusion is to consolidate around context-rich prioritisation layers where possible.
AI-assisted development makes governance debt visible faster. As code volume rises, the limiting factor becomes not detection but decision quality. AI-generated code can widen the gap between what is committed and what is understood, which increases the value of automated policy enforcement and material-change review. That also means teams need clearer ownership boundaries across human developers, AI-assisted workflows, and machine credentials. The practitioner conclusion is to align policy, review, and runtime enforcement before code throughput outruns governance.
Developer productivity is now a security control surface. The article’s 7-hour weekly drag from disconnected tooling is not just an efficiency issue. It is a control failure because it shapes whether security feedback is acted on or ignored. Security leaders should view integration quality, deduplication, and workflow fit as measurable elements of control effectiveness. The practitioner conclusion is to remove friction before asking developers to absorb more findings.
What this signals
Risk-context security will become the practical benchmark for AppSec programmes because teams cannot keep scaling disconnected scanners without increasing operational drag. When one environment produces multiple overlapping findings, the real control is the ability to decide what is reachable, relevant, and worth blocking. This is where contextual platforms begin to outperform coverage-first thinking in the hands of real practitioners.
Secrets sprawl will continue to look like a tooling problem until organisations treat it as lifecycle governance. The presence of multiple secrets manager instances, unmanaged credentials, and delayed revocation creates a control gap that extends well beyond AppSec into NHI governance. Teams should expect audit pressure to shift from whether a secret was found to whether it was owned, rotated, and offboarded on time.
For practitioners
- Prioritise by reachability, not count Block or escalate findings only when the vulnerable component is deployed, exposed, or connected to a sensitive runtime path. This reduces noise and keeps the team focused on material risk rather than abstract severity scores.
- Treat secrets as lifecycle-managed identities Assign clear ownership for every credential, token, and API key, then verify rotation, revocation, and offboarding paths across git history, pipelines, and collaboration tools. Secrets that cannot be traced to an owner should be treated as active risk.
- Correlate code findings to runtime architecture Use tooling that maps dependencies, services, and deployment context together so one finding can be evaluated in relation to its actual business impact. That makes it easier to decide which issues deserve blocking treatment and which can be monitored.
- Reduce scanner overlap and workflow friction Deduplicate findings across SAST, SCA, DAST, IaC, and secrets detection so developers do not receive conflicting alerts for the same issue. Measure whether the toolchain fits the IDE and pull request workflow before expanding the stack further.
Key takeaways
- Modern DevSecOps programmes fail when they optimise for raw findings instead of reachable risk and business impact.
- Secrets management is an identity governance problem when credentials, tokens, and API keys move across code, pipelines, and runtime.
- Tool consolidation only helps when it improves context, deduplication, and developer workflow integration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | Application and secrets governance depend on controlling who and what can access delivery resources. |
| Recommendation — Map pipeline and runtime access to PR.AC-4 and enforce least-privilege permissions for build and deployment paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central where delivery tooling, credentials, and runtime services intersect. |
| SI-2 — Flaw Remediation | The post emphasises contextual remediation over raw vulnerability counts. | |
| Recommendation — Apply AC-6 to reduce excessive access in CI/CD, secret stores, and deployment automation. Use SI-2 to prioritise remediation based on exploitability and operational context, not just severity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential lifecycle controls are directly relevant to leaked secrets and tool sprawl. |
| Recommendation — Use CIS Control 5 to inventory, review, and remove stale accounts and credentials across the delivery chain. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article's risk model includes credential theft and downstream data theft via exposed secrets. |
| Recommendation — Map exposed secrets and reachable flaws to TA0006 and TA0010 to prioritise abuse paths that matter in production. | ||
Key terms
- Risk Context: Risk context is the information used to judge how much access an external identity should receive, including the worker’s role, employer, relationship to the business, and the systems involved. It helps identity teams make access decisions based on actual exposure rather than broad assumptions.
- Secret lifecycle governance: Secret lifecycle governance is the set of controls that manage creation, distribution, rotation, expiry, and revocation for credentials. It treats secrets as living access artefacts rather than static text. That approach is essential when the same credential may travel through code, email, and automation.
- 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.
- Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.
What's in the full article
Apiiro's full article covers the operational detail this post intentionally leaves for the source:
- A category-by-category breakdown of 16 DevSecOps tools across ASPM, SAST, SCA, DAST, IaC, and container security
- Specific product-level capability comparisons, including runtime context, reachability analysis, and IDE workflow integration
- Selection guidance for matching tool depth to stack complexity, team skill level, and compliance requirements
- Examples of how different tools reduce triage noise, automate remediation, and fit into CI/CD pipelines
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity control to broader security operations and lifecycle management.
Published by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
