AppSec complexity is widening the gaps that attackers exploit

At a glance

What this is: OXSecurity argues that AppSec complexity is creating coverage gaps across cloud, microservices and CI/CD, allowing vulnerabilities and breaches to go unnoticed.

Why it matters: For IAM, NHI and application security teams, the warning is that fragmented controls can produce a false sense of coverage while leaving identity, pipeline and runtime gaps open.

Context

Application security becomes harder to govern when the environment keeps fragmenting. Cloud services, microservices, APIs and CI/CD each create their own control plane, so coverage can look broad while important paths remain unmonitored. In identity-heavy delivery pipelines, that fragmentation also creates NHI risk because secrets, tokens and service accounts often move faster than review and approval processes.

The core problem is not simply tool sprawl. It is that each layer can be secured in isolation while the overall system still lacks continuous visibility and accountability across build, deploy and runtime stages. The result is a governance gap, not just a tooling gap, and that makes the article relevant to AppSec, IAM and NHI teams alike.

Key questions

Q: What breaks when application security testing is fragmented across multiple tools?

A: Fragmentation creates overlapping findings, inconsistent policy enforcement, and slow triage because no single system can correlate code, dependency, secrets, and runtime context. The result is not just more noise, but weaker accountability for remediation. Mature teams reduce that problem by centralising ownership, normalising results, and tying each issue to the workflow where it can actually be fixed.

Q: Why do standing credentials and weak access controls increase risk in CI/CD environments?

A: Standing credentials create a persistent target for attackers, especially when developer accounts, service tokens, or repository credentials can be reused across tools. Weak access controls widen the blast radius if one account is compromised, allowing malicious changes to build steps, source code, or infrastructure code. In CI/CD, speed and trust make privilege minimisation essential.

Q: What are the signs that an AppSec programme is failing despite high scan coverage?

A: A growing backlog, long mean time to remediation, frequent reassignment, and repeated dismissals all indicate the programme is detecting issues faster than teams can close them. If findings are abundant but fixes are slow, the control is reporting risk rather than reducing it.

Q: How should security teams reduce AppSec tool sprawl without losing coverage?

A: Start by mapping every tool to a specific control purpose and threat path, then remove overlap where two products answer the same question. Keep the controls that improve visibility, correlation, and response speed, and retire the ones that only add dashboards or duplicate alerts. Coverage matters, but coverage without ownership and triage discipline creates more noise than value.

Technical breakdown

Why AppSec complexity creates coverage gaps

Modern AppSec stacks often combine scanners, runtime tooling, cloud controls and pipeline checks that do not share a single source of truth. That means a vulnerability can be visible in one layer yet still untracked in another, especially when microservices and CI/CD pipelines introduce frequent change. Complexity becomes a control failure when ownership, telemetry and enforcement are split across teams and products. The issue is not lack of security activity, but lack of coherent coverage across the application lifecycle.

Practical implication: teams need to map coverage by lifecycle stage, not by individual tool, and close the handoff points where visibility is lost.

How CI/CD and machine identities widen the attack surface

CI/CD environments are especially sensitive because they depend on non-human identities such as build runners, service accounts, tokens and deployment credentials. If those identities are overprivileged, long-lived or spread across multiple systems, an attacker who reaches the pipeline can pivot into source code, artifacts or production access. This is where AppSec and NHI governance intersect directly. Pipeline security is no longer just about code integrity; it is also about who or what can authenticate to each stage and how tightly that access is scoped.

Practical implication: treat CI/CD credentials as governed NHIs and review their scope, lifetime and offboarding as part of AppSec coverage.

Why full-stack visibility matters more than tool count

Full-stack visibility means being able to trace exposure from code through infrastructure, APIs and runtime behavior without losing continuity between controls. In practice, that requires correlated telemetry, consistent policy and a way to see whether a weakness in one layer can be exploited through another. When that visibility is missing, teams can believe they are secure because multiple tools are deployed, even though none of them provides complete coverage. The control objective is coherence, not accumulation.

Practical implication: consolidate evidence and alerting around application flows so gaps are found as system-level failures, not isolated findings.

Threat narrative

Attacker objective: The attacker aims to exploit fragmented application coverage to reach internal assets, sensitive data or high-value accounts without being detected.

