What breaks when security teams only focus on vulnerabilities in application security programs?

Why This Matters for Security Teams

application security programs that only chase vulnerabilities tend to optimise for the easiest thing to measure, not the full attack surface. That misses the places where modern compromise actually enters: developer identities, secrets, build pipelines, dependency chains, and infrastructure definitions. NIST’s NIST Cybersecurity Framework 2.0 treats governance and protection as broader than code scanning alone, which is the right lens for this problem.

For NHI-heavy environments, the same blind spot is especially dangerous because credentials are often embedded in automation and toolchains rather than managed like traditional user accounts. NHIMG’s The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs, which reflects how often access paths are hidden outside the application itself. In practice, many security teams encounter malicious pipeline changes only after secrets have already been exfiltrated or a build has already been trusted.

How It Works in Practice

A vulnerability-only program usually centers on SAST, DAST, and dependency findings. Those controls are necessary, but they are not sufficient because they inspect artifacts rather than trust relationships. A secure delivery program has to cover who can change code, what secrets are present, how builds are signed, how dependencies are resolved, and whether infrastructure definitions match intended policy. That is why the emerging guidance in OWASP Agentic Applications Top 10 and NIST’s broader governance model both point toward pipeline-aware risk management, not scanner-only coverage.

Practically, teams should split the problem into control planes:

• Developer identity and access, including phishing-resistant MFA and least privilege on source control and CI/CD systems.
• Secret detection and prevention, with short-lived credentials, automated revocation, and scanning in code, logs, and build artifacts.
• Build integrity, including signed commits, protected branches, provenance, and restricted runners.
• Dependency and supply chain controls, including allowlists, pinned versions, and verification of package sources.
• Infrastructure as Code review, policy-as-code, and drift detection for cloud and platform changes.

This matters because an attacker does not need a code vulnerability if they can change the codebase, insert a secret, poison a dependency, or alter the build environment. NHIMG’s The State of Secrets in AppSec shows a large developer behaviour gap in secrets handling, which means prevention cannot rely on training alone; it needs automated controls in the delivery path. These controls tend to break down in highly distributed CI/CD environments because too many temporary identities, third-party integrations, and unmanaged runners bypass central policy enforcement.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery friction, requiring organisations to balance release speed against trust in the software supply chain. That tradeoff becomes most visible when teams run multiple repositories, ephemeral cloud runners, or external build services, because the attack surface moves faster than manual review can keep up.

There is no universal standard for how much of the SDLC must be gated at each stage, but current guidance suggests risk-based controls should be applied where compromise would have the highest blast radius. For example, a public-facing application with regulated data may need enforced signing, secret zeroisation, and locked dependency resolution, while an internal tool may tolerate lighter review if it has no privileged access. The key is not to assume that vulnerability counts equal security maturity.

The edge case that often gets missed is trusted automation. A pipeline can be “secure” from a code-scanning perspective and still be vulnerable if service accounts are over-privileged, IaC templates are reusable across environments without review, or secrets are exposed in workflow logs. Security programs that stop at application flaws usually miss the path where compromise enters through identity and orchestration instead of the source code itself.

Related resources from NHI Mgmt Group

• What breaks when application security programs only scan for vulnerabilities and ignore sensitive data in repositories and logs?
• What breaks when security teams focus only on attachment scanning and ignore staged delivery chains?
• How should security teams prioritise application vulnerabilities that appear across code and dependencies?
• What breaks when application security teams rely on tool sprawl instead of control design?