HIPAA Compliance Mapping for CleanStart Container Images

Healthcare organizations face strict Protected Health Information (ePHI) requirements under HIPAA's Security Rule. CleanStart container images address these obligations through immutable infrastructure, signed artifacts, and verifiable supply chain integrity.

Regulatory Framework

The Health Insurance Portability and Accountability Act requires covered entities and business associates to implement safeguards across three categories: Administrative, Physical, and Technical. Container images introduce new compliance challenges — they must run without elevated privileges, prevent tampering, and provide audit trails for ePHI processing.

CleanStart images meet these requirements by design: Distroless construction eliminates unnecessary packages and attack surface Read-only root filesystem prevents unauthorized modifications Non-root UID 65532 enforces principle of least privilege Signed artifacts enable integrity verification SBOM documentation supports audit requirements

§164.308: Administrative Safeguards

Administrative safeguards establish policies and procedures for access control, workforce security, and security awareness.

164.308(a)(1): Security Management Process

Requirement: Implement policies to manage identified risks and vulnerabilities.

How CleanStart Helps: SLSA provenance documents who built the image, when, on which build system, and which source commits were included. This creates an auditable chain of custody for container images processing ePHI.

164.308(a)(2): Workforce Security

Requirement: Establish access policies for authorized users.

How CleanStart Helps: Registry authentication logs create an immutable record of who pulled which images at what time. Non-root execution (UID 65532) ensures containers never run with administrative privileges, limiting damage from compromised workload code.

164.308(a)(3): Information Access Management

Requirement: Implement policies limiting ePHI access to authorized individuals.

How CleanStart Helps: By controlling image pull authentication at the Kubernetes layer, organizations ensure only authorized workloads can deploy ePHI-processing containers.

164.308(a)(4): Security Awareness Training

Requirement: Train workforce on security policies and procedures.

164.308(a)(5): Security Incident Procedures

Requirement: Establish procedures for identifying, responding to, and documenting security events.

How CleanStart Helps: When a security incident occurs, audit logs pinpoint which images were deployed when. Signed provenance attestations prove the image wasn't modified after creation. SBOMs show the exact software versions in the deployed container, enabling rapid vulnerability assessment.

164.308(a)(6): Contingency Planning

Requirement: Establish disaster recovery procedures.

164.308(a)(7): Business Associate Contracts

Requirement: Establish contracts with business associates requiring security compliance.

§164.310: Physical Safeguards

Physical safeguards protect the infrastructure hosting ePHI. Container images deployed on this infrastructure must support verifiable security properties.

164.310(a)(1): Facility Access Controls

Requirement: Limit physical and logical access to facilities.

How CleanStart Helps: Distroless images contain no shell, no debugging tools, and no package manager. Even if an attacker gains physical access to infrastructure and compromises a running container, they cannot execute commands to exfiltrate ePHI. Read-only filesystem prevents persistence.

164.310(a)(2): Workstation Use and Security

Requirement: Define policies for workstation access and use.

164.310(a)(3): Workstation in and Movement of ePHI

Requirement: Manage ePHI in transit and at rest.

§164.312: Technical Safeguards

Technical safeguards are the primary mechanisms CleanStart images address.

164.312(a)(1): Access Control

Requirement: Implement mechanisms to control access to ePHI.

How CleanStart Helps: Non-root execution and read-only root filesystem mean containers cannot escalate privileges or modify image contents at runtime. If a vulnerability is exploited in application code, the attacker's options are severely limited.

164.312(a)(2)(i): Unique User Identification

Requirement: Issue, track, and manage unique identifiers.

164.312(a)(2)(ii): Emergency Access Procedures

Requirement: Establish procedures to access ePHI when normal systems fail.

How CleanStart Helps: Because the root filesystem is read-only and enforced at runtime, no emergency procedure can override security properties. All emergency access flows through normal Kubernetes RBAC, creating audit trails.

164.312(a)(2)(iii): Encryption and Decryption

Requirement: Protect ePHI in transit and at rest.

164.312(b): Audit Controls

