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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Risk assessment | SLSA Level 4 provenance tracks build environment, builder identity, and materials | Examine slsa.framework.io/spec.v1 provenance blob |
Risk mitigation | Signed images via cosign prevent unauthorized deployment |
|
Documented policies | SBOMs in SPDX 3.0 format enumerate all software components | Extract SBOM from image attestation |
Vulnerability tracking | CycloneDX 1.4 includes known vulnerability metadata | Parse cyclonedx.xml from image attestation |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Authorization verification | API keys for registry.cleanstart.com tied to named users and audit logging | Check registry audit logs for pull events |
Credential rotation | Registry supports time-limited tokens with expiration | Review token creation timestamps and TTL |
Termination procedures | API key revocation immediately prevents image pulls | Verify key status in registry IAM |
Periodic review | Audit trails show all image access by user and timestamp | Generate quarterly access reports |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Access authorization | Kubernetes imagePullSecrets restrict image pull to service accounts | Audit RBAC policies and pull history |
Access establishment and modification | API key management controls who can deploy which images | Review registry IAM policy changes |
Access termination | Revoking keys immediately prevents future pulls | Confirm key revocation in audit trail |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Security reminders | Documentation explaining distroless, read-only FS, SLSA principles | Review training materials |
Protection from malicious software | SBOMs identify all packages; vulnerability scanning confirms no known CVEs | Scan SBOM against NVD/GHSA monthly |
Log-in monitoring | Registry logs all authentication attempts | Monitor for failed login patterns |
Password management | API key rotation practices documented | Audit key age distribution |
164.308(a)(5): Security Incident Procedures
Requirement: Establish procedures for identifying, responding to, and documenting security events.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Response and reporting | Attestations document when images were built; audit logs show deployment timestamps | Correlate incident date with image pull logs |
Mitigating damaging effects | Immutable image signature prevents deploying altered versions | Attempt to modify image layer; cosign verify should fail |
Identifying causes | Build provenance shows source commit hashes; if vulnerability found, trace back to source | Run |
Preserving evidence | Registry stores audit logs with tamper-protection; signed attestations cannot be modified | Archive logs to immutable storage (e.g., Cloud Audit Logs) |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Data backup procedures | Image registry provides immutable, versioned artifact storage | Restore container from registry tag |
Disaster recovery plan | Signed SBOMs enable rapid assessment of what to restore | Verify SBOM completeness and currency |
Emergency access procedures | Read-only filesystem prevents emergency modifications to running container | Attempt to write to / as non-root; expect EROFS |
Testing and revision | Provenance attestations confirm disaster recovery images were built by defined process | Run |
164.308(a)(7): Business Associate Contracts
Requirement: Establish contracts with business associates requiring security compliance.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Documented agreements | SBOMs and provenance serve as compliance evidence for audits | Provide third-party auditors with signed attestations |
Subcontractor compliance | Signed images with metadata enable third-party verification | Share cosign public key; allow verification without pulling |
§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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Visitor control | Provenance shows who accessed build systems; container registry controls who can pull images | Audit build system access logs |
Security awareness | Documentation on distroless design reduces attack surface from facility compromise | Review design documentation |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Workstation security | Images run as non-root UID 65532 by design; cannot execute privileged operations | Verify EUID in running container: |
Workstation use policies | SLSA provenance documents build environment; audit logs show deployment | Review usage logs in container orchestration platform |
164.310(a)(3): Workstation in and Movement of ePHI
Requirement: Manage ePHI in transit and at rest.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Security | FIPS 140-3 validated cryptography in build and signing; TLS for registry access | Verify registry enforces HTTPS; test with unencrypted HTTP (should fail) |
§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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
User identification | Registry API keys identify users; audit logs record all pulls and push attempts |
|
Emergency access procedures | Read-only filesystem prevents unauthorized modifications even in emergencies | Verify |
Encryption and decryption | Signed attestations use FIPS 140-3 algorithms; registry enforces TLS | Inspect certificate chain: |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Unique identifiers | API keys tied to named users and service accounts | Query registry IAM: |
Audit trails | Registry logs every pull request with user, timestamp, image reference | Export logs to SIEM: |
164.312(a)(2)(ii): Emergency Access Procedures
Requirement: Establish procedures to access ePHI when normal systems fail.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Procedures documented | Provenance attestations immutable; signed by build system with audit trail | Store attestations in compliance archive |
Alternative access | Read-only root filesystem prevents bypassing normal security controls | Attempt to remount root as writable; should fail or require node credentials |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Encryption during transmission | Registry connections use TLS 1.3; signed attestations prove integrity | Test: |
Encryption at rest | Images stored encrypted in registry; signing prevents tampering | Attempt to modify image layer in storage; cosign verify should fail |
Key management | Signing keys managed by build system with access controls; registry keys rotated | Review key rotation policy; check signing key age |
164.312(b): Audit Controls
Requirement: Implement mechanisms to record and examine activity.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Audit logs | Registry audit logs record all push, pull, delete operations with user, timestamp, outcome | Export and review logs monthly: |
Log retention | Archive registry logs to immutable storage with retention policy (minimum 6 years) | Verify Cloud Logging retention is set to 6+ years |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Data integrity | Signed SBOM and attestations prevent tampering; cosign verify confirms signature | Attempt to modify SBOM; |
Non-repudiation | Build system signs image with auditable private key; audit logs show who triggered build | Query audit logs: |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Encryption | Registry enforces TLS 1.3 for all connections; image pulls require HTTPS | Test: |
Certificates | Registry uses CA-signed certificates; certificate chain validated on pull | Inspect: |
Key Management | TLS certificates managed by AWS Certificate Manager; auto-renewed before expiry | Verify certificate renewal occurs >30 days before expiry |
§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 trailAuditor 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 rejectionAuditor 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 + TOTPAuditor 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 yearsAuditor 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 measuresHIPAA 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 requiredBest Practice 6: Supply Chain Risk Management
Audit Requirement: Manage business associate compliance per §164.313(a)
Subcontractor Assessment:
Subcontractor | Service | HIPAA Controls | Verification |
|---|---|---|---|
AWS | Cloud Infrastructure | Encryption at rest/in transit, access logging, incident response | Review AWS BAA + SOC 2 Type II report |
GitHub | Source Control | Access logging, encryption, audit trail | Review GitHub Enterprise security docs |
DataDog | Monitoring | Encryption of audit data, access controls | Review DataDog SOC 2 report |
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:
- ePHI Identification: Know which containers process ePHI
- Encryption at Rest: Database and file storage encrypted (outside CleanStart)
- Encryption in Transit: TLS for network communication (outside CleanStart)
- Access Controls: RBAC at Kubernetes and application level (outside CleanStart)
- Audit Logging: Application logs showing who accessed what ePHI (outside CleanStart)
- Data Minimization: Store only necessary ePHI; delete when no longer needed (outside CleanStart)
CleanStart's Role: Supporting These Requirements
Responsibility | CleanStart Support |
|---|---|
Image integrity | Signed images prove no tampering; attestations document build provenance |
Supply chain | SBOM proves all software components; CycloneDX includes CVE status |
Access controls | Kubernetes RBAC enforcement; image pull authentication logged |
Incident response | SBOM enables rapid forensic analysis if breach suspected |
Audit readiness | Pre-built compliance evidence (SBOM, attestations, logs) |
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:
- List all images deployed in production: kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u
- For each CleanStart image, verify signature: cosign verify --key https://keys.cleanstart.com/prod.pub registry.cleanstart.com/image:tag
- 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:
- 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
- Review for: Image pull operations (method="GET" path="/v2/*/manifests") Actor identification (protoPayload.authenticationInfo.principalEmail) Timestamp (protoPayload.requestMetadata.requestTimestamp)
- Spot-check 5+ entries for completeness
- 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:
- Select 3 production images
- Download SBOM: cosign download sbom registry.cleanstart.com/image:tag > sbom.json
- 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
- 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:
- Query image pull audit logs for past 30 days
- Identify unique actors (service accounts, human users)
- Verify each actor is documented in access control policy: kubectl describe rolebindings -A | grep image-puller
- 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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Mechanism to verify integrity | Images signed with cosign; VEX documents provide tamper-evident integrity metadata |
|
Protect against improper alteration | Signed SBOMs prove exact software versions; VEX documents list known vulnerabilities | Compare deployed image SBOM against baseline quarterly |
Secure deletion | Read-only filesystem prevents unauthorized deletion of audit logs or attestations | Verify logs not writable by container process |
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.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Encryption during transmission | Registry enforces HTTPS; image push/pull encrypted | Test: |
Signed attestations | Provenance and SBOM signed by build system; cosign verifies signature |
|
Secure channels | Kubernetes imagePullSecrets ensure authentication over HTTPS | Audit imagePullSecret configuration in all pods |
§164.314: Organizational Requirements
164.314(a): Business Associate Agreements
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Written agreements | Provide signed SBOMs, provenance, and audit trails as evidence of compliance | Generate compliance report from registry logs and attestations |
Compliance audit | Third parties can verify image integrity without access to private keys | Share cosign public key; allow external verification |
§164.316: Policies and Documentation
164.316(a): Policies and Procedures
Requirement: Establish written policies and procedures.
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Documented policies | SLSA provenance documents build process; SBOMs document software inventory | Create policy document referencing provenance and SBOM artifacts |
Regular review and updates | Attestation timestamps show when images were created; audit logs show when deployed | Quarterly review of image versions and SBOM updates |
Accurate and complete documentation | SBOMs are machine-readable and complete; provenance is cryptographically signed | Validate SBOM against image contents: parse cyclonedx.xml |
164.316(b): Documentation Requirements
HIPAA Control | CleanStart Evidence | Verification Method |
|---|---|---|
Creation and retention | Signed attestations stored immutably in registry; audit logs retained for 6+ years | Verify retention policies in registry configuration |
Safeguards | Attestations signed and cannot be altered; audit logs in tamper-protected Cloud Logging | Attempt to modify attestation; cosign verify should reject |
Availability for review | Registry provides audit logs and attestations on demand | Generate on-demand compliance report |
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.0Step 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.0Step 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 imageStep 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:
HIPAA Area | Control | CleanStart Evidence | Confidence |
|---|---|---|---|
Administrative | Risk Assessment | SLSA Provenance | High |
Administrative | Access Control | Registry Audit Logs | High |
Administrative | Incident Response | Signed Attestations + Logs | High |
Physical | Facility Security | Distroless Design, Read-Only FS | High |
Technical | Authentication | API Keys, Registry IAM | High |
Technical | Integrity | SBOM, VEX, cosign Signatures | High |
Technical | Encryption | FIPS 140-3, TLS, Signing Keys | High |
Technical | Audit Logs | Cloud Audit Logs, Registry Logs | High |
Organizational | BAA Compliance | Signed Evidence Artifacts | High |
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