CI/CD & GitHub Security

pull_request runs the workflow in the fork's context with no access to the base repo's secrets and a read-only token, so even though it checks out attacker-supplied code, there's nothing valuable to steal — it's safe for untrusted forks. pull_request_target runs in the base repo's context with full secrets and a write token; it was designed so fork PRs could do privileged things like labeling. The danger is that it checks out the base branch by default, but developers often add an explicit checkout of the PR head SHA and then build or test it — now untrusted code runs with full secrets and write access, which is a complete compromise of the repo and anything those secrets reach. So the rule is: use pull_request for untrusted forks, and if you must use pull_request_target, never check out and execute the PR's code in that context.

Instead of storing a long-lived cloud key in GitHub Secrets, the runner requests a short-lived, signed OIDC token from GitHub that asserts who's running — the repository, branch, and workflow. The cloud provider has a trust policy that verifies those claims and, if they match, returns temporary scoped credentials. So there's no standing secret sitting in the secrets store to leak, the credentials expire in minutes, and you can scope the trust tightly — for example only the main branch of one specific repo may assume the production role. It's the CI/CD equivalent of using roles instead of long-lived users: you prove an identity rather than carrying a key, which removes the single most common CI credential-theft vector.

PPE is getting the CI runner to execute attacker-controlled code so it runs with the pipeline's privileges — secrets, cloud access, signing keys. Direct PPE is modifying the pipeline definition itself, the workflow YAML, for example adding a step that exfiltrates secrets, which works if the attacker can influence a branch that triggers the pipeline. Indirect PPE is modifying something the pipeline calls rather than the workflow file — a build script, Makefile, test config, or an npm lifecycle hook — so even a protected workflow file executes poisoned code. Indirect is sneakier because reviewers scrutinize the workflow YAML but overlook the scripts it invokes. The fork-based public variant abuses pull_request_target to run a fork's changes with the upstream repo's secrets.

Dependency confusion exploits how package managers resolve a name that exists in both a private internal registry and the public one. If a company uses an internal package and an attacker publishes a public package with the same name at a higher version, the resolver may pull the attacker's public package because it favors the highest version across configured sources — running their install-time code in the build. Prevention: scope or namespace internal packages so their names can't be claimed publicly, configure the resolver to only get internal names from the private registry, pin dependencies with hashes so an unexpected package is rejected, and claim your internal names defensively on the public registry. It was the basis of a famous 2021 research bug-bounty campaign that breached many major companies.

I'd instrument both the control plane and the build runtime. Control plane: alert on changes to workflow files, self-hosted runner config, branch protection, and any action whose pinned SHA changed, plus new collaborators or deploy keys. Runtime: monitor what builds actually do — unexpected outbound network connections during dependency install or build, processes spawning shells, and access to credentials a step shouldn't need — since malicious packages and poisoned steps reveal themselves by behavior. I'd also watch for new public packages matching our internal namespace, verify artifact provenance with SLSA attestations and signature checks so a tampered artifact is caught, and feed CI/CD audit logs into the SIEM. The premise is that attackers rely on CI/CD being a logging blind spot, so visibility into both who-changed-what and what-the-build-did is the detection.

SLSA is about provenance — proving how an artifact was built. Level 3 requires a hardened, hosted build platform and non-falsifiable, signed provenance. In practice that means builds run on a managed, isolated builder, not a developer's machine, where the build can't tamper with its own provenance; each build produces a signed attestation describing the source commit, the builder identity, and the build steps; and the signing uses a mechanism the build itself can't forge — for instance an ephemeral OIDC identity through Sigstore, with the signature logged in a transparency log like Rekor. Then consumers verify that provenance before deploying, enforced at admission via cosign and a policy engine or Binary Authorization. The result is you can cryptographically confirm an artifact came from your trusted pipeline off a specific commit and wasn't built or altered elsewhere.

It depends on the token's permissions and lifetime. The default GITHUB_TOKEN is automatically scoped per workflow and expires when the job ends, which limits exposure — but if it has broad permissions, within that window an attacker can push code, modify or create releases and packages, alter workflows to plant persistence, open or approve PRs, and touch anything in the repo it has write to, potentially poisoning artifacts that downstream consumers trust. If the workflow over-grants permissions, or worse if it's a long-lived personal access token or app token rather than the ephemeral GITHUB_TOKEN, the blast radius and duration grow dramatically. So the mitigations are setting least-privilege permissions at the job level, never echoing the token, and preferring the short-lived default token over PATs. The supply-chain angle is what makes it severe: write access to a build pipeline can ship malware with a trusted signature.