CI/CD Security Checklist: How Engineering Leaders Stop Supply Chain Attacks

Attackers don’t breach production first; they breach your pipeline. This CI/CD security checklist shows how engineering and security leaders secure builds, secrets, and deployments.

CI/CD Security Checklist for Engineering Managers

Modern engineering teams ship fast.
Attackers move faster.

CI/CD pipelines are no longer just build systems; they are a critical part of production infrastructure. A compromised pipeline can allow attackers to inject malicious code, poison dependencies, leak secrets, or deploy compromised builds directly to production.

As Engineering Managers, we’re expected to maintain high delivery velocity while reducing security risks. This checklist gives you a practical way to audit and improve the security of your CI/CD pipeline without slowing down your team.

Key takeaways

• Fast pipelines stay fast when security is built in, not bolted on.

• Most CI/CD risks stem from convenience—exposed secrets, weak access controls, and unchecked changes.

• If a pipeline can deploy to production, it needs production-grade security controls.

• Every unverified dependency and unsigned artifact expands the attack surface.

• The best CI/CD security checks run quietly, early, and automatically.

• What you secure in the pipeline today is what you never have to investigate tomorrow.

1. Secure the foundation: access, branch protection & secrets

Most CI/CD compromises begin with weak access control or exposed credentials. Securing the foundation removes the most common attack paths.

What to review

Access control

• Enforce MFA across:

  • GitHub, GitLab, Bitbucket

  • CI platforms and artifact repositories

• Apply role-based access control (RBAC)

• Remove unused or inactive accounts regularly

Branch protection

Protect main (or release branches) with:

• Mandatory pull request reviews

• Required status checks

• No direct commits

Secrets management

Never store secrets in:

• Repositories

• CI/CD YAML files

• Plaintext environment variables

Use external secret managers:

• AWS Secrets Manager

• GCP Secret Manager

• Azure Key Vault

• HashiCorp Vault

Example: secure secret usage in GitHub Actions

GitHub Actions referencing protected secrets:

name: build-and-test
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Call internal API with a secure token
        env:
          API_TOKEN: $
        run: curl -H "Authorization: Bearer $API_TOKEN" https://internal.example.com/health

This simple pattern prevents accidental token exposure in code or logs.

2. Build stage security: dependencies, SBOMs & runners

The build stage is the core of the software supply chain. Attackers often target dependencies, base images, and build environments.

What to review

Dependency security

• Run Software Composition Analysis (SCA) on every build

• Tools: Snyk, Trivy, OWASP Dependency-Check

• Block builds on high or critical vulnerabilities

SBOM generation

• Generate a Software Bill of Materials (SBOM) for every build

• Formats: CycloneDX, SPDX

• Store SBOMs centrally for audit and incident response

Runner security

• Prefer ephemeral runners

• Avoid reusing build machines

• Prevent state persistence across jobs

Base images

• Use minimal base images (Alpine, Distroless)

• Avoid bloated or unmaintained images

Example: GitLab CI with dependency and image scanning stages

stages:
  - build
  - security

build-image:
  stage: build
  script:
    - docker build -t myapp:${CI_COMMIT_SHA} .

dep_scan:
  stage: security
  image: snyk/snyk:latest
  script:
    - snyk test --file=package.json --severity-threshold=high

image_scan:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL myapp:${CI_COMMIT_SHA}

This stops high-risk vulnerabilities from silently reaching production.

3. Security testing: SAST, DAST, and IaC scans

Security testing should be embedded into CI/CD the same way unit and integration tests are.

What to review

Static Application Security Testing (SAST)

• Run on every pull request

• Catch insecure code paths early

Dynamic Application Security Testing (DAST)

• Run against staging or ephemeral environments

• Identify runtime vulnerabilities

Infrastructure as Code (IaC) scanning

• Scan Terraform, Kubernetes manifests, Helm charts, and CloudFormation

• Detect misconfigurations before deployment

Example tools

• SAST: Semgrep

• IaC: Checkov

• DAST: OWASP ZAP, Burp automation

Example: GitHub Actions with Semgrep & Checkov

name: security-checks
on:
  pull_request:
    branches: [ main ]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: "p/ci"

  iac_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          soft_fail: false

4. Deployment security: approvals, identity & least privilege

The deployment stage often has the highest level of access and the highest risk.

What to review

Deployment controls

• Require manual approvals for production environments

