Written by Albert Friedman
on 

Short-lived identities and automated scanning: a practical pattern for secure CI/CD secrets

Modern CI/CD pipelines do two risky things at once: they act with privileged access to deploy and they process source that can contain secrets or insecure dependencies. A pragmatic way to reduce those risks is to combine ephemeral identities (so the pipeline never stores long-lived cloud credentials) with automated scanning (SAST, dependency scans, image/IaC checks and secret detection). This article explains the why, the common patterns, and small examples that make the pattern concrete. (tag-security.cncf.io)

Why ephemeral identities matter in CI/CD

Long-lived credentials in repos, runner environments, or image layers are a persistent invitation for attackers: once a secret is leaked, it can be reused until someone rotates it. Short-lived or ephemeral credentials limit the window of abuse because they automatically expire and are tied to an issued identity. This reduces blast radius and aligns with modern zero-trust principles for machine identities. The cloud and supply‑chain guidance community now recommends ephemeral credentials for machine/service access in CI/CD contexts. (tag-security.cncf.io)

Common ephemeral patterns:

OIDC-based, secretsless authentication (typical flow)

Platforms such as GitHub Actions expose an OIDC token at runtime that the job can present to a cloud provider (or a brokerage service) and receive temporary credentials (for example AWS STS tokens). This means the repository doesn’t contain permanent keys and the credential is only valid for a short session. The cloud-side trust relationship must be carefully scoped (audience, repo, branch, environment) to avoid token replay or cross-repo misuse. GitHub documents the OIDC integration and the common actions that perform the exchange. (docs.github.com)

Example (GitHub Actions -> AWS via the official action):

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write     # required for OIDC token exchange
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
          aws-region: us-east-1
      - name: Deploy
        run: aws s3 cp myapp s3://my-bucket --recursive

The action exchanges the GitHub-issued OIDC token for temporary AWS credentials so long-lived keys never land in the repository or runner environment. Proper IAM trust conditions (restricting token audience, repository and workflow) reduce misuse risk. (docs.github.com)

Automated scanning: multiple layers, complementary coverage

Ephemeral credentials reduce the damage from leaked keys, but they don’t stop insecure code, vulnerable libraries, or accidental secrets in commits. Build-time scanning fills that gap. A robust CI/CD pipeline typically runs a combination of:

These scans are complementary: SAST finds risky code patterns, SCA finds vulnerable libraries, image/IaC scanners find runtime exposures, and secret scanners catch accidental leaks.

Example: small GitHub Actions pipeline that combines OIDC and scans

A compact workflow can cover the essential pattern: use OIDC to get deploy credentials, run a dependency scan, run a CodeQL scan, run an image/IaC scan, and gate deploys on scan results. The snippet below demonstrates the sequence without claims about a specific policy engine:

name: CI

on: [push, pull_request]

jobs:
  analysis:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4

      - name: Run CodeQL (SAST)
        uses: github/codeql-action/init@v2
        with:
          languages: javascript
      - uses: github/codeql-action/analyze@v2

      - name: Dependency scan (Dependabot runs in background)
        run: echo "Dependabot configured via repository settings"

      - name: Trivy scan (image / IaC / secrets)
        uses: aquasecurity/trivy-action@v0
        with:
          scan-type: fs
          format: table

  deploy:
    needs: analysis
    if: $
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
          aws-region: us-east-1
      - name: Deploy
        run: echo "deploying..."

Note: the example uses the official CodeQL and Trivy actions and the AWS OIDC exchange action to avoid long-lived keys in the repository. Each tool’s documentation includes configuration and advanced options. (codeql.github.com)

Caveats and common implementation pitfalls

Closing note: combined risk reduction

Ephemeral identities reduce the standing attack surface by removing long-lived credentials from repos and runners; automated, layered scanning reduces the probability that insecure code or leaked secrets make it to production. When the two patterns are used together, the pipeline’s capacity to both do work and be misused is substantially reduced — but only if the OIDC trust and scanner deployments are themselves managed and monitored. The referenced provider and tooling docs contain the configuration specifics and caveats for each integration. (tag-security.cncf.io)

Further reading (selected docs used in this article):