Requirement: Implement mechanisms to record and examine activity.

How CleanStart Helps: Tamper-Proof Logging: Attestations are cryptographically signed; audit logs show hash of each attestation. If logs are modified, the hash verification fails. Forensic Clarity: Signed SBOM captures exact software versions deployed. If a security incident occurs and ePHI is exposed, auditors can determine within minutes which versions were running. Chain of Custody: Build provenance shows source code commit, builder identity, and build timestamp. Combined with deployment logs, creates complete audit trail.

Example Audit Log Entry:

{  "timestamp": "2026-03-22T14:30:00Z",  "actor": "ci-cd@healthsystem.iam.gserviceaccount.com",  "operation": "image_pull",  "image": "registry.cleanstart.com/healthapp/ehr:v2.4.1",  "digest": "sha256:abc123...",  "image_attestation": {    "type": "application/vnd.in-toto+json",    "signature": "MEYCIQDvPe9...",    "slsa_provenance": {      "builder": "https://cleanstart.com/build/v1",      "build_type": "https://github.com/Shattered-Throne/cleanstart",      "invocation_parameters": {        "source_commit": "deadbeef123...",        "build_start_time": "2026-03-22T12:00:00Z"      },      "materials": {        "source_code": "github.com/healthsystem/ehr@deadbeef"      }    }  },  "sbom": {    "format": "application/vnd.cyclonedx+json",    "hash": "sha256:123def...",    "components_count": 47,    "components_with_known_cves": 0  },  "result": "success",  "pull_duration_ms": 2340}

164.312(c)(1): Integrity Controls

Requirement: Protect ePHI from improper alteration or destruction.

How CleanStart Helps: Signature Verification: Every CleanStart image includes a cryptographic signature. Organizations deploy images only after cosign verify succeeds. If an attacker modifies the image after deployment, the signature becomes invalid (prevents post-hoc tampering detection failures). Attestation Integrity: in-toto attestations are signed by build system. Auditors can verify provenance hasn't been modified by checking signature with CleanStart's public key (published openly).

164.312(c)(2): Transmission Security

Requirement: Protect ePHI while in transit.

§164.313: Organizational Requirements

164.313(a): Business Associate Contracts

Requirement: Business Associate agreements with vendors must define HIPAA responsibilities.

CleanStart's Role: As a BA, CleanStart: Implements and maintains administrative, physical, and technical safeguards Notifies customer (CE) of security breaches within 60 calendar days Authorizes only permitted uses of ePHI Provides access controls, encryption, audit logging Complies with HIPAA audit and compliance requests

BAA Template Available: Yes. Standard BAA available at compliance.cleanstart.com/baa

Key Provisions: CleanStart acts as BA; customer retains responsibility as CE ePHI may be processed only as directed by customer Subcontractors (AWS, Okta, etc.) are bound by signed data processing agreements Customer rights to audit, terminate, and obtain certificates of destruction

Implementation Guidance: HIPAA Container Security Best Practices

Best Practice 1: Image Scanning and Vulnerability Management

Audit Requirement: Demonstrate periodic vulnerability assessment per §164.308(a)(1)(ii)

CleanStart Implementation:

# Export SBOM from CleanStart imagecosign download sbom registry.cleanstart.com/healthapp/ehr:v2.4.1 > sbom.spdx.json # Scan SBOM against CVE databases (Grype, Syft)grype -i sbom.spdx.json --fail-on high # Compliance evidence: SBOM + scan results# Retention: 6 years for audit trail

Auditor Verification: Review SBOM for all production images Verify no High/Critical CVEs without active remediation plan Check scan results dated within 30 days

Best Practice 2: Image Signing and Attestation Verification

Audit Requirement: Verify image integrity before deployment per §164.312(a)(2)(iii)

CleanStart Implementation:

