CI/CD Security Best Practices Every Developer Should Know

Estimated reading time: 12 minutes

Hook

Most teams trust their CI/CD pipeline more than they trust their own engineers — without realizing it. Your pipeline can read your code, inject new code, deploy to production, modify infrastructure, rotate secrets, and access private registries… all without anyone watching. And attackers know it.

A single leaked GitHub token, an insecure self-hosted runner, or a malicious open-source package can quietly take over your entire software supply chain. This post shows how CI/CD security actually works, how attackers compromise pipelines, and the CI/CD security best practices every team must follow to ship safely.

Introduction

CI/CD pipelines accelerate development, eliminate manual deployment errors, and help builders ship continuously. But they also introduce new, high-impact attack surfaces. Your pipeline:

Runs untrusted code
Has access to sensitive secrets
Connects directly to cloud infrastructure
Downloads packages from the public internet

CI/CD security is no longer optional. According to Sonatype’s 2024 Supply Chain Report, supply-chain attacks have increased 742% over the past three years. Many of these attacks specifically target CI/CD systems because they bypass the usual security walls.

In this guide, you’ll learn:

What CI/CD pipelines actually do
How attackers exploit them
How to harden GitHub Actions, GitLab CI, and other CI/CD platforms
Proven CI/CD security best practices
How to validate your pipeline with automated scanners (including Rafter)

Let’s get into it.

If you want to get Rafter set up with CI/CD, check out our docs.

What CI/CD Actually Does Under the Hood

Most teams think of CI/CD as “automated testing and deploys,” but technically, it’s far more powerful.

A typical CI/CD pipeline can:

Clone your entire repo
Inject or modify code
Build containers and artifacts
Store secrets in environment variables
Deploy infrastructure
Access cloud accounts through IAM roles
Publish packages to artifact registries

From an attacker's perspective, this is the holy grail. CI/CD has:

High privileges
Low monitoring
Many external dependencies
A large surface for supply-chain manipulation

Why CI/CD Pipelines Are a Top Attack Target

Attackers target CI/CD because:

Pipelines run arbitrary code by design
Build servers often store unencrypted secrets
API keys for production frequently live in the CI environment
Developers rarely audit pipeline logs
Third-party packages run inside builds

CI/CD is the ultimate “trusted execution environment” — and that trust is dangerous.

Common CI/CD Security Failures

You’ve probably seen these in the wild:

Secrets stored in plaintext .env files
GitHub/GitLab deploy tokens with admin access (yikes)
No signature verification for artifacts
Self-hosted runners with root privileges
Missing environment isolation
No security scanning in pipeline steps

If you’re using any of these, you have pipeline vulnerabilities.

How to Set Up a Secure CI/CD Pipeline

Below is the secure-by-default approach we recommend for most teams.

Step 1 — Lock Down CI/CD Credentials

Use short-lived credentials or ephemeral OpenID Connect (OIDC) tokens — not long-lived API keys.

Example (GitHub OIDC → AWS IAM)


permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Assume AWS Role
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789:role/DeployRole
          aws-region: us-east-1

This eliminates static credentials completely — a massive win for CI/CD security.

Step 2 — Implement Least Privilege for Every Job

Every job should have exactly the permissions it needs — no more.

Bad (way too much access)


permissions:
  contents: write
  packages: write
  deployments: write

Good (minimal access)


permissions:
  contents: read

Most GitHub Actions workflows don’t need write access at all.

Step 3 — Secure Secrets Management

CI/CD secrets should never live in .env files or Git history.

Better options:

GitHub Actions Encrypted Secrets
GitLab Protected Variables
AWS Secrets Manager
Doppler
HashiCorp Vault

Example: Fetching secrets securely


- name: Retrieve secret
  run: |
    export API_KEY=$(aws secretsmanager get-secret-value ...)

Rotate secrets automatically, and avoid passing them into jobs that don’t require them.

Step 4 — Enforce Environment Isolation

Dev ≠ Staging ≠ Production.

Isolate them rigorously:

