Skip to content

compliance-mapping.md

Latest commit

 

History

History
128 lines (91 loc) · 8.22 KB

compliance-mapping.md

File metadata and controls

128 lines (91 loc) · 8.22 KB
Raw

Compliance Mapping

Maps each trust control plane layer to the regulatory clauses it satisfies. Intended for audit preparation and evidence packaging.

The lab produces verifiable, reproducible evidence for each control listed below. Evidence artifacts are generated by the supply chain gate (supply-chain-gate.yml) and the enforcement layer (analyze-drift.py, audit-fleet.sh).

Control Summary

Control Layer Evidence artifact
Image integrity verification Trust Kyverno admission log, cosign verify output
Software Bill of Materials Supply Chain CycloneDX SBOM (cosign attest)
Vulnerability disclosure Supply Chain + Enforcement grype attestation, audit-fleet.sh report
Provenance attestation Supply Chain SLSA provenance (supply-chain-gate.yml)
Drift detection Enforcement analyze-drift.py output
Admission enforcement Trust Kyverno policy audit log
Break-glass access control Trust break-glass-exception.yaml + audit trail

HIPAA — Security Rule

Relevant standard: 45 CFR §164.312 — Technical Safeguards

Clause Requirement Lab control Evidence
§164.312(a)(1) Access control — unique user identification Keyless signing ties image origin to a specific OIDC identity (GitHub Actions workflow or vendor pipeline) cosign verify output showing subject + issuer
§164.312(b) Audit controls — record activity on systems containing ePHI Kyverno admission logs record every deploy attempt (admitted and rejected) with image reference, namespace, timestamp Kyverno audit log via kubectl get events or SIEM integration
§164.312(c)(1) Integrity — protect ePHI from improper alteration Cosign signature pins the image to a specific digest; drift detection flags any post-admission digest change analyze-drift.py Drift column
§164.312(e)(2)(ii) Encryption and decryption SBOM attestation documents what cryptographic libraries are present and their versions CycloneDX SBOM artifact

PCI DSS v4.0

Relevant requirements: Requirement 6 (Secure Systems and Software) and Requirement 11 (Test Security)

Requirement Description Lab control Evidence
6.3.3 All software components protected from known vulnerabilities grype vulnerability scan attested at build time; audit-fleet.sh runs continuous post-deployment scan grype attestation artifact, audit-fleet.sh report
6.4.1 Public-facing web apps protected against known attacks Admission policy rejects images without verified provenance; unsigned images cannot reach production Kyverno admission rejection log
6.5.1 Manage all payment software components SBOM documents every package in every image; SBOM delta tool (tools/generate-sbom-delta.sh) shows exactly what was added on top of the base CycloneDX SBOM + SBOM delta report
11.3.1 Internal vulnerability scans performed audit-fleet.sh runs scanner-driven vulnerability inventory across the fleet on schedule audit-fleet.sh CronJob output

SOC 2 Type II

Relevant Trust Service Criteria: CC6 (Logical and Physical Access) and CC7 (System Operations)

Criterion Description Lab control Evidence
CC6.1 Logical access security measures Kyverno require-signature enforces that only images from approved signing identities can run Kyverno ClusterPolicy + admission log
CC6.2 Prior to issuing system credentials, entity registers and authorizes new internal and external users Signing identity (subject + issuer) is the credential; policy explicitly allow-lists approved identities require-signature.yaml identity matcher
CC6.8 Entity implements controls to prevent or detect and act upon the introduction of unauthorized software require-trusted-registry restricts image sources; require-signature rejects unsigned images Policy manifests + admission rejection log
CC7.1 Detect and monitor for new vulnerabilities audit-fleet.sh continuously surfaces CVE findings by workload and team; findings route to owners via Kubernetes events audit-fleet.sh output, CronJob manifest
CC7.2 Monitor system components for anomalous behavior analyze-drift.py detects digest drift, unsigned workloads, and SBOM-absent images post-admission analyze-drift.py output

FDA 21 CFR Part 11 — Electronic Records

Relevant clauses: Subpart B (Electronic Records)

Clause Requirement Lab control Evidence
§11.10(a) System validation — accurate and reliable operation Lab includes five hypothesis-driven experiments (E1–E5) with documented expected vs. actual outcomes Experiment READMEs, output/ directories
§11.10(b) Ability to generate accurate copies of records All artifacts (signatures, SBOMs, attestations) are content-addressed OCI objects stored in the registry; reproducible by digest Registry manifest + cosign download
§11.10(c) Record protection — protect electronic records throughout retention Cosign signatures stored in Rekor transparency log (append-only, tamper-evident) Rekor log entry (cosign verify --rekor-url)
§11.10(e) Audit trail — secure, computer-generated, time-stamped audit trail Kyverno admission logs + Rekor transparency log entries provide time-stamped, immutable record of every deployment Kyverno event log + Rekor entries
§11.10(k) Device checks — use of appropriate controls over use of devices require-trusted-registry constrains which registries workloads may pull from require-trusted-registry.yaml

NIST SP 800-190 — Application Container Security

Relevant sections: Section 4 (Countermeasures)

Section Countermeasure Lab control Evidence
4.1.1 Use container-specific OS and images DHI base (dhi.io/python:3.13) is a distroless, minimal runtime — no shell, no package manager Dockerfile in experiments/E4-supply-chain-gates/examples/sample-app/
4.1.2 Image provenance and integrity Cosign keyless signing + SLSA provenance attestation document build origin and environment supply-chain-gate.yml, cosign verify output
4.1.3 Avoid including unnecessary components SBOM delta tool shows exactly what the application adds on top of the base; nothing else tools/generate-sbom-delta.sh output
4.2.1 Use read-only filesystems DHI base runs as nonroot (UID 65532) with no write access to system paths Dockerfile USER directive, DHI base defaults
4.3.1 Use namespaces Experiments deploy into isolated namespaces (trust-plane-demo); require-trusted-registry is scoped per namespace Namespace manifests, policy scope
4.5.1 Vulnerability management Continuous vulnerability inventory via audit-fleet.sh; findings attributed to owning teams with patch-age tracking audit-fleet.sh output

Evidence Packaging for Audits

When preparing evidence for an audit cycle, run the following and collect the outputs:

# 1. Current policy state
kubectl get clusterpolicy -o yaml > evidence/policies-$(date +%Y%m%d).yaml

# 2. Recent admission events (last 7 days)
kubectl get events --all-namespaces \
  --field-selector reason=PolicyViolation \
  --sort-by='.lastTimestamp' > evidence/admission-events-$(date +%Y%m%d).txt

# 3. Drift audit snapshot
python3 experiments/E1-drift-observation/analyze-drift.py \
  --cluster $(kubectl config current-context) \
  --output table > evidence/drift-audit-$(date +%Y%m%d).txt

# 4. Fleet vulnerability inventory
bash tools/audit-fleet.sh > evidence/vuln-inventory-$(date +%Y%m%d).txt

# 5. Signature verification for a specific image
cosign verify \
  --certificate-identity-regexp '^https://github\.com/opscart/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  <image-ref> > evidence/sig-verify-$(date +%Y%m%d).txt

Collect into a single evidence package and attach to the audit workpaper. Each output is timestamped and reproducible.

Further Reading

  • architecture.md — how the three layers produce these controls
  • thesis.md — scope limits (what this pattern does not address)
  • runbook.md — break-glass procedures and their audit implications