What do teams get wrong when they rely only on application security for DevOps risk?

Why This Matters for Security Teams

Relying on application security alone narrows DevOps risk to the deployed app and misses the earlier control points where most pipeline failures begin. Planning decisions shape trust boundaries, package ingestion determines what code enters the build, build integrity determines what actually gets promoted, and release distribution determines what reaches production. That means teams can pass scans and still ship malicious dependencies, poisoned artifacts, or reused credentials that never sat inside the web application itself. Application security tools are still necessary, but they are only one layer in a broader software delivery threat model. A control set that focuses only on runtime or source-level findings tends to overestimate coverage while leaving dependency intake, CI/CD trust, artifact provenance, and promotion controls under-governed. OWASP ASVS helps on the application side, but it does not replace controls for the delivery chain itself. In practice, many security teams discover pipeline exposure only after an artefact has already been signed, stored, or deployed rather than through the application findings they expected to catch it. The State of Secrets in AppSec shows how often secret handling remains fragmented even in programmes that believe they have strong control, with an average of 6 distinct secrets manager instances contributing to control drift. The State of Secrets in AppSec provides useful context for that gap.

How It Works in Practice

DevOps risk is distributed across the delivery chain, so the practical mistake is treating one control family as if it covered the entire chain. Application security is strongest at finding issues in code and exposed interfaces, but pipeline risk also includes who can introduce code, what dependencies are accepted, how builds are reproduced, where secrets are used, and how releases are promoted. A useful way to think about the failure modes is by stage:

• Planning and design: control gaps start when threat modelling, trust boundaries, and dependency assumptions are never made explicit.
• Package ingestion: risk appears when third-party packages are trusted without provenance checks, pinning, or review of transitive dependencies.
• Build integrity: the pipeline can be altered if build runners, build scripts, or signing steps are not protected from tampering.
• Release distribution: exposed artefacts, weak promotion gates, or unverified images can move unsafe code into production.

OWASP ASVS is useful where the issue is application behaviour, but teams also need controls for container images, registries, and build-time trust. NIST SP 800-190 Container Security is a stronger fit when the risk is image integrity, registry trust, or runtime packaging rather than a web vulnerability in the application itself. Secrets are a recurring blind spot because they bridge the app and the pipeline. The 2024 State of Secrets Management Survey reports that only 44% of organisations are currently using a dedicated secrets management system, which helps explain why cross-environment credential reuse remains common. The 2024 State of Secrets Management Survey is directly relevant to that operational weakness. These controls tend to break down when teams assume build and deploy systems are “internal” and therefore exempt from the same integrity and access discipline they apply to production applications.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery friction, so organisations have to balance release speed against provenance, review, and recovery costs. That trade-off becomes more visible in fast-moving environments where teams use ephemeral infrastructure, many microservices, or frequent dependency updates. A few edge cases matter in practice:

• Monorepos and shared pipelines: one weak trust decision can affect many services at once, so app-level scanning alone creates a false sense of compartmentalisation.
• Internal package mirrors: mirroring improves availability, but it does not automatically solve tampered packages or compromised upstream maintainers.
• Signed artefacts: signatures help only if key custody, signing authority, and verification are all enforced consistently.
• Cross-environment reuse: credentials that work in dev, test, and prod make compromise much easier to turn into lateral movement.

There is no universal standard for how much of this should sit in AppSec versus platform engineering, but the boundary should be defined by the control point rather than by team structure. If the failure can happen before code reaches the application runtime, then app scanning is at best partial coverage. The better question is whether the organisation can prove integrity at each promotion step, not whether it can find defects once software is already assembled. Guide to the Secret Sprawl Challenge is a useful next read when secret handling is the practical bottleneck.

Risk and Threat Considerations

The material risk is coverage drift, where teams believe application findings represent delivery-chain assurance even though the attacker path begins earlier. That creates exposure to dependency compromise, build tampering, artefact substitution, and secret abuse across environments. Failure mechanism: adversaries target whatever stage has the weakest verification, whether that is a malicious package, a poisoned build step, a leaked pipeline secret, or an unverified release artefact. Once they control one trust point, they can persist through subsequent promotions and bypass app-centric review entirely. Impact: compromised code can reach production with valid signatures, hidden payloads, or reused credentials intact, making detection harder and response slower. The result is not just a vulnerable application, but an untrusted delivery system.

Practitioner Guidance

What to prioritise: Treat pipeline trust as a separate control domain from application findings. The first priority is to identify where code, dependencies, secrets, build outputs, and release artefacts enter the chain, then verify which of those steps has real enforcement rather than advisory checks.

Decision rule: If a control only inspects deployed code, it should be treated as incomplete for DevOps risk unless there is also a way to verify dependency integrity, build provenance, and release promotion. If you cannot evidence those three points, assume the pipeline still has blind spots.

What to verify: Teams should be able to show who can modify build inputs, how secrets are scoped across environments, and whether artefacts are reproducible or at least traceable to a trusted build. If those answers rely on tribal knowledge, the control model is weaker than it appears.

Practitioner takeaway: AppSec is necessary, but DevOps risk is governed by the weakest trust step in the delivery chain, not by the best scanner in the tooling stack.

Related resources from NHI Mgmt Group

• What do security teams get wrong when they treat CSPM as enough for application risk?
• What do security teams get wrong when they rely on authentication logs to understand identity risk?
• What do security teams get wrong when they rely on static rules for cloud application attacks?
• What do teams get wrong when they rely on application code for permission checks?