Application security testing is fragmenting across code, cloud and runtime

At a glance

What this is: Cycode argues that application security testing has split into multiple tool types because no single control covers source code, dependencies, runtime behaviour and mobile risk.

Why it matters: For IAM and AppSec teams, the implication is that security decisions now depend on correlating findings, ownership and exploitability across the software delivery chain rather than trusting any one scanner.

By the numbers:

• Organizations use an average of 50 AppSec tools, and 67% of security leaders say managing them is a significant hurdle.

Context

Application security testing is the set of controls used to find vulnerabilities before software reaches production. The governance problem is not whether teams can scan code, but whether they can translate many partial findings into a coherent risk picture that developers and security owners can actually act on.

This article sits in the broader AppSec and software delivery control space rather than a pure identity article, but it still intersects with IAM through ownership, access to pipelines, and the handling of secrets, tokens and privileged build credentials. That makes it relevant to practitioners trying to govern risk across the software lifecycle, not just at the point of code review.

The article’s central claim is typical of modern AppSec programmes: tool coverage has expanded faster than operating models for correlation, prioritisation and remediation.

Key questions

Q: How should security teams consolidate application security testing across code, dependencies, infrastructure, and containers?

A: Security teams should evaluate AST as a coverage problem, not a collection of separate tools. The practical goal is a single integration point that scans repository code, open source dependencies, infrastructure definitions, and container outputs with enough context to route findings to the right owner. Consolidation works best when it reduces duplicate noise, preserves build context, and supports fast developer remediation.

Q: Why do fragmented AppSec tools create more risk than just operational noise?

A: Because fragmentation delays triage, obscures ownership, and makes it harder to prove whether a control is working. Security teams spend time translating between tools instead of fixing issues, while developers receive conflicting signals. The result is slower remediation and weaker accountability, especially when code, pipeline, and ticketing systems are all separate.

Q: What breaks when application security testing does not include CI/CD and secrets?

A: The control boundary stops at the code repository while the real attack surface moves into build and deployment paths. Pipeline credentials, tokens and automation permissions can expose the same business risk as a vulnerable component if they are ungoverned or overprivileged.

Q: How do security teams know which application vulnerabilities matter most?

A: Prioritise flaws that are externally reachable, have known exploit patterns, or expose sensitive identity material such as credentials, sessions, or privileged APIs. A long vulnerability list is not useful on its own. Teams need a ranked view based on exploitability, business exposure, and whether the issue can lead to authenticated access or lateral movement.

Technical breakdown

Why SAST, SCA, DAST and runtime tools each see different risk

Static application security testing inspects source code or bytecode before execution, so it is good at finding insecure patterns, hardcoded secrets and obvious injection paths. Software composition analysis looks at third-party dependencies and containers, while dynamic testing observes running applications from the outside. IAST and RASP add runtime visibility, but each sees only part of the attack surface. That is why a single testing method rarely gives full assurance: code flaws, dependency risk and runtime abuse appear at different stages and require different evidence models.

Practical implication: map each testing method to the risk it can actually observe, and do not treat one scanner as whole-program coverage.

Why fragmented findings break prioritisation

The main operational issue is not finding vulnerabilities, but deciding which findings matter first. When SAST, SCA, DAST and runtime tools report separately, teams get duplicate alerts, conflicting severity scores and no clear signal on exploitability or ownership. That creates tool sprawl and review fatigue. Effective programmes correlate findings across controls, connect them to the affected asset and identify whether the issue is reachable in production. Without that context, teams spend time on noise while exploitable weaknesses remain open.

Practical implication: centralise correlation and triage so severity is judged by exploit path, exposure and owner, not by scanner output alone.

Why secure SDLC coverage now has to include secrets and pipelines

Modern application security testing is no longer limited to application code. Build systems, CI/CD workflows, secrets, containers and mobile runtime behaviour are now part of the attack surface because they determine how code is produced, signed, deployed and accessed. That widens the governance boundary from code quality to delivery-chain integrity. For IAM and NHI governance, the important point is that credentials used by pipelines, service accounts and automation can create the same kind of exposure as a vulnerable line of code if they are unmanaged or overprivileged.

