Application security testing coverage still leaves attack surface gaps

At a glance

What this is: Arnica’s guide explains how SAST, DAST, SCA, and secrets scanning fit together and shows why no single application security testing category covers the full attack surface.

Why it matters: For IAM and security teams, the identity angle sits in hardcoded secrets, authentication weaknesses, and access control failures that scanners must catch before code or runtime exposure becomes a credential event.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Arnica’s guide to SAST, DAST, and SCA coverage in application security testing

Context

Application security testing is only useful when it matches where vulnerabilities actually appear. Static analysis, runtime testing, dependency review, and secrets detection each cover different failure modes, and treating them as interchangeable leaves predictable blind spots in code, runtime, and identity-related controls.

This matters because the article’s core issue is governance, not tooling volume. Security teams need coverage that maps to commit time, dependency change, and pre-production runtime, with special attention to hardcoded credentials and authentication paths that turn application bugs into identity compromise.

Key questions

Q: How should security teams implement DAST in CI/CD pipelines?

A: Start by making DAST part of the release workflow, not a separate review process. Connect scans to branches or build stages, require authenticated test coverage, and export results in machine-readable formats so downstream systems can act on them. The key is to block only confirmed, reachable issues while keeping lower-confidence findings visible for follow-up.

Q: Why do application secrets create identity risk as well as appsec risk?

A: Because secrets are machine credentials. If a token, API key, or certificate is embedded in an application, compromise of the app can become compromise of a downstream identity. That is why IAM and AppSec need shared ownership of secret scope, rotation, and revocation.

Q: What do security teams get wrong about SAST and DAST coverage?

A: They often treat the tools as substitutes rather than complementary controls. That leads to blind spots, either by missing design flaws that static analysis could catch or by missing live exploitation paths that only dynamic testing can expose. Coverage should be measured by phase and risk surface, not by vendor count.

Q: What should teams do when AppSec findings involve secrets or access tokens?

A: Treat the issue as an identity event, not only a code defect. Revoke the exposed credential, rotate the secret, identify every system that could have used it, and verify that the token was not copied into other environments. If the access path is unclear, assume broader exposure until proven otherwise.

Technical breakdown

How SAST, DAST, and SCA split responsibility across the pipeline

SAST, or static application security testing, inspects source code, bytecode, or binaries without executing them. That makes it effective for injection flaws, insecure API use, and hardcoded credentials, but it cannot observe runtime state or external configuration. DAST, or dynamic application security testing, probes a live application and is better at finding authentication bypass, session flaws, and misconfigurations visible only when the system is running. SCA adds dependency intelligence by checking third-party packages for known CVEs and license risk. The practical model is not competition between the three, but division of labour across build, deploy, and runtime.

Practical implication: map each testing type to the stage where its blind spots are smallest and stop expecting one scanner to cover all three phases.

Why secrets scanning belongs in application security testing

Secrets scanning is a separate control because credentials behave differently from ordinary code defects. A leaked API key, token, or certificate can be abused immediately, often without any exploit chain beyond access to the repository, build logs, or generated artefacts. SAST may detect some embedded secrets, but only if the pattern is obvious and the scanner is tuned correctly. Runtime testing will not help once a secret has already been exposed. In practice, secrets scanning is the control that turns identity material into a first-class AppSec object rather than an incidental code smell.

Practical implication: gate every pull request and build on secret detection so credentials never become part of the release path.

Why reachability and exploitability matter more than raw findings

Traditional AppSec programs often drown teams in unprioritised findings. Reachability asks whether vulnerable code is actually callable from an attack path, while exploitability asks whether the weakness can be used in the environment as deployed. That distinction matters because many reported issues never become real exposure, but a smaller set can combine with weak authentication, standing privileges, or exposed secrets to create high blast radius. The article correctly shifts the conversation away from sheer volume and toward operational significance, which is where remediation resources should be spent.

Practical implication: rank findings by attack path and business impact, not by severity score alone.

Threat narrative

Attacker objective: The attacker wants to turn a software flaw into usable access, then exploit that access for data theft, account compromise, or deeper environment penetration.

1. Entry occurs when attackers reach vulnerable code, exposed credentials, or a misconfigured runtime surface that basic static checks did not fully cover.
2. Escalation follows when the attacker uses authentication weakness, hardcoded secrets, or reachable dependencies to move from discovery into active abuse.
3. Impact is the theft of data, unauthorised access, or application compromise that could have been limited by earlier secrets scanning, SCA, or DAST coverage.

NHI Mgmt Group analysis

