Article / engineering article
CI/CD security checklist: what to inspect before the next release
A pipeline can access code, artifacts and often production. Start by asking who can execute code with those privileges. This checklist gives a small team an inspection order without requiring another paid toolset.
Map the access boundaries
List events that start a pipeline: pull requests, pushes, tags and manual runs. Record permitted branches, runners, available secrets and publishing privileges alongside them. The most useful outcome is discovering a path from an external change to a privileged action.
Our design rule is to give untrusted-code checks and production deployments different trust conditions. Do not provide deployment credentials to a routine pull-request check simply because one job is convenient to maintain.
Reduce permissions and credential lifetime
GitHub recommends minimum GITHUB_TOKEN permissions and secrets instead of plaintext credentials. Where the provider and trust configuration support it, OIDC exchanges workflow identity for short-lived cloud credentials.
We inspect what a credential can do as well as where it is stored. Keeping a secret out of the repository is insufficient if any workflow can obtain an administrator token.
- Default to read-only permissions and elevate only the operation that needs them.
- Restrict cloud-role trust to the intended repository, branch or deployment environment.
- Inspect logs and artifacts for accidental disclosure.
- Revoke or rotate exposed credentials; deleting a line from Git is insufficient.
Inspect what enters the build
A third-party action executes code inside your workflow. GitHub recommends pinning actions to a full commit SHA. The pipeline owner needs to review dependency provenance and updates, not just a green status.
Our checklist separately covers the lockfile, runtime version, job network access and provenance of the artifact being released. Dependency scanning is useful when findings have an owner and a review deadline, rather than forming an endless warning list.
Define which findings block a release
Findings have different consequences. We recommend recording production exposure, exploitability and required permissions. Any exception needs a reason, an owner and a review date.
| Finding | First action |
|---|---|
| Exposed production credential | Revoke access and investigate its use. |
| Untrusted PR receives deploy access | Stop the unsafe trigger path and separate jobs. |
| Vulnerable dependency | Check reachability, update and exercise the critical workflow. |
| Abandoned scanner without an owner | Assign responsibility and restore handling of findings. |
Verify recovery as well as restrictions
Ask the team to show how it identifies the current release, restores a previous artifact and handles a failed migration. This exposes gaps that are hard to see in YAML alone.
The outcome should be a short list of concrete changes with responsible owners. This checklist organises the review; it is not a compliance certification or a substitute for inspecting the actual infrastructure.
Sources and context
Working through a similar problem?
Tell us about your product, current constraints and intended outcome. We will identify a concrete next step.