Practical implication: extend application testing controls to the delivery chain, including secrets, pipeline permissions and runtime access paths.

Threat narrative

Attacker objective: The attacker’s objective is to exploit a missed application weakness before the organisation can identify and contain it.

1. Entry occurs when an application ships with an untested flaw or vulnerable dependency that reached production because the earlier control set missed it.
2. Credential or code-path abuse follows when the weakness enables injection, misuse of a library, or another exploitable execution path inside the application.
3. Impact is realised when attackers turn that flaw into data exposure, unauthorised access or costly remediation after release.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

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

Application security testing is now a correlation problem, not a scanner problem. The article shows that SAST, SCA, IAST, DAST, MAST and RASP each expose different slices of risk, but none create a complete control picture on their own. That means the governance failure is assuming coverage exists because tools exist. Practitioners should treat correlation, ownership and reachability as the real decision layer.

Tool sprawl is the new AppSec control gap. When organisations operate dozens of scanners, the issue shifts from missing detection to mismanaging overlap, false positives and fragmented workflow. That is not just an efficiency issue, because noisy control planes delay action on exploitable findings. Teams need an operating model that turns multiple test results into a single risk queue.

Build and pipeline credentials belong inside the application security boundary. The article’s discussion of secrets, containers and CI/CD confirms that AppSec now intersects directly with NHI governance. Pipeline accounts, API tokens and automation privileges can turn a software defect into a broader access problem if they are overexposed or poorly governed. The practical conclusion is that application testing and credential governance can no longer be managed as separate disciplines.

Runtime validation is becoming the decisive proof point. Static analysis can identify likely weaknesses, but runtime evidence shows whether a flaw is actually reachable in production conditions. That shifts the burden from theoretical vulnerability lists to tested exposure paths. Practitioners should use runtime context to decide which findings deserve immediate remediation and which remain low-risk until they are proven exploitable.

What this signals

Application security programmes are shifting from detection breadth to decision quality. The operational question is no longer how many scanners a team owns, but whether those scanners produce a prioritised remediation queue that developers trust. That makes ownership, exploitability and runtime exposure the real control outcomes.

AppSec and identity governance are converging through delivery credentials. Once build systems, automation tokens and service accounts become part of the testing boundary, NHI governance stops being a separate discipline and becomes part of application resilience. Teams that ignore that overlap will keep missing the route by which code flaws become access issues.

For practitioners

• Correlate scanner output into one risk queue Merge SAST, SCA, DAST, IAST and runtime findings into a single triage workflow that groups duplicates, preserves ownership and surfaces exploitability.
• Extend testing to pipelines and secrets Include CI/CD permissions, service accounts, tokens and other delivery-chain credentials in application security testing so build and deploy paths are not blind spots.
• Prioritise reachable production exposure Rank findings by whether an attacker can reach the vulnerable code path in the deployed environment, not just by scanner severity.
• Use runtime evidence to validate static findings Confirm whether the most serious issues are observable in live execution, then escalate the findings that combine reachability with sensitive data access or privilege.

Key takeaways

• Application security testing now needs multiple control types because code, dependency, runtime and mobile risks do not show up in the same place.
• The main programme weakness is not lack of scanning, but lack of correlation, ownership and prioritisation across tool outputs.
• Treat CI/CD permissions, secrets and runtime exposure as part of the AppSec boundary, not as separate governance problems.

Key terms

• Application Security Testing Service: A managed or platform-based delivery model for finding and prioritising software vulnerabilities across code, dependencies, secrets, containers, and infrastructure. It combines scanning with workflow integration and often adds remediation support, reporting, and governance features for enterprise development teams.
• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
• Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course covers NHI governance, machine identity security and secrets management as part of a practical identity security foundation. It is designed for practitioners who need to connect access governance to the broader security controls their programmes depend on.