Written by Albert Friedman
on 

Building a secure CI/CD pipeline with ephemeral secrets and automated scanning

Modern CI/CD pipelines accelerate delivery — and, if left unsecured, they accelerate breaches. Two failure modes show up again and again: long-lived secrets embedded in repos or CI variables, and late or missing security scans that allow vulnerable artifacts into production. This article shows a practical, recent approach that pairs ephemeral secret handling (OIDC + dynamic secrets) with automated, shift-left scanning (SAST, SCA, IaC, container) so pipelines are both usable and defensible. (arxiv.org)

Why this matters now

Large-scale measurements show secret leakage remains a major problem — millions of credentials have been exposed in public repositories in recent years — and attackers increasingly target CI/CD toolchains as a high-leverage entry point. Meanwhile, cloud providers and CI platforms now support federated identity (OIDC) and short-lived tokens that make long-lived credentials unnecessary. Adopting ephemeral credentials plus automated scanning reduces blast radius and finds issues earlier in the lifecycle. (arxiv.org)

Core building blocks

A practical workflow (pattern)

Below is a concise pattern that maps a GitHub Actions-like CI flow to dynamic secrets and scanning:

  1. Job starts; GitHub Actions issues a per-job OIDC token.
  2. The workflow exchanges that OIDC JWT for a short-lived credential from the secrets engine (e.g., HashiCorp Vault) or directly from the cloud provider (via federation).
  3. Secrets are injected into the job environment only for the lifetime of the job; no long-lived secrets persist in the repo or in CI variables.
  4. Run fast shift-left scans:
    • Semgrep for SAST and custom secret rules.
    • Trivy for container image CVEs and IaC misconfiguration checks.
  5. If scans pass, request ephemeral deployment credentials and execute the deployment step.

A minimal GitHub Actions snippet that sketches steps 1–4:

name: CI

on: [push, pull_request]

permissions:
  id-token: write      # allow OIDC token issuance
  contents: read

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Login to Vault via OIDC
        uses: hashicorp/vault-action@v2
        with:
          url: $
          role: "ci-role"
        env:
          VAULT_TOKEN: $

      - name: Run Semgrep (SAST + secret rules)
        uses: returntocorp/semgrep-action@v1
        with:
          config: "p/ci"

      - name: Build image
        run: docker build -t my-app:ci .

      - name: Trivy scan image + IaC
        uses: aquasecurity/trivy-action@v0
        with:
          image-ref: my-app:ci
          scan-type: "image,misconfig"

This pattern relies on OIDC-authenticated retrieval of secrets (step: Login to Vault) and then runs scanning steps before any deployment. HashiCorp and GitHub provide canonical guidance and integrations for this model. (developer.hashicorp.com)

Scanning choices and where to run them

Tip: Gate longer, more expensive scans (fuzzing, deep SCA with license analysis) to scheduled runs or release pipelines while keeping fast rule-based scans on PRs for immediate feedback.

Operational considerations

Trade-offs and common pitfalls

Conclusion

Secure CI/CD is an engineering trade-off: modest upfront effort in configuring OIDC federation and a central secrets engine, plus integrating fast automated scans, yields pipelines that are both fast and resilient. The pattern — ephemeral credentials + centralized secret policies + shift-left scanning — reduces the attacker surface and stops many issues before they reach production. The landscape and tooling keep evolving, but the core principles — least privilege, short-lived credentials, and early automated detection — remain steady. (docs.github.com)