CI/CD pipelines move fast. That is why they are a prime target and a prime control point. You do not need to bolt on a heavy security program, but you do need to insert the right checks at the right stage.

This guide maps practical security controls to each phase of a CI/CD pipeline and explains why they belong there.

1. Source control: protect the entry point

If the repo is weak, the rest of the pipeline is exposed.

Practical steps:

  • Require MFA and SSO for source control.
  • Enforce branch protection and code review.
  • Block force pushes to main.

Reference:

2. Pre-commit and PR checks: catch issues early

Fast feedback prevents broken builds and risky merges.

Practical steps:

  • Run secret scanning on commits.
  • Run linting and unit tests for obvious errors.
  • Add a basic SAST check for high-risk patterns.

References:

3. Build stage: isolate and verify

Builds should be repeatable and trusted.

Practical steps:

  • Use ephemeral build runners.
  • Pin base images and dependencies.
  • Generate an SBOM for built artifacts.

References:

Starter plan for the first sprint

If you are starting from zero, do a small set of changes and keep the pipeline green.

Starter plan:

  • Enable branch protection and reviews
  • Add secret scanning on PRs
  • Run dependency checks on build
  • Add a production approval step

4. Dependency checks: manage third-party risk

Supply chain issues often start in dependencies.

Practical steps:

  • Run dependency scanning on every build.
  • Fail builds on critical CVEs with a clear policy.
  • Track exceptions with owners and expiry dates.

Reference:

5. Artifact handling: sign and store

Artifacts should be traceable and tamper-resistant.

Practical steps:

  • Sign artifacts during build.
  • Store artifacts in a controlled registry.
  • Require provenance metadata for releases.

Reference:

6. Deploy stage: add approvals where risk is highest

Deployment is the moment of highest impact.

Practical steps:

  • Require manual approval for production deploys.
  • Use environment-specific variables and secrets.
  • Block deploys that reduce security controls (for example, disable logging).

Reference:

7. Runtime checks: verify after deploy

Security does not stop at deploy.

Practical steps:

  • Run post-deploy smoke tests and security checks.
  • Verify key config settings (TLS, logging, IAM roles).
  • Alert on unexpected changes in production.

Reference:

8. Keep the pipeline itself secure

Pipelines can be abused if the control plane is weak.

Practical steps:

  • Restrict who can edit pipeline definitions.
  • Use least privilege for pipeline IAM roles.
  • Log pipeline changes and build actions.

Reference:

9. Handle secrets in the pipeline carefully

Secrets are often exposed in build logs or environment variables.

Practical steps:

  • Use a secret manager and inject values at runtime.
  • Mask secrets in build logs.
  • Avoid storing secrets in pipeline config files.

References:

10. Separate environments by design

If build and deploy environments are mixed, security drift is common.

Practical steps:

  • Use separate accounts or projects for prod and non-prod.
  • Restrict cross-environment access.
  • Store prod secrets in a separate secret manager.

Reference:

11. Prepare for rollback

Security also means the ability to reverse a bad release.

Practical steps:

  • Keep the previous artifact available for quick rollback.
  • Use automated rollback on failed health checks.
  • Record who approved the change.

12. Watch for common failure modes

Small gaps in the pipeline create big exposure.

Common issues:

  • CI tokens with admin access to production
  • Secret values printed in build logs
  • Bypassing approvals in “emergency” deploys

13. Example control placement

If you need a quick map, start here:

  • Source: MFA, branch protection, code review
  • Build: dependency scanning, SBOM, artifact signing
  • Deploy: approval gate, config validation, post-deploy checks

Quick checklist

  • Branch protection and review in source control
  • Secret scanning and dependency checks in PRs
  • Signed artifacts stored in a controlled registry
  • Approval gate for production deploys
  • Post-deploy validation with alerts

Closing thought

CI/CD security works best when it is placed in the right spots and tuned for your team. Protect the repo, validate code and dependencies, sign artifacts, and add guardrails at deploy time. Those steps catch real risk without slowing delivery.

If you want help mapping security controls into your pipeline, we can help. We focus on practical steps that keep delivery moving. Reach out through our consulting page to start a quick conversation.