• Use protected environments in GitHub or GitLab

Identity-based access

• Replace long-lived cloud keys with:

  • OIDC-based, short-lived credentials

• Avoid static credentials wherever possible

Least privilege

CI/CD service accounts should have:

• Only the permissions required to deploy

• No broad or admin-level access

Example: OIDC-based secure deployment

name: deploy
on:
  push:
    branches: [ main ]

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment:
      name: production
    permissions:
      id-token: write   # Enables OIDC
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Authenticate using OIDC
        run: echo "Requesting cloud token..."
      - name: Deploy
        run: ./scripts/deploy.sh

5. Observability, logging & incident response

If you can’t reconstruct “who did what, when, and how,” you’re blind during incidents.

What to review

Logging

• Centralize CI/CD logs using:

  • Splunk

  • Datadog

  • Elastic

• Retain logs according to compliance needs

Alerts

Trigger alerts on:

• Pipeline configuration changes

• Runner configuration updates

• Permission changes

• Secret rotations

Incident response

Maintain a CI/CD incident response runbook that includes:

• Token revocation

• Pipeline shutdown procedures

• Artifact validation

• Integrity rechecks and redeployments

Prepared teams recover faster and with less impact.

6. Additional high-impact practices

These controls are often skipped, but they provide substantial security gains.

Recommended additions

• Sign build artifacts using Cosign or Sigstore

• Enforce linting, formatting, and minimum test coverage

• Rotate pipeline credentials every 60–90 days

• Periodically review and clean:

  • Stale runners

  • Inactive users

  • Unused service accounts

• Isolate CI runners from internal networks unless required

How Appknox helps secure CI/CD pipelines

Checklists define what needs to be secured.
Execution is where most teams struggle.

This is where Appknox fits into modern CI/CD security workflows.

Appknox helps engineering and security teams embed automated security testing and visibility directly into CI/CD pipelines, so risks are identified early, before they reach production.

Where Appknox adds value across the CI/CD lifecycle

• During the code and build stages
  Appknox integrates into CI/CD pipelines to run automated security testing as part of every build, helping teams catch vulnerabilities early without slowing development.

• Across dependencies and artifacts
  With SBOM support and vulnerability visibility, teams gain clarity into third-party and open-source risk within the software supply chain.

• Before production deployments
  Security findings are prioritized by severity and risk, allowing teams to gate releases based on what actually matters.

• For security leaders and audits
  Unified dashboards and audit-ready reports give CISOs and security teams visibility into pipeline security posture, trends, and remediation progress with no manual effort.

• For developers and security teams
  Clear, actionable findings reduce back-and-forth and help teams fix issues faster.

In short, Appknox helps teams move from checklist-driven intent to pipeline-enforced security.

Final words

CI/CD security is not about slowing teams down; it’s about removing blind spots from the software delivery process.

By securing access, dependencies, testing, deployments, and observability, engineering and security teams can protect the software supply chain while maintaining delivery velocity.

A strong CI/CD pipeline is not just fast.
It is trustworthy.

See how Appknox secures CI/CD pipelines in practice.
Book a personalized demo to see how Appknox integrates with your CI/CD workflows and helps your teams ship securely, without slowing down.

Book your demo today.

FAQs: CI/CD Security for Engineering Managers

1. What parts of the CI/CD pipeline should engineering managers prioritize first?
Engineering managers should first secure access control, secrets management, and production deployment permissions. These areas typically have the highest blast radius.

2. How do engineering managers balance CI/CD security with delivery deadlines?
By automating checks early in the pipeline. Preventive controls avoid last-minute fixes and production incidents.

3. What CI/CD security responsibilities fall under engineering managers versus security teams?
Engineering managers own pipeline design and workflows. Security teams define risk thresholds and incident response. Shared ownership works best.

4. How can engineering managers reduce security friction for developers?
By integrating security checks directly into pull requests and CI/CD workflows.

5. What CI/CD security metrics should engineering managers track?
Failed security checks, time to remediate, pipeline change frequency, and release-blocking issues.

6. How often should CI/CD security controls be reviewed?
At least quarterly and after major changes or incidents.

7. What are common CI/CD security mistakes as teams scale?
Reusing long-lived runners, unused credentials, skipping SBOMs, and relying on manual approvals.

8. How can engineering managers prepare teams for CI/CD security incidents?
Maintain incident runbooks, centralized logs, token revocation steps, and clear ownership.