Security in CI/CD: Secrets Management, SAST, Supply Chain

CI/CD CI/CD 8 min read 1596 words Beginner ExcellentWiki Editorial Team

CI/CD pipelines handle the most sensitive assets in software engineering: source code, credentials, cloud access keys, and deployment artifacts. A compromised pipeline gives attackers access to all of these. Real-world attacks — Codecov (2021), SolarWinds (2020), and the node-ipc protestware incident (2022) — demonstrate that CI/CD security is not optional. This guide covers secrets management, static and dynamic analysis, dependency scanning, container security, software supply chain protection, and the DevSecOps practices that build security into every pipeline stage.

Secrets Management

Secrets — API keys, database passwords, cloud provider credentials, TLS certificates — are the crown jewels of CI/CD security. A secret leaked in build logs, committed to a repository, or exposed in an environment variable is an immediate security incident.

Where Secrets Live in CI/CD

Secrets enter the pipeline in several ways:

Environment variables configured in the CI platform — GitHub Actions secrets, GitLab CI variables, Jenkins credentials, CircleCI contexts.
Repository files — .env files or configuration files accidentally committed. Even encrypted secrets in repositories are vulnerable if the decryption key is accessible.
Build artifacts — secrets baked into container images or deployment packages persist in registries and are accessible to anyone who pulls the image.
External services — secrets fetched at runtime from HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager.

Best Practices for Secrets in Pipelines

Never hardcode secrets. Secrets do not belong in source code, configuration files, or pipeline definitions. Every CI platform supports encrypted secrets — use them exclusively.

Least privilege for secrets. A pipeline building a frontend application does not need production database credentials. Scope secrets to the environment and job that requires them. GitHub Actions environment secrets and GitLab CI environment-scoped variables enforce this.

Short-lived credentials. Use access tokens with short expiration times. AWS STS temporary credentials (valid for 1 hour) are safer than long-lived access keys. HashiCorp Vault dynamic secrets generate credentials on demand and expire them after use.

Secret scanning in repos. Enable secret scanning on every repository. GitHub secret scanning, GitLab secret detection, and tools like Gitleaks, TruffleHog, and git-secrets scan commits and block secrets from being pushed.

# Pre-commit hook with gitleaks
gitleaks detect --source . --verbose

Audit secret access. Log every pipeline secret access — which job, which user, which branch, which time. CI platforms provide audit logs. Feed them to the SIEM for correlation with other security events.

Rotating Secrets

Secret rotation should be automated. Use tools like aws secretsmanager rotate-secret or Vault’s rotation capabilities. Cloud provider managed secrets services (AWS Secrets Manager, Azure Key Vault) support automatic rotation on a schedule.

Static Application Security Testing

SAST tools analyze source code for security vulnerabilities without executing the application. They identify SQL injection, cross-site scripting (XSS), command injection, insecure cryptography, and hundreds of other vulnerability patterns.

Integrating SAST into CI/CD

SAST scanning runs during the test stage, after compilation but before packaging:

# GitLab CI SAST job
semgrep-sast:
  stage: test
  script:
    - semgrep --config=auto --error .
  artifacts:
    reports:
      sast: gl-sast-report.json

Popular SAST tools include:

Semgrep — open-source, fast, supports 30+ languages. Community rules cover OWASP Top 10 and CWE Top 25. Rule customization fits team-specific patterns.
SonarQube — comprehensive code quality and security analysis. Integrates with GitHub and GitLab for inline PR annotations.
CodeQL — GitHub’s semantic code analysis engine. Uses query language to define vulnerability patterns. Deep analysis finds vulnerabilities other SAST tools miss.
Bandit (Python), Brakeman (Ruby on Rails), FindSecBugs (Java) — language-specific SAST tools.

SAST Configuration

Configure SAST tools thresholds that fail the pipeline:

Block on critical and high severity — any CVE-level vulnerability prevents the build from progressing.
Warning on medium severity — annotate the PR but do not block.
Accept low severity — track in the security dashboard for periodic review.

False positives are the main challenge with SAST. Establish a triage process: security engineers review SAST findings and suppress confirmed false positives with documented justification. Do not configure SAST to never fail — that defeats the purpose.

Dependency Scanning

Modern applications depend on dozens or hundreds of open-source packages. Each dependency introduces transitive dependencies, creating a dependency tree thousands of nodes deep. A vulnerability in any node threatens the application.

Software Composition Analysis

SCA tools identify dependencies, their versions, and known vulnerabilities:

# GitHub Actions dependency review
dependency-review:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/dependency-review-action@v4
      with:
        fail-on-severity: critical

Leading SCA tools:

Dependabot (GitHub) — automatic dependency updates with vulnerability PRs.
Renovate — configurable dependency update bot supporting many ecosystems.
Snyk — comprehensive SCA with fix advice and license compliance.
Trivy — open-source, scans OS packages and application dependencies.
OWASP Dependency-Check — free SCA with NVD data feeds.

