Written by Nelson Koning
on 

Practical steps to secure your CI/CD: ephemeral secrets, secret scanning, and artifact signing

CI/CD pipelines are the production lines of modern software — and like any factory, they’re only as safe as the tools, materials, and access controls around them. Recent supply‑chain incidents where trusted scanners and GitHub Actions were weaponized show that simply having scanners and secrets in place isn’t enough; you need a layered approach that treats secrets as ephemeral, scans aggressively at multiple points, and cryptographically proves the origin of build artifacts. (aquasec.com)

In this short guide I’ll walk through pragmatic, contemporary practices that fit into one secure mental model: make credentials short‑lived, catch leaks early, and sign what you produce so consumers can verify it.

Why this matters (real example)

Core patterns that reduce blast radius

1) Prefer ephemeral, federated credentials (no more static cloud keys)

jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Configure AWS credentials (OIDC) uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy aws-region: us-east-1 - name: Deploy run: aws s3 cp build/artifact.zip s3://my-bucket/

(Official actions and docs show this pattern; follow your cloud provider’s OIDC/trust configuration steps.) ([github.com](https://github.com/aws-actions/configure-aws-credentials?utm_source=openai))

If you need secrets at runtime (API keys, DB passwords), emit them from a secrets manager as short‑lived credentials instead of baking them into the repo — e.g., Vault dynamic credentials or cloud secrets with automatic rotation. HashiCorp Vault and cloud secrets engines support issuing ephemeral credentials for databases and cloud APIs. ([developer.hashicorp.com](https://developer.hashicorp.com/vault/docs/secrets/aws?utm_source=openai))

2) Catch leaked secrets at multiple points (pre‑commit, PR, server)
- Pre‑commit hooks and local developer tooling stop many accidental leaks before they reach the server. Tools like detect‑secrets and gitleaks can be run locally in pre‑commit or as a required step in CI. ([github.com](https://github.com/Yelp/detect-secrets?utm_source=openai))
- Server‑side scanning (e.g., GitHub’s secret scanning / push protection) adds safety for public and organization repos and can alert on known token formats or custom patterns. Use push‑protection so high‑confidence patterns block pushes. ([docs.github.com](https://docs.github.com/en/enterprise-server%403.16/code-security/secret-scanning/enabling-secret-scanning-features/enabling-secret-scanning-for-your-repository?utm_source=openai))
- Don’t forget history: some tools inspect full git history to find old commits containing keys. If you find leaks, rotate and revoke immediately and treat the incident as potentially wide‑ranging.

3) Harden CI toolchain: pin, verify, and prefer immutability
- Pin actions and dependencies to immutable references. Tag names are mutable and have been abused; prefer a commit SHA or an immutable release where supported. GitHub’s “Immutable Releases” feature (and general practice of pinning by SHA) give strong protection against tag‑poisoning. ([docs.github.com](https://docs.github.com/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases?utm_source=openai))
- Verify downloaded tooling and actions. Use artifact signing and transparency logs. Sigstore and Cosign lower the barrier to signing container images and build artifacts and to storing attestations in a public transparency log, so consumers can verify what they run. ([docs.sigstore.dev](https://docs.sigstore.dev/about/overview/?utm_source=openai))
- Be cautious with popular scanners and shared actions during and after supply‑chain incidents: monitor vendor advisories, pin to known‑good SHAs, and prefer actions with immutability or signed releases. The March 2026 Trivy compromise shows what happens if mutable tags and unsigned artifacts are relied upon. ([aquasec.com](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/?utm_source=openai))

4) Sign artifacts and produce SBOMs and attestations
- Signing: sign images, binaries, and SBOMs during the build. Consumers (deploy pipelines, admission controllers) can verify signatures before pushing to production. Cosign is the common Sigstore client for this purpose. ([docs.sigstore.dev](https://docs.sigstore.dev/quickstart/quickstart-cosign/?utm_source=openai))
- SBOMs: build tools and scanners (like Trivy) can generate Software Bill of Materials for images. SBOM + signature = verifiable, inspectable provenance. ([trivy.dev](https://www.trivy.dev/docs/v0.69/guide/target/container_image/?utm_source=openai))

Quick cosign example:
```bash
# sign an image (example)
cosign sign ghcr.io/my-org/my-app:1.2.3

# verify an image signature
cosign verify ghcr.io/my-org/my-app:1.2.3

Refer to Sigstore/Cosign docs for recommended key management and ephemeral certificate options. (docs.sigstore.dev)

Practical checklist (one page of controls)

Closing note — think like an auditor, move like a musician Securing CI/CD is less about a single silver‑bullet tool and more about composing a layered orchestra where short‑lived identities, multiple scanning layers, and cryptographic signatures play together. Imagine a band: if the drummer (scanner) suddenly plays a wrong note (is compromised), the rest of the ensemble (ephemeral credentials, signatures, policies) keeps the performance from collapsing. Treat each layer as both an enforcer and a detector, and favor ephemeral, verifiable constructs over static, long‑lived secrets. (aquasec.com)

References and further reading (select)

Keep your pipeline’s blast radius small, verify what you run, and treat even “security” tools as part of your threat model — a little defensive choreography goes a long way in keeping builds trustworthy.