Rebuilding a HIPAA CI/CD pipeline: signed promotion, OPA admission, and audit-grade evidence

Rebuilding a HIPAA CI/CD pipeline: signed promotion, OPA admission, and audit-grade evidence



Tópico: Rebuilding a HIPAA CI/CD pipeline: signed promotion, OPA admission, and audit-grade evidence
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
Signed promotion first. Admission control second. Evidence emission everywhere.

The boundary was solid. The pipeline shipping into it was not.

This is a redacted write-up of a real engagement: a HIPAA CI/CD pipeline overhaul for an AI SaaS vendor, the third engagement after a FedRAMP boundary build and a Kubernetes migration.



The context


After the FedRAMP authorization architecture shipped and the Kubernetes migration brought the production workload onto EKS, the team turned to a problem they had been deferring: the HIPAA-side CI/CD pipeline still ran on patterns inherited from before either of the previous engagements.

The pipeline produced container images, ran tests, and pushed to ECR. But:

• it did not sign artifacts

• it did not enforce policy at admission time on the EKS cluster

• security scans ran, but findings were emailed to a Slack channel engineers had quietly muted

• the audit trail was GitHub Actions logs that aged out at 90 days, shorter than the audit cycle they had to defend

The team understood the gaps. The next HITRUST i1 cycle was on the calendar, and the prior boundary review had flagged the pipeline as a known risk. The scope was clear: rebuild the pipeline so HIPAA controls are enforced structurally, not by human discipline, and produce evidence that survives the audit window.



The approach


Three architectural commitments shaped the rebuild. Every artifact reaching production must carry a cryptographic provenance chain from source commit through admission. The cluster itself must reject any workload that fails policy, with the rejection logged as evidence. And every gate decision, scan result, and admission verdict must emit to a write-once store that outlives the deploy that produced it.

┌──── GitHub Actions Workflow (HIPAA build) ─────────────────────────────────────────────┐
│                                                                                          │
│  ┌─────────┐    ┌──────────────┐    ┌────────────┐    ┌──────────────┐    ┌──────────┐ │
│  │  Lint   │──▶│  Build &     │──▶│  Security  │──▶│  Sign         │──▶│  Push    │  │
│  │ + Test  │    │  SBOM        │    │  Scan      │    │  (Cosign)    │    │  to ECR  │  │
│  └────┬────┘    │  (Syft)      │    │ (Trivy +   │    │  + Attest    │    └────┬─────┘ │
│       │         └──────┬───────┘    │  Semgrep)  │    └──────┬───────┘         │       │
│       │                │            └──────┬─────┘           │                  │       │
│       └────────────────┴───────────────────┴─────────────────┴──────────────────┘       │
│                                          │                                              │
│                              Evidence: each step                                        │
│                              emits to S3 (Object Lock 7yr)                              │
└────────────────────────────────────────────┬───────────────────────────────────────────┘
│
▼
┌──────────────────────────────────┐
│  EKS Cluster (HIPAA workloads)   │
│                                  │
│  ┌────────────────────────────┐  │
│  │  OPA Gatekeeper Admission  │  │
│  │  - Verify Cosign signature │  │
│  │  - Check SBOM presence     │  │
│  │  - Reject unsigned images  │  │
│  │  - Log admission verdict   │  │
│  └────────────────────────────┘  │
│                                  │
│  Pod → Service → Production      │
└──────────────────────────────────┘
│
▼
All decisions → Evidence stream
(Athena queryable, retention-locked)



Key decisions


•
Cosign signing with KMS-backed keys. Images signed in the pipeline using Cosign, with signing keys managed in AWS KMS inside the FedRAMP boundary established in the prior engagement. Same key topology, same identity federation, same audit chain. The HIPAA pipeline inherits the FedRAMP infrastructure rather than running parallel to it.

•
SLSA Level 3 provenance attestation. Every image carries a provenance attestation generated during the build, signed alongside the image, and verifiable by any downstream consumer. The attestation records the source commit, the builder identity, the build inputs, and the policy decisions made during the build.

•
OPA Gatekeeper admission policy. The EKS cluster rejects any pod whose image does not have a valid Cosign signature traceable to the pipeline signing key. Unsigned images cannot reach production by accident; the cluster refuses them at admission time and the refusal is logged as evidence.