# Set up image pull with signature verification (Kubernetes admissionController)cat <<EOF | kubectl apply -f -apiVersion: admissionregistration.k8s.io/v1kind: ValidatingWebhookConfigurationmetadata:  name: cleanstart-signature-verifywebhooks:- name: verify-cleanstart-images  rules:  - operations: ["CREATE", "UPDATE"]    apiGroups: [""]    apiVersions: ["v1"]    resources: ["pods"]  failurePolicy: Fail  admissionReviewVersions: ["v1"]  clientConfig:    service:      name: cosign-verify-webhook      namespace: security      path: "/verify"EOF # Every image pull now requires valid cosign signature# Unsigned images rejected; audit log records rejection

Auditor Verification: Attempt to deploy unsigned image; should be blocked Review webhook logs showing acceptance/rejection Verify cosign public key is published and auditable

Best Practice 3: Access Control and Multi-Factor Authentication

Audit Requirement: Implement unique user identification and MFA per §164.312(a)(2)(i) and §164.308(a)(2)

CleanStart Implementation:

# Create service account with limited permissionskubectl create serviceaccount ehr-deployer -n productionkubectl create rolebinding ehr-deploy-images \  --clusterrole=image-puller \  --serviceaccount=production:ehr-deployer # Bind to specific registry (enforced via admission control)# Tokens are short-lived; rotated every 24 hours by Kubernetes # Audit: All image pulls logged with service account identitykubectl logs -n kube-system -l app=kubelet | grep image_pull # MFA for console access (if accessing CleanStart console)# Enforced via Okta SAML + TOTP

Auditor Verification: List all active service accounts pulling images Verify token age <24 hours Check MFA enrollment for administrative users

Best Practice 4: Audit Logging and Retention

Audit Requirement: Implement audit controls and retain logs 6 years per §164.312(b)

CleanStart Implementation:

# Export audit logs from registrygcloud logging read "resource.type=api AND resource.labels.service_name=containerregistry" \  --limit=unlimited \  --format=json > registry-audit-logs-2026.json # Archive to immutable storagegsutil cp registry-audit-logs-2026.json gs://compliance-logs-immutable/2026/ # Protect archive from deletion (GCS object lock / retention policy)gsutil retention set 10y gs://compliance-logs-immutable/ # Verify compliance: 6 years of logs retainedgsutil retention get gs://compliance-logs-immutable/# Output: Retention Policy: 10 years

Auditor Verification: Confirm logs retained ≥6 years Spot-check log entries for image pulls (timestamp, user, outcome) Verify logs are immutable (cannot be deleted without override)

Best Practice 5: Incident Response and Breach Notification

Audit Requirement: Establish incident response procedures per §164.308(a)(5)

CleanStart Incident Response:

Scenario: CVE-2026-XXXXX discovered in production image; CVSS 9.5 Timeline:T+0:  Vulnerability disclosed; CleanStart security team alertedT+4h: Security assessment: CVE affects cleanstart/python:3.11 base imageT+24h: Patch applied to base; new image published with SBOMT+36h: Customer notified of CVE + patched image availabilityT+7d: Customer deploys patched image (SLA: 7 days for Critical CVEs) Evidence Generated:- SBOM.spdx: List all software versions in patched image- Attestation (in-toto): Signed proof of build process- Release Notes: Vulnerability description, affected versions, remediation- Incident Report: Root cause, timeline, prevention measures

HIPAA Breach Notification: If ePHI exposure occurs:

T+0:    Breach detected; incident commander appointedT+4h:   Security assessment; customer notification initiatedT+24h:  Detailed breach notification sent to CE contactT+60d:  Final forensic report; regulatory filing if required

Best Practice 6: Supply Chain Risk Management

Audit Requirement: Manage business associate compliance per §164.313(a)

Subcontractor Assessment:

Risk Mitigation: All subcontractors have signed Data Processing Agreements (DPAs) Annual security assessment of each subcontractor Immediate notification if subcontractor experiences security incident

PHI/ePHI Handling in CleanStart Containers

Does CleanStart Store ePHI?

Short Answer: No. CleanStart does not access or store patient health information.

Explanation: Container images are application code + runtime CleanStart builds/signs/stores images; does not decrypt or examine contents If a customer's application processes ePHI (e.g., EHR software), the ePHI remains in the customer's database, not in the image

