GitHub Advanced Security and DAST close appsec gaps in CI/CD

At a glance

What this is: This is a StackHawk analysis of how GitHub Advanced Security and DAST fit together to detect code, secret and runtime vulnerabilities earlier in the software lifecycle.

Why it matters: It matters because AppSec teams need controls that cover both source-level defects and runtime exposure, including the secrets and access paths that often bridge development and production.

By the numbers:

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

👉 Read StackHawk's analysis of GitHub Advanced Security and DAST for AppSec

Context

GitHub Advanced Security sits in the gap between code review and runtime assurance. In practice, teams still struggle to stop vulnerabilities, leaked secrets and dependency risk from moving from pull request to production, which is why the primary issue is control coverage rather than tool count.

Application security programmes also need to account for non-human identity exposure. Secret scanning, dependency review and CI/CD-integrated testing all touch the same governance problem: how to control credentials, automation and deployment paths before they become persistent attack surface.

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 leaked secrets create an identity governance problem, not just a code problem?

A: Because a leaked secret is a live credential with an owner, scope and lifecycle. If it remains valid after exposure, it can be abused like any other non-human identity. Governance has to cover discovery, revocation, rotation and auditability, otherwise the organisation only knows that the secret existed, not that it was removed.

Q: What breaks when teams rely on static analysis alone for AppSec?

A: Static analysis can identify vulnerable code patterns, but it cannot prove how the application behaves with real authentication, session state or deployed infrastructure. That leaves gaps around exploitability, false positives and misconfigured runtime controls. Teams that stop at code scanning may ship software that looks clean in review but remains attackable in production.

Q: Who is accountable when a compromised action leaks repository secrets?

A: Accountability usually spans platform engineering, application owners, and identity governance, because the failure crosses code integrity, workflow design, and credential lifecycle. The right question is not who owns the incident alone, but which team owns action trust, which team owns the secret, and which team owns the downstream access it enabled.

Technical breakdown

How code scanning maps defects before they ship

Code scanning uses static analysis to inspect source code for known vulnerability patterns and data-flow issues. Tools such as CodeQL trace how untrusted input moves through an application and flag paths that could enable SQL injection, XSS or unsafe deserialisation. The value is not just finding bugs, but prioritising them before they are compiled into a release. Static analysis is strongest when rulesets are tuned to the languages and frameworks a team actually uses, otherwise alerts become noise and are ignored.

Practical implication: tune queries to your stack and enforce review on high-severity findings before merge.

Why secret scanning is really NHI governance

Secret scanning is often presented as a code hygiene feature, but its security significance is broader. API keys, access tokens and certificates are non-human identities in practice because they grant machine access to data, services and pipelines. When those credentials are committed to code or configuration, the issue is not only exposure but lifecycle failure, because the secret may remain valid long after discovery. That creates standing access that bypasses least privilege and makes revocation speed a primary control.

Practical implication: treat every detected secret as an identity lifecycle event, not just a code defect.

DAST fills the runtime gap that static tools cannot see

Dynamic Application Security Testing evaluates the running application rather than the codebase in isolation. That matters because many failures only emerge when authentication, authorisation, session handling and server configuration interact under live conditions. DAST can confirm whether a vulnerability is truly exploitable, which helps teams separate theoretical weaknesses from real attack paths. Used alongside static analysis, it gives AppSec a better signal on whether a control failure is isolated in source or present in the deployed service.

Practical implication: use runtime testing on authentication and authorisation paths that static scanning cannot validate.

Threat narrative

Attacker objective: The attacker wants to turn exposed development credentials into trusted access that enables code theft, pipeline abuse or production compromise.

1. Entry occurs when a leaked API key, token or exposed configuration file gives an attacker a valid foothold into source repositories, CI/CD systems or downstream services.
2. Escalation follows when the exposed credential is still active, allowing the attacker to move from read access to repository manipulation, pipeline abuse or broader application access.
3. Impact occurs when the attacker uses the trusted access path to exfiltrate code, alter deployments or pivot into connected systems and data stores.