Dependency Chain Protection

Beyond vulnerability scanning, protect the dependency chain itself:

Lock files — commit package-lock.json, yarn.lock, poetry.lock, requirements.txt with pinned hashes. Lock files ensure deterministic dependency resolution.
Private registries — proxy external registries through a private registry (Nexus, Artifactory, GitHub Packages). This provides an audit trail of allowed packages and versions.
Package allowlisting — only specific packages and versions can be used. Out-of-policy packages are blocked by the registry.

Container Security

Containerized CI/CD pipelines require security scanning at the image level:

Image Scanning

Scan container images for known vulnerabilities in base OS packages and application dependencies:

# Scanning with Trivy in GitHub Actions
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'registry.example.com/app:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'

Base Image Selection

Choose base images with minimal attack surface:

Distroless images — Google’s distroless/* images contain only the application and its runtime. No shell, no package manager, no utilities. A compromise cannot drop a shell.
Chainguard Images — minimal, actively maintained images with near-zero CVEs.
Alpine Linux — small base (5 MB musl-based) but uses musl libc instead of glibc, which can cause compatibility issues.

Supply Chain Levels for Software Artifacts

SLSA is a security framework for software supply chain integrity. SLSA levels (1–4) define progressively stricter build integrity requirements:

SLSA 1 — the build process documents provenance (who, what, when).
SLSA 2 — the build process runs in a hosted CI/CD environment.
SLSA 3 — the build runs on ephemeral, isolated infrastructure with hermetic builds.
SLSA 4 — the build is fully isolated, dependencies are pinned, and provenance is non-forgeable.

Most CI/CD pipelines aim for SLSA 3. Achieving SLSA 3 requires:

CI/CD pipeline runs in isolated, per-build environments
Build steps are hermetic (dependencies are explicitly declared and versioned)
Provenance is generated and signed by the CI/CD platform

Signing and Attestation

Sigstore’s cosign signs container images and other artifacts:

cosign sign --key cosign.key registry.example.com/app@sha256:...

Verification during deployment:

cosign verify --key cosign.pub registry.example.com/app@sha256:...

In-toto attestations provide a signed record of how the artifact was built, including the pipeline steps, source commit, and builder identity.

Pipeline Security Hardening

Beyond scanning code and dependencies, harden the pipeline infrastructure itself:

Restrict pipeline triggers — only allow trusted actors to trigger production pipelines. Use if: github.actor == 'trusted-user' or protected branch rules.
Least privilege for CI tokens — the CI token used by the pipeline should have minimal permissions. Do not use personal access tokens with full repository access.
Review third-party actions — GitHub Actions from the marketplace can execute arbitrary code. Pin actions to full commit SHA instead of version tags. Audit periodically for removed or compromised actions.
Isolate build environments — use ephemeral runners that are destroyed after each build. Shared runners leak state between builds.
Separate production from development — production pipelines should use separate runners, secrets, and environments from development pipelines.

Frequently Asked Questions

What is DevSecOps and how does it relate to CI/CD?

DevSecOps integrates security practices into DevOps workflows, making security a shared responsibility across development, operations, and security teams. In CI/CD, DevSecOps means security scanning runs as automated pipeline stages — SAST, dependency scanning, container scanning, secret detection — rather than as a manual gate before release. Shift-left security catches vulnerabilities early, when they are cheaper to fix.

Should I fail the pipeline on any security finding?

No. Fail the pipeline on critical and high-severity findings that are confirmed (not false positives). Medium and low findings should generate warnings, annotate PRs, and be tracked for remediation. Failing on every finding creates incentive to disable scanning entirely.

How do I handle security findings in third-party dependencies?

First, determine if the vulnerability is reachable in your application’s context — the dependency may include vulnerable code that your application never calls. For reachable vulnerabilities with available patches, update the dependency. For vulnerabilities without patches, add compensating controls (WAF rules, network segmentation, input sanitization) and track the exception with a remediation timeline.

What is the most important CI/CD security practice?

Secrets management. Most CI/CD security incidents start with an exposed credential. Adopt ephemeral credentials, use platform-native secret stores, enable secret scanning, and audit secret access. No other practice has as much impact on reducing the risk of pipeline compromise.

Conclusion

Security in CI/CD requires defense across multiple layers: secrets never exposed, code scanned before acceptance, dependencies monitored for vulnerabilities, container images hardened and signed, and supply chain provenance attested. The DevSecOps approach embeds these practices into every pipeline stage rather than treating security as a pre-release checklist. A secure CI/CD pipeline is the foundation of a secure software supply chain.

For a comprehensive overview, read our article on Artifact Management.

For a comprehensive overview, read our article on Ci Cd Best Practices.

Share this article

X LinkedIn Facebook Email