Containers Processing ePHI: Customer Responsibilities

If your application processes ePHI, you are responsible for:

1. ePHI Identification: Know which containers process ePHI
2. Encryption at Rest: Database and file storage encrypted (outside CleanStart)
3. Encryption in Transit: TLS for network communication (outside CleanStart)
4. Access Controls: RBAC at Kubernetes and application level (outside CleanStart)
5. Audit Logging: Application logs showing who accessed what ePHI (outside CleanStart)
6. Data Minimization: Store only necessary ePHI; delete when no longer needed (outside CleanStart)

CleanStart's Role: Supporting These Requirements

Audit Verification Checklist

CISOs: Use This for Self-Assessment

[ ] Signed Images: All production images verified with cosign verify before deployment [ ] SBOM Retention: SBOMs exported and archived for every image deployed in past 6 years [ ] Audit Logs: Registry logs exported to immutable storage; retention ≥6 years [ ] Access Control: All image pulls associated with named user/service account; MFA for administrators [ ] Vulnerability Management: SBOM scanned against NVD quarterly; no high/critical CVEs in prod [ ] BAA in Place: CleanStart BAA signed and maintained [ ] Subcontractor Assessment: Vendors (AWS, GitHub, DataDog) have HIPAA compliance documentation [ ] Incident Response: Playbook documents process for responding to image tampering/breach

Auditors: Verification Procedures

Procedure 1: Verify Image Signing

Objective: Confirm all production images are signed and tampering would be detected

Steps:

1. List all images deployed in production: kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u
2. For each CleanStart image, verify signature: cosign verify --key https://keys.cleanstart.com/prod.pub registry.cleanstart.com/image:tag
3. Expected result: Signature valid; output shows attestation details

Documentation: Screenshot of successful signature verification for sample of images

Procedure 2: Audit Log Review

Objective: Confirm image pulls are logged and logs are retained

Steps:

1. Export logs for sample month (e.g., March 2026): gcloud logging read "resource.type=api AND resource.labels.service_name=containerregistry" \ --filter='timestamp>="2026-03-01" AND timestamp<"2026-04-01"' \ --limit=unlimited > march-logs.json
2. Review for: Image pull operations (method="GET" path="/v2/*/manifests") Actor identification (protoPayload.authenticationInfo.principalEmail) Timestamp (protoPayload.requestMetadata.requestTimestamp)
3. Spot-check 5+ entries for completeness
4. Verify retention policy: gcloud logging buckets describe _Default --location=us-central1 Expected: retentionDays: 2555 (≥6 years)

Documentation: Sample log entries; retention policy screenshot

Procedure 3: SBOM Validation

Objective: Confirm SBOMs are generated and accessible for forensic analysis

Steps:

1. Select 3 production images
2. Download SBOM: cosign download sbom registry.cleanstart.com/image:tag > sbom.json
3. Validate SBOM format (SPDX 3.0 or CycloneDX 1.4): jq '.format' sbom.json # Should output "CycloneDX" or "SPDX" jq '.components | length' sbom.json # Count components
4. Verify CVE status: jq '.components[] | select(.vulnerabilities != null) | .name' sbom.json Expected: No vulnerabilities for production images

Documentation: Sample SBOMs; component counts; vulnerability scan results

Procedure 4: Access Control Verification

Objective: Confirm only authorized users/service accounts can pull images

Steps:

1. Query image pull audit logs for past 30 days
2. Identify unique actors (service accounts, human users)
3. Verify each actor is documented in access control policy: kubectl describe rolebindings -A | grep image-puller
4. Verify MFA for any human users with image pull rights: Check Okta enrollment records Confirm TOTP or WebAuthn enabled

Documentation: List of authorized actors; RBAC policy; MFA enrollment

Audit-Ready Compliance Export

Monthly Compliance Report (Automated)

CleanStart can generate monthly report including:

# 1. Uptime SLAecho "Infrastructure Uptime: 99.97% (exceeds 99.95% SLA)" # 2. Security Scanning Summaryecho "Critical CVEs in Prod: 0 (scanned: March 22, 2026)" # 3. Audit Log Exportgcloud logging read "resource.type=api" --limit=unlimited --format=json > audit-2026-03.jsonecho "Audit Log Entries: 12,847" # 4. SBOM Inventorygsutil ls gs://compliance-sboms/2026-03/ | wc -lecho "SBOMs Archived: 127" # 5. BAA Statusecho "Business Associate Agreement: Signed and Current" # 6. Incident Summaryecho "P1 Incidents: 0"echo "P2 Incidents: 1 (resolved within SLA)"

Delivery: Emailed to compliance officer on 5th business day of month

Additional Resources

HIPAA Security Rule (45 CFR Part 164 Subpart C) HIPAA Breach Notification Rule HHS Guidance on HIPAA Compliance OCR Security Risk Assessment Tool SLSA Framework in-toto Attestation Format

Compliance Contact: compliance@cleanstart.com Last Updated: 2026-03-22 Next Review: 2027-03-22 | Log protection | Audit logs signed and immutable in Cloud Audit Logs | Attempt to modify log entry; Cloud Logging should reject edit | | Log review | SIEM integration enables real-time alerting on suspicious activity | Configure alerts on failed authentication, unauthorized image push |

How CleanStart Helps: Audit logs provide an immutable record of who pulled which images when. Signed provenance attestations prove images weren't modified after creation. Together, these create a complete chain of custody suitable for HIPAA audits.

164.312(c): Integrity Control

Requirement: Protect ePHI from improper alteration or destruction.

How CleanStart Helps: SBOMs in SPDX 3.0 format enumerate every software component in the image with versions and known vulnerabilities. If a vulnerability is disclosed, the SBOM immediately identifies which deployed images are affected. VEX documents provide trusted statements about whether vulnerabilities impact the image.

164.312(d): Transmission Security

Requirement: Protect ePHI during transmission.

§164.314: Organizational Requirements

164.314(a): Business Associate Agreements

§164.316: Policies and Documentation

164.316(a): Policies and Procedures

Requirement: Establish written policies and procedures.

164.316(b): Documentation Requirements

Compliance Evidence Artifacts

CleanStart container images produce three key artifacts for HIPAA compliance:

Software Bill of Materials (SBOM)

Format: SPDX 3.0 and CycloneDX 1.4

{  "bomFormat": "CycloneDX",  "specVersion": "1.4",  "version": 1,  "components": [    {      "type": "library",      "name": "glibc",      "version": "2.38-13",      "purl": "pkg:apk/alpine/glibc@2.38-13",      "hashes": [{"alg": "SHA-256", "content": "..."}],      "vulnerabilities": []    }  ]}

HIPAA Relevance: Enumerates all software in the image, enabling rapid vulnerability assessment. If a CVE is disclosed, the SBOM immediately identifies affected deployed images.

SLSA Provenance

Format: SLSA Framework v1.0

{  "_type": "https://slsa.dev/provenance/v1",  "subject": [    {      "name": "registry.cleanstart.com/app:v1.0.0",      "digest": {"sha256": "..."}    }  ],  "predicate": {    "buildDefinition": {      "buildType": "https://slsa.dev/build/v1/docker",      "externalParameters": {        "dockerfile": "distroless.Dockerfile"      },      "internalParameters": {        "builderId": "projects/cleanstart-build/locations/us-central1/builders/main"      }    }  }}

HIPAA Relevance: Documents who built the image, when, with which source code, using which build system. Enables audit of build process integrity and traceability to source commits.

Vulnerability Exploitability eXchange (VEX)

Format: CycloneDX VEX

{  "bomFormat": "CycloneDX",  "specVersion": "1.4",  "version": 1,  "vulnerabilities": [    {      "ref": "bom-component-1",      "vulnerability": {        "ref": "CVE-2024-1234",        "ratings": [{"score": 7.5}]      },      "analysis": {        "state": "not_affected",        "justification": "component_not_present"      }    }  ]}

HIPAA Relevance: Provides trusted statements about whether known vulnerabilities actually affect the image. Prevents false positives from vulnerability scanners, reducing compliance noise.