SAST and DAST are complementary control planes, not competing product categories. Static analysis finds code defects before execution, while dynamic testing exposes behaviour that only appears at runtime. The market habit of comparing them as substitutes obscures the real governance question: which attack surface is covered at which lifecycle stage. Teams that treat them as interchangeable will always leave gaps between commit, build, and deployment. The practitioner conclusion is to assign each test type to the control boundary it can actually observe.

Secrets exposure is the most underappreciated identity problem inside AppSec. Application testing often frames hardcoded credentials as a code quality issue, but the governance failure is identity-related because leaked tokens, keys, and certificates are live access objects. Once exposed, they bypass many application-layer controls entirely. That is why NHI governance, secrets lifecycle management, and AppSec cannot be separated in mature programmes. The practitioner conclusion is to treat secrets scanning as identity control, not just secure coding hygiene.

Reachability creates the named concept teams should operationalise: attack-path-aware AppSec. Findings only matter when an attacker can reach and chain them into abuse, and that requires linking code analysis to runtime context, dependency posture, and exposed credentials. This aligns with modern risk-based review under NIST SP 800-53 and with least-privilege thinking in identity governance. The practitioner conclusion is to prioritise findings that sit on a real attack path and suppress noise that has no exploitable route.

OWASP Top 10 coverage is a testing architecture problem, not a checklist problem. Broken access control, vulnerable components, and security misconfiguration map to different controls and different test types. No single scanner can close all three, which means governance must define coverage by class of weakness rather than vendor output. That approach is especially important where application flaws intersect with IAM, because access control failures are rarely visible to one control family alone. The practitioner conclusion is to design coverage by risk class and lifecycle stage.

Agentic-era code generation increases the speed of exposure, not just the speed of delivery. As AI-generated code enters pipelines alongside human-written code, the volume of code to review grows faster than manual processes can absorb. That does not create a new category of vulnerability, but it does raise the odds that hardcoded secrets, injection flaws, and insecure auth logic move into production before anyone notices. The practitioner conclusion is to ensure machine-generated code is scanned through the same governance pipeline as human-authored code.

What this signals

Attack-path-aware AppSec: the practical shift for security programmes is moving from scanner volume to exploitability, with secrets and auth weaknesses treated as identity events when they surface in code or CI pipelines. That means remediation should be owned, time-bound, and tied to the control that failed, not just counted in a backlog.

Teams that already run identity lifecycle controls will adapt faster because application testing now intersects with service accounts, API keys, and certificates. The useful external baseline here is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control and authentication families, plus the identity guidance in Ultimate Guide to NHIs.

The next maturity step is to connect security testing to whether a vulnerability is reachable in the deployed environment and whether the exposed identity material can be revoked immediately. That is where AppSec becomes governance, not just detection.

For practitioners

• Implement pull-request secrets detection Block merges when API keys, tokens, or certificates appear in source, configs, or generated artefacts, and route each hit to the owning team for immediate revocation and rotation. Use the same control across human and AI-generated code paths so credentials do not bypass review during automated commits.
• Map testing controls to the SDLC stage Run SAST at commit time, SCA on every dependency update, and DAST against staging or pre-production before release. This stage-based mapping reduces blind spots and stops teams from expecting runtime testing to compensate for insecure code already merged into the build.
• Prioritise findings by reachability and exploitability Triage issues by whether the vulnerable code path is reachable, whether the flaw can be chained with exposed credentials or weak authentication, and how far the blast radius extends if it is abused. Use that ranking to decide what gets fixed first.
• Tie AppSec results to identity lifecycle controls When a finding involves secrets, service accounts, or certificates, require an identity owner, a revocation path, and a rotation deadline in the remediation ticket. This prevents application defects from lingering as active access objects after code changes are shipped.

Key takeaways

• SAST, DAST, SCA, and secrets scanning solve different parts of the application risk problem, so treating any one of them as sufficient guarantees blind spots.
• The strongest AppSec signal is reachability plus exploitability, because those are the conditions that turn code defects and exposed secrets into real compromise.
• Identity governance now sits inside AppSec because leaked tokens, service keys, and certificates are operational access objects, not just development mistakes.

Key terms

• 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.
• Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
• 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.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.

What's in the full article

Arnica's full blog post covers the operational detail this post intentionally leaves for the source:

• The full testing matrix that maps SAST, DAST, SCA, and secrets scanning to pipeline stages and deployment gates.
• The article’s tool-selection guidance for AppSec teams choosing between developer-first and platform-wide coverage models.
• Examples of how Arnica ranks findings by reachability and exploitability rather than raw alert counts.
• The detailed comparison of testing categories against OWASP Top 10 coverage gaps.

👉 Arnica’s full post covers the AppSec testing matrix, coverage gaps, and prioritisation approach in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps security and identity practitioners connect application risks to access lifecycle controls.