CI/CD hardening checklist for a team with no security engineer

You can harden a CI/CD pipeline in an afternoon without a security engineer by working through twelve changes: restrict the default token, pin actions, protect branches, review workflow files, scope secrets to environments, avoid privileged triggers, prefer short-lived credentials, and keep runners clean. Start at the top, because the list is ordered by effect per hour spent.

The checklist

Do these in order. Each links to a longer post where it helps.

Tokens and identity

1. Set the default workflow token to read-only and declare permissions per job. See what permissions the token should have.
2. Replace stored cloud keys with short-lived credentials from OIDC where the provider supports it. GitHub's documentation lists the gains: no long-lived cloud secrets in GitHub, finer control of access, and credentials that expire after the job.
3. Delete unused secrets and write down an owner and rotation method for each one that remains. GitHub advises auditing registered secrets and rotating them periodically.

Code and change control

4. Protect the main branch: pull requests, approvals, required checks, no force pushes. See branch protection for a small team.
5. Put workflow files under code owner review. See CODEOWNERS for workflows.
6. Pin third-party actions to full commit SHAs and let Dependabot propose updates. See keeping pins current.

Triggers, secrets and caches

7. Find every pull_request_target and workflow_run trigger, and remove any that check out untrusted code. See fork pull requests and secrets.
8. Move production credentials into an environment with required reviewers. See approval before deploy.
9. Rewrite run steps that paste untrusted values into scripts. See script injection.
10. Check who can write your cache and keep release jobs minimal. See cache access.

Runners and visibility

11. Use hosted runners unless you truly need your own. If you self-host, use one job per fresh runner. See self-hosted runners.
12. Turn on logging and review. Know who changed a workflow, who approved a deployment and which runs used which secrets.

How this lines up with a recognised list

The OWASP Top 10 CI/CD Security Risks project names ten risk areas. They include insufficient flow control mechanisms, inadequate identity and access management, dependency chain abuse, poisoned pipeline execution, insufficient pipeline based access controls, insufficient credential hygiene, insecure system configuration, ungoverned usage of third party services, improper artifact integrity validation, and insufficient logging and visibility.

Roughly, items 1 to 3 address identity and credential hygiene, 4 and 5 address flow control, 6 addresses dependency chain and third party use, 7 to 10 address poisoned pipeline execution and pipeline based access, 11 addresses system configuration, and 12 addresses logging. The mapping is our own reading, so use the OWASP pages for the full definitions.

What to do after the afternoon

Hardening is a state you maintain. Put a recurring reminder every quarter to re-run the list, because new workflows, new contributors and new actions drift away from it.

Then look at the code and dependencies the pipeline builds, since a hardened pipeline can still ship a vulnerable package.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard handles the dependency and code side: scanning, reachability analysis to prioritise what matters, policy gates on pull requests, and fix pull requests that are off by default. A free scan is available at gold.safeguard.sh/scan. Pipeline settings remain yours to configure in GitHub or GitLab.

Quick check

Sources

• Secure use reference, GitHub Docs
• OpenID Connect, GitHub Docs
• OWASP Top 10 CI/CD Security Risks
• GitLab CI/CD variables, GitLab Docs

Last reviewed: 19 October 2026.