NHI Mgmt Group analysis

Shift-left only works when runtime validation is part of the control model. Static analysis can reduce defect volume, but it cannot prove exploitability in live authentication and authorisation flows. Teams that rely on code scanning alone are optimising for code quality, not attack resistance. The practical conclusion is that AppSec governance has to combine pre-commit analysis with runtime verification.

Secret scanning is a machine identity control, not a developer convenience feature. Once an API key or token lands in a repository, the organisation is dealing with a live identity lifecycle problem, not just a code issue. That means detection, revocation, rotation and ownership must be linked. In NHI terms, the control gap is often persistence, not discovery, and OWASP-NHI style governance should treat leaked credentials as active identities until proven otherwise.

Runtime exposure gap: the real problem in modern application security is the distance between what static tools can prove and what attackers can actually execute. DAST closes part of that gap by testing live behaviour, but it still depends on strong access control, clean secret hygiene and trustworthy CI/CD orchestration. The governance lesson is that security teams need evidence of exploitability, not just evidence of scanning.

The security budget story is increasingly about concentration, not coverage. As more AppSec spend goes into code and secrets tooling, the risk is fragmentation across scanners, repositories and pipelines rather than a single missing capability. Control owners should measure whether their tools reduce time to revocation, time to triage and time to safe release. If those numbers do not move, the programme is buying activity rather than assurance.

What this signals

Runtime assurance will become the differentiator for mature AppSec programmes. As code scanning becomes table stakes, teams will be judged on whether they can prove exploitability in deployed applications and not just enumerate findings. The practical shift is toward measuring control effectiveness across the pipeline, with NIST SP 800-53 Rev 5 Security and Privacy Controls providing a useful control baseline.

Secret detection is converging with NHI governance. Every exposed token, API key or certificate represents a non-human identity that needs ownership, revocation and audit trails. That is why identity teams and AppSec teams need shared processes rather than separate queues, especially where build systems and deployment automation hold persistent access.

Control sprawl is the hidden risk in shift-left programmes. If scanning, secret detection and DAST are not tied to common ownership and response metrics, organisations may increase alert volume without reducing exposure. The right question is whether the control stack shortens the time from discovery to safe removal, not how many findings it produces.

For practitioners

• Gate merges on high-risk code findings Require review or rejection for high-severity CodeQL findings in pull requests before merge, and track exception approval separately from standard developer workflow.
• Treat leaked secrets as identity incidents When secret scanning detects an API key, token or certificate, assign an owner, revoke or rotate the credential, and confirm where the secret was used across pipelines and services.
• Run DAST against live auth paths Prioritise runtime tests for login, session handling, authorisation and API endpoints that static analysis cannot fully validate, especially in release candidates.
• Map CI/CD credentials to the services they can reach Inventory the non-human identities used by GitHub Actions, deployment jobs and build systems, then document which repositories, clouds and data stores each one can access.
• Measure remediation speed, not alert volume Track median time to fix code findings, leaked secrets and failing runtime tests so the programme is judged on reduction in exposure, not on the number of alerts generated.

Key takeaways

• GitHub Advanced Security and DAST address two different halves of the same AppSec problem: code-level defects and runtime exploitability.
• Leaked secrets are identity events because they expose active machine credentials that can persist long after discovery.
• The control objective is faster containment and safer release, not simply more scanning output.

Key terms

• Code Scanning: Code scanning is automated static analysis that inspects source code for security flaws before software is deployed. It looks for known vulnerability patterns, risky data flows and insecure coding constructs so teams can fix issues early in the development lifecycle.
• 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.
• Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

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

• How StackHawk positions DAST alongside GitHub Advanced Security in a CI/CD workflow
• Specific examples of integrating scans into GitHub Actions and pull request gates
• StackHawk's walkthrough of runtime testing for APIs, authentication and authorisation
• Implementation guidance for teams that want to extend static analysis into live application testing

👉 StackHawk's full post covers code scanning, secret scanning, DAST and integration examples for modern pipelines.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect application security controls to identity lifecycle decisions across development and operations.