Separate cloud accounts
Protected branches required for production deploys
Separate runners (never share prod secrets with dev runners)

Suggested Mermaid Diagram

This prevents lateral movement in case one environment is compromised.

Step 5 — Verify and Sign Everything

Use:

Signed commits
Verified authorship
Artifact signing (Sigstore / Cosign)
SLSA provenance attestations

A tampered commit or build artifact can undermine your entire security strategy.

Step 6 — Add Automated Security Scanning

Security scanning must be part of the CI/CD pipeline itself. Of course, we recommend using Rafter for this.

However, if you prefer to use other tools, here are some examples:

Example — Add Semgrep + Trivy to Pipeline


steps:
  - uses: actions/checkout@v4

  - name: Semgrep SAST scan
    uses: returntocorp/semgrep-action@v1

  - name: Trivy dependency scan
    uses: aquasecurity/trivy-action@master

Automating these checks dramatically reduces risk.

CI/CD Security Best Practices

Below are the highest-impact improvements you can make today.

Best Practice #1 — Protect Build Runners

Self-hosted runners are powerful and dangerous.

To secure them:

Use ephemeral runners (destroy after each job)
Disable SSH access
Run builds in containers
Don’t give root access to build environments

Containerized builds (e.g., GitHub Actions “Docker jobs”) reduce 80% of common runner risks.

Best Practice #2 — Monitor Pipelines Like Production

Your pipeline is production infrastructure.

Monitor:

Logins
Token usage
Workflow changes
Unusual job execution patterns
Failed authentication attempts

GitHub’s “audit logs” are your best friend here.

Best Practice #3 — Lock Down Dependencies and Supply Chain

Most pipeline compromises happen via packages, not code.

Defenses:

Pin versions
Don’t install from GitHub repos directly
Use dependency allowlists
Generate SBOMs (Trivy, Syft)
Validate checksums

Best Practice #4 — Enforce Code Integrity at Every Step

Turn on:

Required reviews
Protected branches
Signed commits
Admin-only workflow file changes

GitHub Actions workflows are code — treat them like it.

Best Practice #5 — Implement Policy-as-Code

Tools:

OPA/Gatekeeper
Kyverno
Rego policies
GitHub rule sets

These enforce rules like:

“No workflow can access production unless two admins approve”
“No job can run with root privileges”

Guardrails > guidelines.

How CI/CD Pipelines Get Hacked

Case Study #1 — CircleCI Breach (2023)

Attackers stole CircleCI session tokens, granting access to customers’ secrets. Many teams lost API keys, database credentials, and cloud tokens.

Lesson: Never store long-lived secrets in CI.

Case Study #2 — SolarWinds Build Pipeline Compromise

Attackers infiltrated the CI server, injected malicious code into a signed artifact, and distributed it globally.

Lesson: Sign everything and verify builds.

Case Study #3 — Malicious GitHub Actions PRs

Attackers submitted PRs containing workflow changes that exfiltrated secrets.

Lesson: Protect workflow files with branch rules.

How to Validate That Your CI/CD Pipeline Is Secure

Use a continuous security feedback loop:

Automated scans (SAST, dependency, secrets)
Token rotation
Pipeline monitoring
Regular workflow audits
Zero-day dependency alerting

Using Rafter for CI/CD Security

Rafter fits into CI/CD pipelines to provide:

Secrets exposure detection
Hardcoded credential detection
Insecure dependency alerts
App-logic security scanning for JS/TS + Python
Zero-config scans for vibe-coded apps

Drop Rafter directly into GitHub Actions or run locally:


npx @rafter/cli scan

CI/CD security is most effective when it’s effortless — exactly our mission at Rafter.

Conclusion

CI/CD pipelines are the backbone of modern software delivery — and one of the most overlooked security surfaces in engineering teams.

By applying these CI/CD security best practices, you significantly reduce your exposure to supply-chain attacks, leaked secrets, malicious PRs, and compromised dependencies.

If you want a fast, simple way to secure your CI/CD pipeline:

→ Run your first Rafter scan today

→ Secure your GitHub repo in under 30 seconds