CI/CD Pipeline Security

Using GitHub Actions referenced by mutable tags like @main or @v3 instead of full commit SHAs means a compromised or hijacked action can inject malicious code into your CI pipeline without any change to your workflow file.

Using untrusted event data like github.event.issue.title directly inside run: blocks allows attackers to inject arbitrary shell commands into your CI pipeline by crafting malicious issue titles, PR bodies, or commit messages.

Printing or echoing environment variables containing secrets in CI scripts exposes them in build logs, which are often accessible to all repository collaborators and sometimes publicly visible on open-source projects.

Using self-hosted GitHub Actions runners with pull_request_target or public fork workflows allows untrusted code from external contributors to execute on your infrastructure with access to secrets, persisted state, and the host network.

GitHub Actions workflows with permissions: write-all or no explicit permissions block grant the GITHUB_TOKEN excessive access, allowing a compromised step to modify code, create releases, write packages, or change repository settings.

Without branch protection on main/production branches, any developer (or compromised account) can push directly, force-push destructive changes, or merge without code review, bypassing all quality and security gates.

A CI/CD pipeline that only runs tests and linting without any SAST, DAST, dependency scanning, or secret detection means vulnerabilities are only found after deployment -- if they are found at all.

Build artifacts (binaries, container images, packages) produced without cryptographic signatures or provenance attestations can be silently replaced by an attacker between the CI build and deployment, resulting in supply chain compromise.