Building secure CI pipelines with GitHub Actions and secrets detection

At a glance

What this is: This is a short StackHawk post on using GitHub Actions to add SAST, DAST, and secrets detection to CI pipelines.

Why it matters: It matters because CI security controls often intersect with identity through exposed credentials, service accounts, and tokens that can turn build-time leakage into broader access risk.

👉 Read StackHawk's guidance on securing CI pipelines with GitHub Actions

Context

CI pipelines are a high-value control point because they see code, secrets, and deployment logic before changes reach production. When security checks are bolted on late, the organisation often discovers leaked credentials after they have already been copied into logs, artifacts, or downstream services. In identity terms, that is where non-human identities and secrets become a governance problem rather than a tooling problem.

GitHub Actions is one way teams can insert security checks into automated delivery, but the important question is how consistently those checks are enforced across repositories and environments. For identity and access practitioners, the main issue is whether secrets detection and application testing are integrated into the same control plane that governs service accounts, API keys, and other credentials. That starting point is common, not exceptional, in modern CI programmes.

Key questions

Q: How do I implement secrets scanning in a CI/CD pipeline?

A: Implement secrets scanning at three points: pre-commit hooks on developer workstations to catch secrets before they enter version control, CI/CD pipeline gates that scan every commit and pull request and block merges containing detected secrets, and repository scanning across all existing repositories to find historical secrets in commit history. Configure scanning to alert and block, not just report. Establish a secrets remediation process for historical findings, treating any discovered credential as compromised.

Q: Why do leaked credentials in GitHub Actions create identity risk?

A: Because the leaked item is usually a non-human identity credential such as a service account token or API key. Once exposed, it can be reused outside the original pipeline and may grant access to repositories, cloud services, or deployment systems that trust it.

Q: What breaks when CI workflows use broad permissions?

A: A single compromised job can reach repositories, build artifacts, or cloud resources that were never needed for that step. Broad permissions collapse blast-radius controls, making one leaked secret or malicious workflow change far more damaging than the original coding issue.

Q: Which controls should govern secrets in automated delivery?

A: Use least privilege, short-lived credentials, mandatory rotation, and traceable ownership for every secret that CI consumes. Those controls should sit alongside code scanning so the organisation can remove stale access rather than only detect exposure after the fact.

Technical breakdown

How GitHub Actions fits into CI security controls

GitHub Actions runs workflows as part of the build and delivery process, which makes it a practical enforcement point for security checks. In this context, SAST examines code for known patterns before deployment, DAST tests the running application from the outside, and secrets detection searches for credentials or tokens that should never be committed. The architectural value is that these checks sit close to the change, where they can stop risky content before it propagates into artifacts, logs, or release steps. The limitation is that workflow design matters as much as the tools themselves.

Practical implication: treat the workflow as a control boundary and define which checks are mandatory before merge or release.

Why secrets detection is the identity-critical control in pipelines

Secrets detection matters because a leaked credential is an identity event, not just a code-quality issue. API keys, service account tokens, and certificates often carry privileges that extend well beyond the pipeline that exposed them. Once committed or echoed in automation, they can be reused by attackers, copied into caches, or remain valid after the original code path changes. That is why secrets management and CI security belong together. The governance task is to reduce the exposure window and ensure credential lifecycle controls are aligned with how fast code moves.

Practical implication: pair pipeline scanning with rotation and revocation processes for any secret detected in source or build output.

How DAST and SAST complement each other in automated delivery

SAST and DAST answer different questions. SAST looks for insecure patterns in the code itself, including dangerous constructs that may introduce authentication or input-handling flaws. DAST exercises the application in a running state, which is useful for catching exposed endpoints, misconfigurations, or exploit paths that static analysis cannot see. In CI, the value comes from sequencing these tests so that a build is blocked only when both code-level and runtime-level risk checks fail, rather than relying on one signal to carry the whole burden.

Practical implication: use both control types together so release decisions are based on code evidence and runtime behaviour.

Threat narrative

Attacker objective: The attacker aims to turn a CI exposure into trusted access that can be reused across source control, build, and deployment systems.

1. Entry occurs when a developer, dependency, or workflow path introduces a secret, insecure code pattern, or exposed endpoint into the CI process.
2. Escalation happens when the leaked credential or flaw is validated by an attacker and reused to access repositories, build systems, or connected services.
3. Impact follows when the stolen access is used to modify code, reach protected systems, or exfiltrate data through trusted automation channels.

