Supply Chain Security & FedRAMP Compliance

The Challenge

FedRAMP Moderate authorization requires proving complete supply chain integrity for every container image in production. That means FIPS 140-3 validated cryptography, provenance attestation for every build artifact, zero tolerance for known vulnerabilities, and audit evidence that the image scanned is byte-identical to the image deployed. The platform I manage runs 40+ containers, so this couldn't be a manual process. It had to be automated, consistent, and impossible to skip.

Approach & Role

I designed and implemented the entire supply chain security framework. From base image selection through attestation verification, it's all in a single reusable GitHub Actions composite action (785 lines) that every repository in the organization consumes. No per-team configuration needed. Every container meets the same compliance bar.

The core problem I solved is a TOCTOU (time-of-check-to-time-of-use) gap. Most container pipelines scan images after pushing to a remote registry. Between push and scan, an unverified image exists in production-accessible storage. I eliminated that gap with a local OCI registry pattern: images are built, scanned, and attested locally before being published. The scanned image is cryptographically guaranteed to be the published image.

Architecture & Patterns

The local OCI registry pattern (TOCTOU elimination):

The fundamental security problem with most container pipelines: you push an image to a remote registry, then scan it after publication. Between push and scan, an unverified image sits in production-accessible storage. Worse, if you scan and then push separately, the image bytes might differ due to layer cache invalidation, concurrent builds, or registry-side rewriting.

I solve this by spinning up a local OCI-compliant registry within the CI runner itself. The build pipeline pushes to localhost:5000, runs all verification gates against that local image, and only copies the verified bytes to the production registry via crane copy. The SHA256 digest is tracked end-to-end. The scanned image is bit-identical to the signed image is bit-identical to the deployed image. No TOCTOU window exists.

This is implemented as a single 785-line GitHub Actions composite action that any repository can consume with zero per-team configuration.

Build pipeline (single composite action):

  1. Start local OCI registry (localhost:5000)
  2. Build container image, push to local registry
  3. Generate SBOM (CycloneDX + SPDX via syft) against local image
  4. Dual vulnerability scan (Trivy + Grype) against local image, defense in depth
  5. CIS Docker Benchmark compliance check (hard gate, exits code 1 on failure)
  6. Secrets scan (prevent credential leakage)
  7. Copy verified image to GHCR via crane copy (preserving digest)
  8. Keyless cosign signing via Fulcio OIDC (signs the exact digest from step 7)
  9. Four attestation types attached to the signed digest: SBOM, vulnerability report, SLSA provenance, build log

FIPS compliance:

CI/CD security hardening:

Reusable action design

Impact & Scale