Notifications
Clear all
Topic starter
14/09/2026 10:10 am
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.
NHIMG editorial — based on content published by Apiiro: a guide to DevSecOps tools and risk-based application security
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.
Questions worth separating out
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.
Q: Why do secrets and credentials need governance inside application delivery pipelines?
A: Because secrets are not static configuration.
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.
Practitioner guidance
- Prioritise by reachability, not count Block or escalate findings only when the vulnerable component is deployed, exposed, or connected to a sensitive runtime path.
- 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.
- 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.
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
👉 Read Apiiro's analysis of DevSecOps tool selection and risk-based application security →
DevSecOps tool sprawl: what teams need to prioritise now?
Explore further
14/09/2026 10:11 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Context-driven DevSecOps tools are replacing coverage-first security