NHI Mgmt Group analysis

Pipeline security is now identity governance by another name. When GitHub Actions, secrets detection, and application testing are combined, the real control question is who or what is allowed to move from code into execution. That is an IAM and NHI problem because the most dangerous failures involve service accounts, tokens, and automation credentials with implicit trust. Teams that treat CI as only a DevSecOps concern miss the governance layer entirely.

Secret sprawl remains the underlying failure mode in automated delivery. The issue is not simply that secrets exist, but that they are duplicated, copied, and reused across workflows faster than teams can account for them. That creates a verification trust gap where scanners may find exposure after access has already been abused. Practitioners should read this as a signal that lifecycle controls matter more than ad hoc detection.

Continuous testing does not eliminate privilege risk unless credential scope is also reduced. A pipeline that checks code quality but still runs with broad repository or cloud permissions can turn a minor leak into a material incident. The governance lesson is that least privilege, short-lived credentials, and offboarding discipline must govern the build layer as tightly as production. In practical terms, the control surface is the credential, not just the code.

OWASP Non-Human Identity guidance is increasingly relevant to CI tooling. Build systems, runners, and automation tokens behave like non-human identities because they authenticate, act, and sometimes persist privileges independently of any human session. Once that is recognised, secret detection becomes only one part of a wider control model that includes rotation, scope limitation, and traceable ownership. Practitioners should align pipeline controls with NHI governance, not leave them in separate programmes.

What this signals

GitHub Actions reinforces a broader programme lesson: security checks only reduce risk when they are coupled to identity lifecycle controls. A secret that is found but not revoked is still an active access path, which is why pipeline governance and NHI governance need to converge around the same operational owners.

Verification trust gap: in automated delivery, teams often trust the workflow more than the credential it uses. That gap widens when build jobs inherit broad permissions, so the practical response is to narrow scope, shorten credential lifetime, and make exposure events trigger rotation automatically.

For teams that already operate under least-privilege and Zero Trust assumptions, CI is where those assumptions are tested first. The relevant question is not whether the pipeline can scan for secrets, but whether it can prevent exposed identity material from remaining valid long enough to be abused.

For practitioners

• Enforce secret scanning before merge Block pull requests when secrets detection finds API keys, tokens, or certificates in source, configuration, or workflow files. Make the scan mandatory in the same GitHub Actions workflow that runs build validation so risky material cannot bypass review.
• Tie leaked secret alerts to rotation playbooks When a secret is detected, revoke or rotate the credential immediately and verify that dependent services have been updated. Use a documented ownership map so the team that receives the alert knows which service account or token must be replaced.
• Reduce workflow permissions to the minimum required Scope GitHub Actions permissions so each job only receives the repository, deployment, or cloud access it needs for that step. Avoid broad runner credentials, because a single exposed token can otherwise reach multiple systems.
• Separate code testing from privileged deployment paths Keep SAST and DAST in earlier pipeline stages and reserve deployment credentials for a later, tightly controlled job. That separation limits the blast radius if a build step is compromised or a secret is echoed into logs.

Key takeaways

• CI security becomes an identity control problem as soon as workflows handle credentials, tokens, or certificates.
• Secret detection is only useful when it is tied to revocation, rotation, and reduced workflow privilege.
• Build pipelines that combine SAST, DAST, and secrets scanning should still be designed around blast-radius control, not trust in automation.

Key terms

• Secrets detection: Secrets detection is the identification of credentials such as API keys, tokens, certificates, and passwords in code, configuration files, or pipelines. In mature programmes, detection is paired with rotation, revocation, and ownership so exposed secrets do not remain usable.
• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• GitHub Actions runner: A GitHub Actions runner is the machine that executes a workflow job. In practice it is an identity-bearing execution environment because it can hold secrets, access tokens, and network reach. If the runner is persistent or overprivileged, it becomes part of the attack surface rather than just infrastructure.

What's in the full article

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

• Step-by-step GitHub Actions examples for adding security checks into a CI workflow
• Practical guidance on combining DAST, SAST, and secrets detection in one pipeline
• Documentation pointers for instrumenting StackHawk inside GitHub Actions
• Implementation details for teams that need to operationalise the workflow rather than just understand the concept

👉 StackHawk's full post covers the GitHub Actions workflow setup, testing stages, and secrets detection detail.

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 is designed for practitioners who need to connect identity controls to modern automation and delivery programmes.