•
Security scanning as pipeline gates. Trivy and Semgrep run as required stages with explicit pass/fail thresholds. Findings above threshold fail the build. Below-threshold findings are emitted to the evidence stream with deduplication, so engineers see actionable items, not noise. The muted Slack channel is no longer the disposition path for findings.

•
SBOM generation with Syft. Every build produces a software bill of materials in SPDX format, signed alongside the image. The SBOM is queryable from the evidence stream, so a question like "where is log4j 2.14 still running" is answered with a query, not an inventory project.

•
Evidence emission at every step. Each stage emits structured JSON to a centralized evidence bucket with Object Lock retention configured for 7 years. Auditors get query access via Athena; engineers cannot alter the evidence after emission.

•
Reusable workflow as the contract. The HIPAA-pipeline-as-code is published as a reusable GitHub Actions workflow that other repos call. The workflow definition is the compliance contract: changing the controls it enforces requires a code review. The pattern compounds across new services that join the platform.



What we built


Because the FedRAMP boundary and the Kubernetes platform had already shipped, this work inherited their identity, KMS topology, logging architecture, and network segmentation. It slotted into that infrastructure rather than introducing parallel patterns.

Reusable GitHub Actions workflow. Versioned, called by reference rather than duplicated. It runs the security gates, signs artifacts, enforces SBOM generation, and emits evidence. New services adopting the platform inherit the controls by calling the workflow.

Cosign signing infrastructure. Keys in AWS KMS inside the FedRAMP boundary, signing identity federated from the existing IdP via OIDC. No long-lived signing credentials anywhere. The signature includes SLSA Level 3 provenance.

OPA Gatekeeper admission policies. Reject any image without a valid Cosign signature. Reject events are logged with full context (image, signature attempted, policy that rejected, time, namespace) to the evidence stream. Engineers cannot bypass admission because the cluster refuses to schedule workloads that fail policy.

Centralized evidence pipeline. The same evidence bucket from the FedRAMP engagement, extended with HIPAA-specific streams: signed artifact emissions, admission decisions, scan results, SBOM publications. Athena query layer over the top. The Splunk SIEM connection from the prior work continues to consume the stream through the same cross-account read role.

Audit query interface. Pre-built Athena queries for the questions HITRUST i1 assessors ask most: which images reached production with valid signatures over a date range, which deployments added new dependencies, which admission events were rejected, which SBOMs contain a specific vulnerable component. Seconds, not reconstruction work.

"Hired Lucas to overhaul our CI/CD pipelines in a HIPAA environment and he absolutely delivered. He rebuilt our pipelines with proper artifact promotion, added security scanning, and tightened up our deployment process so we're now both faster and more compliant. Deployment time dropped significantly and the audit trail is now clean."

Ryan S., CTO @ AI SaaS



Results


Outcome

100%
production images signed with verifiable provenance

7 yr
evidence retention with cryptographic integrity

0
findings on the post-rebuild HITRUST i1 readiness review for pipeline-related controls

The rebuild closed every gap flagged during the prior boundary review related to CI/CD architecture. The team has since adopted the reusable workflow across additional repos, so each new service inherits the controls by calling the workflow rather than rebuilding them. The pattern compounds rather than ages.



What made it work


Inheriting the boundary from prior work. The signing keys live in the KMS topology from the FedRAMP engagement. The evidence bucket is the same one the boundary review created. Multi-engagement relationships compound when each new engagement extends the prior architecture instead of running alongside it.

Admission control as the enforcement layer. Signing is only as strong as the verification at the consumption point. OPA Gatekeeper at admission time is what makes the signing meaningful: the cluster refuses to schedule unsigned images, and the refusal is logged. Engineers cannot bypass the control by writing a different pipeline, because the cluster refuses what the pipeline does not produce.

Reusable workflow as the compliance contract. Publishing the pipeline as a reusable workflow turns it from a per-repo template into an organization-level artifact. New services inherit the controls by calling it. The compliance contract becomes a property of the platform, not a discipline the team has to remember to apply.

Originally published at stonebridgetechsolutions.com.

Stonebridge Tech Solutions builds compliance-grade cloud infrastructure for healthcare and defense teams. If you want a rough read on your own control count and first-cycle audit cost, the scope estimator takes about two minutes.