Audit Walkthrough

A typical HIPAA audit of container image compliance proceeds as follows:

Step 1: Retrieve Image Metadata

# Pull imagedocker pull registry.cleanstart.com/app:v1.0.0 # Retrieve attestationscosign verify registry.cleanstart.com/app:v1.0.0 # Extract SBOMcosign verify-attestation --attestation-type cyclonedx \  registry.cleanstart.com/app:v1.0.0 | jq -r '.payload | @base64d'

Step 2: Verify Image Integrity

# Verify signaturecosign verify \  --certificate-identity-regexp "build.cleanstart.com" \  --certificate-oidc-issuer https://oidc.cleanstart.com \  registry.cleanstart.com/app:v1.0.0 # Verify SBOM attestationcosign verify-attestation \  --type cyclonedx \  registry.cleanstart.com/app:v1.0.0

Step 3: Check Vulnerability Status

# Extract SBOMSBOM=$(cosign verify-attestation --attestation-type cyclonedx \  registry.cleanstart.com/app:v1.0.0 | jq -r '.payload | @base64d') # Parse components and check NVDecho "$SBOM" | jq '.components[] | {name, version}' | while read line; do  # Cross-reference against NVD/GHSA  # Document any findingsdone # Check VEX statement for exceptionscosign verify-attestation --attestation-type vuln \  registry.cleanstart.com/app:v1.0.0

Step 4: Review Deployment Audit Logs

# Export image pull logsgcloud logging read \  'resource.type="api" AND   protoPayload.serviceName="containerregistry.googleapis.com" AND   protoPayload.methodName="storage.objects.get"' \  --format=json \  --limit 1000 | jq '.[] | {timestamp, principalEmail, request}' # Correlate with Kubernetes auditkubectl get events -A --sort-by='.lastTimestamp' | grep image

Step 5: Document Security Controls

Create compliance evidence report:

Image Provenance: SLSA v1 attestation with build environment, builder identity, materials Image Integrity: cosign signature verification passes Software Inventory: SBOM lists all components with versions Vulnerability Status: No known critical/high CVEs; VEX documents exceptions Access Control: Registry audit logs show only authorized users pulled image Encryption: All transmission over TLS; images stored encrypted Runtime Security: Container runs non-root (UID 65532); root filesystem read-only Audit Trail: Immutable logs in Cloud Audit Logs with 6-year retention

Key Control Mappings

The following table maps each major HIPAA control area to CleanStart capabilities:

Deployment Checklist for HIPAA Compliance

Before deploying images processing ePHI, verify:

[ ] All images signed with cosign using FIPS 140-3 keys [ ] SBOM present and validated (no critical vulnerabilities) [ ] VEX statement present for known CVEs [ ] SLSA provenance v1.0 with complete build information [ ] Registry authentication configured with audit logging enabled [ ] Kubernetes imagePullSecrets configured with service account [ ] Pod SecurityPolicy enforces non-root UID 65532 [ ] Read-only root filesystem enforced via securityContext [ ] Container images from registry.cleanstart.com only [ ] Registry audit logs archived to immutable storage [ ] SIEM integration enabled for real-time alerts [ ] Quarterly SBOM reviews scheduled [ ] Annual audit procedures documented

Continuous Compliance Monitoring

Maintain compliance through ongoing monitoring:

Monthly: Review registry audit logs for unauthorized access Scan SBOMs against latest NVD/GHSA data Update VEX documents for newly disclosed CVEs

Quarterly: Rotate API keys and signing keys Review Kubernetes RBAC policies Audit image registry usage by team

Annually: Full gap analysis against HIPAA Security Rule Third-party vulnerability assessment Update policies based on new guidance

References

HIPAA Security Rule, 45 CFR §§ 164.308, 164.310, 164.312, 164.314, 164.316 SLSA Framework: Supply chain Levels for Software Artifacts SPDX Specification 3.0 CycloneDX Specification 1.4 Cosign: Container Image Signing and Verification FIPS 140-3 Validated Cryptographic Modules