1. Entry occurs through a missed gap in the application stack, such as a CI/CD weakness, overlooked vulnerability or exposed internal path.
2. The attacker uses that gap to reach internal tooling, credentials or deployment access that should have been constrained by stronger coverage.
3. With expanded access, the attacker can move through connected systems, compromise accounts or reach sensitive data and services.
4. The impact is breach exposure that remained undetected because fragmented controls never provided a full view of the attack path.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.

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

Coverage, not tool count, is the decisive AppSec variable: the article points to a recurring governance failure where organisations equate more tooling with better control. In practice, the environment can become harder to defend when scanners, pipeline checks and runtime tools do not operate as one coverage model. Practitioners should measure whether every application path is actually governed, not whether every product category is present.

CI/CD has become an identity security problem as much as an application security problem: build runners, service accounts and pipeline tokens are now part of the attack surface, not just plumbing. That creates a direct bridge between AppSec and NHI governance, especially where credentials are persistent or insufficiently scoped. The governance question is whether machine identities are controlled with the same discipline as human access, because compromised pipelines can become a fast route to deployment and data exposure.

Full-stack visibility is the only defensible response to modern application sprawl: cloud, microservices and APIs make isolated point controls too easy to outgrow. A named concept here is coverage fragmentation, meaning the security stack appears broad but cannot trace risk consistently across build, deploy and runtime. That is the condition attackers exploit, so security leaders should treat coherence across layers as a control objective in its own right.

AppSec simplification succeeds only when it reduces governance ambiguity: simplification should mean fewer blind spots, not fewer controls. If teams cannot explain where evidence comes from, who owns each layer, and how a finding is correlated across systems, the programme is still complex in the ways that matter. The practical test is whether the organisation can follow one vulnerable path from code to runtime without gaps in accountability.

The broader lesson is that application risk is increasingly lifecycle risk: issues introduced in code, pipelines or integrations can only be managed if the governance model follows the asset through every stage. That means identity, change and runtime controls must be aligned, not treated as separate disciplines. Practitioners should judge their AppSec maturity by lifecycle continuity, because that is where attackers find the cracks.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Coverage fragmentation: this is the practical failure mode the article exposes, where security activity exists but the organisation cannot trace a vulnerability cleanly from code to runtime. For practitioners, the next step is to measure continuity across control handoffs rather than counting tools. If a finding cannot be followed across the delivery chain, the programme still has a material gap.

In application delivery, the most useful simplification is governed simplification. That means fewer invisible ownership seams, tighter correlation between pipeline and runtime signals, and better control of non-human identities that move through CI/CD. The teams that gain the most are the ones that turn AppSec from a set of disconnected checks into a single evidence chain.

For practitioners

• Map coverage across the application lifecycle Build a single view of code, build, deploy, API and runtime controls so ownership and detection do not stop at team boundaries.
• Treat CI/CD credentials as governed NHIs Inventory build runners, service accounts, tokens and deployment secrets, then scope access, review privilege and revoke dormant credentials.
• Correlate telemetry across tools Join findings from scanners, CI/CD, cloud and runtime monitoring so a weakness in one layer can be traced into the others.
• Reduce hidden access paths Remove unnecessary third-party integrations, unused pipeline permissions and stale account relationships that expand the blast radius of a single compromise.
• Test for blind spots in full-stack coverage Use attack-path exercises to verify whether an exposed secret, missed update or internal tool path would be detected before impact.

Key takeaways

• AppSec programmes fail when visibility breaks between code, pipeline and runtime, even if multiple tools are deployed.
• The article’s concern is not only vulnerability volume but governance continuity, especially where CI/CD and machine identities expand the attack surface.
• Practitioners should simplify for traceability, correlate signals across layers and treat pipeline credentials as governed access paths.

Key terms

• Workflow fragmentation: Workflow fragmentation is the condition where related security tasks are spread across separate tools, teams, or undocumented habits. It increases delay, inconsistency, and governance gaps because no single process owns the movement from signal to action.
• Continuous Application Coverage: Continuous application coverage is an assurance model that checks application risk throughout the change lifecycle instead of only during scheduled assessments. It aims to keep security evidence aligned with what is actually running, which is especially important when identity paths, secrets, and integrations change frequently.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Full-Stack Visibility: Full-stack visibility means seeing and reasoning across the security controls and data sources that collectively describe an environment. In practice, it includes identity, endpoint, cloud, network, email, and ticketing context. Without it, alert investigation is partial, and important relationships between events can remain hidden.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management for practitioners who need to govern non-human access in modern delivery pipelines. It is suitable for security leaders and architects aligning identity controls with broader security programmes.