Auditors are asking questions you can't answer with standard AI containers. They want to know: What code ran during the build? What vulnerabilities exist in your dependencies? Can you prove the image wasn't tampered with? Which version of your AI model is actually running in production?

EU AI Act Article 9 mandates risk documentation. NIST AI RMF demands artifact trails. Singapore's IM8 requires cryptographic proof of control. Your container is the only artifact that travels from development through production—and it must carry the evidence with it.

Standard AI containers hide their origins. Source code is missing. SBOMs are afterthoughts. Attestations don't exist. Auditors see a black box and fail the assessment.

CleanStart AI containers embed compliance evidence directly into the image, making audits verifiable, reproducible, and fast.

EU AI Act: Article-by-Article Container Evidence

The EU AI Act (2024) requires AI system documentation for high-risk applications. Your container is the deployment unit—it must satisfy the Act's core requirements.

Article 9: Risk Management System

Risk assessments require comprehensive documentation. EU AI Act Article 9 demands documentation of known vulnerabilities in AI system components, dependency versions and their security posture, build reproducibility for regression testing, and change history with approval chains.

Container Evidence for Article 9:

The SBOM (Software Bill of Materials) lists all 1,200+ base OS packages, Python libraries, ML frameworks, and AI model weights, providing a comprehensive inventory for vulnerability mapping and compliance auditing. Provenance attestations deliver SLSA L3+ proof that the image was built from a specific commit, signed by CI/CD systems with full approval chains documented. Dependency freezing through version-pinned base images, frozen OS packages, and pinned ML library versions ensures reproducibility and prevents undocumented dependency updates. Embedded vulnerability scan reports show the count of known vulnerabilities at build time, with clear remediation paths for any flagged issues.

CleanStart Implementation:

You can extract SBOM from image using cosign attach sbom registry.cleanstart.com/ai-container:v1.2.3. You can verify the provenance chain using cosign verify-attestation --attestation slsaprovenance registry.cleanstart.com/ai-container:v1.2.3.

Risk assessments now have artifact-level proof. Auditors see: "On 2025-03-22, we built image v1.2.3 from commit abc1234def, with 47 transitive dependencies, zero critical vulnerabilities."

Article 10: Data and Data Governance

AI systems require governance of training, validation, and test data. The EU AI Act Article 10 demands documentation of data provenance, quality checks, and bias mitigation. Your container often includes pre-trained model weights for inference, feature engineering logic for data pipelines, and bias detection code for governance.

Container Evidence for Article 10:

Model attestations provide metadata proving which model weights, versions, and training data were used in the deployed system. Data governance labels extend the SBOM with documentation of data source, version, and quality checks applied. Code provenance captures a source code snapshot proving that governance code was reviewed and approved before containerization.

CleanStart Approach:

Model metadata is stored as OCI image annotations. Example annotations include org.cleanstart.model.name=vision-classifier-v2, org.cleanstart.model.trained-date=2025-02-15, org.cleanstart.model.training-data-version=prod-feb-2025, org.cleanstart.bias-scan.date=2025-03-20, org.cleanstart.bias-scan.status=passed.

Article 15: Accuracy, Robustness, and Cybersecurity

The requirement states that "High-risk AI systems shall be designed and developed in a manner that ensures appropriate levels of accuracy, robustness and cybersecurity." This requires evidence that the deployed container matches the tested and approved version, no package downgrades or known-vulnerable versions are present, and the build process itself was secure with no unauthorized modifications.

Container Evidence for Article 15:

Reproducible builds ensure that the same source commit plus build timestamp always produces the same image hash, creating bit-for-bit identical outputs that prove the deployed version matches the tested version. Signed attestations deliver SLSA L3 proof that the image came from the approved CI/CD system, not a rogue build or manual intervention. Version integrity guarantees no runtime patching, with all versions frozen at build time to prevent undocumented changes. Security scanning through SBOMs proves zero critical vulnerabilities at deployment time.

CleanStart Guarantee:

Build the same source commit twice and get an identical image digest. AI regulators require proof that the model running in production is the one that passed testing.

Article 17: Quality Management System

Ongoing monitoring and documentation of AI system performance is required, including model drift, data distribution shift, and security posture, ensuring systems remain compliant over time.

Container Evidence for Article 17:

Build metadata including build date, CI/CD system ID, and approval sign-offs creates an audit trail of the deployment. Continuous vulnerability tracking allows images to be re-scanned against updated vulnerability databases without rebuild, catching emerging threats. Audit logs prove which container version ran, when, and for how long, creating verifiable records of production deployments. Incident response records enable tracing which production deployments are affected if a vulnerability is discovered.

NIST AI Risk Management Framework: Mapping Container Controls

NIST AI RMF (January 2023) defines four core functions. Your container is where governance, mapping, measurement, and management become auditable.

GOVERN: Define AI Risk Policies and Container Governance

NIST GOVERN function requires policies for AI system procurement, deployment, and oversight. Container-level controls translate these policies into enforceable technical requirements.

Container-Level Controls:

Image signing policies require all AI containers to be signed by approved CI/CD systems, creating cryptographic identity. Registry access control restricts deployments to only approved registries like registry.cleanstart.com, preventing pull-from-anywhere scenarios. Admission control through Kubernetes or orchestration policies blocks unsigned or unscanned images before they reach production. Immutable tag enforcement in production uses digest-based references instead of floating tags like "latest", preventing tag reassignment attacks.

CleanStart Enablement:

You can enforce policy by creating a ValidatingWebhookConfiguration for Kubernetes that only allows signed images from trusted registries. You can sign AI container with CleanStart keyring using the cosign sign command with Cloud KMS key.

MAP: Understand AI System Components and Dependencies

NIST MAP function requires understanding what's inside your AI system, including models, training data, and dependencies.

Container Artifacts for Mapping:

The SBOM provides a complete bill of materials with all 1,200+ transitive dependencies listed in SPDX or CycloneDX format. Model provenance documents which models, versions, and training data versions are embedded in the container. Source code snapshots prove what code was reviewed before container build, creating auditability. External dependencies documentation lists which ML frameworks like TensorFlow or PyTorch, inference engines, and external APIs are called.

CleanStart SBOM Integration:

You can attach SBOM to image using cosign attach sbom --sbom sbom.spdx.json registry.cleanstart.com/ai-container:v1.2.3. You can extract and verify SBOM using cosign download sbom registry.cleanstart.com/ai-container:v1.2.3 | jq '.components | length', which outputs 1247 (all transitive dependencies listed).

MEASURE: Continuous Monitoring and Measurement

NIST MEASURE requires ongoing assessment of AI system performance, including security, accuracy, and fairness.

Container-Based Measurement:

Vulnerability scanning checks the SBOM against latest vulnerability databases from NVD, GHSA, and security advisories, enabling quick detection of new threats. Model performance tracking includes container annotations with model version, baseline accuracy, and acceptable drift thresholds. Runtime telemetry incorporates minimal instrumentation for audit trails capturing request count, error rate, and inference time. Continuous compliance re-scans images monthly to detect emerging vulnerabilities without requiring rebuilds.

Scan Example:

You can scan container against current vulnerability database using trivy image --format json registry.cleanstart.com/ai-container:v1.2.3 | jq '.Results[] | select(.Severity=="CRITICAL")', showing critical vulnerabilities: 0. You can generate compliance report for NIST MEASURE using sbom-reporter --sbom sbom.spdx.json --format nist-ai-rmf > report.json.

MANAGE: Risk Response and Incident Management

NIST MANAGE requires processes to respond to identified risks, update AI systems, and manage incidents.

Container Artifact Trails for Management:

Patch SLAs documented in container metadata specify how quickly critical vulnerabilities must be patched. Rollback capability through image digest immutability ensures any version can be instantly restored. Incident timeline reconstruction from container logs proves which version was running during the incident. Change approval records stored in image annotations create a complete lineage of each release.

IM8 (Singapore) Requirements for AI Containers

Singapore's Information Technology (Governance) Act IM8 requirements for AI in government systems demand cryptographic proof of control, source transparency, and non-repudiation.

Source Code Transparency Requirement

IM8 mandates proof that AI system source code was reviewed and approved before deployment. Container evidence includes source provenance linking the container attestation to the specific source commit with CI/CD-signed proof. Code review records reference approval tickets and reviewers in image annotations. Build-from-source-only policies ensure no pre-built binaries, with all components compiled from reviewed source.

CleanStart Compliance:

You can verify source commit for deployed container using cosign verify-attestation --attestation slsaprovenance registry.cleanstart.com/ai-container:v1.2.3 | jq '.materials.resolvedDependencies[].name, .materials.environment'.

The output proves: built from commit abc123 on 2025-03-22, reviewed by JIRA ticket CLEAN-8501, approved by security-team.

Cryptographic Identity and Non-Repudiation

IM8 requires cryptographic proof that the container came from the approved system and hasn't been modified. Enforcement through private key signing uses HSM-backed private keys with no shared credentials, creating non-repudiation. Attestation chains deliver SLSA L4 attestations proving the container was built, scanned, and approved without manual intervention. Signature verification on all deployments checks signatures against public keys before launch. Tamper detection ensures image digests change immediately if any layer is modified.

Implementation:

You can create SLSA L4 attestation (HSM-backed) using slsa-github-generator build --image-name registry.cleanstart.com/ai-container. You can verify signature and attestation before deployment using cosign verify --certificate-identity-regexp '.*@github.com/cleanstart-security' --certificate-oidc-issuer https://token.actions.githubusercontent.com registry.cleanstart.com/ai-container@sha256:abc123....

Access Control and Least Privilege

IM8 mandates that containers run with minimal permissions. CleanStart AI container defaults enforce non-root execution as UID 65532 (unprivileged user nobody), removing any shell from the image (no /bin/sh or /bin/bash access), mounting application layers read-only with only /tmp writable, dropping all Linux capabilities with none added back, and preventing volume mounts to host filesystem—only named volumes with explicit bind mounts allowed.

Kubernetes Enforcement:

Pod security context configuration specifies runAsNonRoot: true, runAsUser: 65532, fsReadOnlyRootFilesystem: true, allowPrivilegeEscalation: false, dropping all capabilities with none added back. Volume mounts include temporary directory at /tmp and read-only cache at /model-cache. Volumes include emptyDir for temp and configMap for model-weights.

Audit Trail and Non-Repudiation

IM8 mandates comprehensive audit logs proving who deployed what, when, and with what approval. Container-based audit uses immutable metadata in image annotations to store deployment approvals, timestamps, and approver identity. Signed deployments through Kyverno or similar policy engines sign all deployment YAML with logs proving the approval chain. Runtime auditing includes container logs with request count, inference latency, and error events. Incident timeline reconstruction combines image digest and container logs to prove which exact version was running during any incident.

CIS Benchmark Compliance for AI Containers

The Center for Internet Security publishes Docker and Kubernetes benchmarks. CleanStart AI containers meet CIS Level 1 and 2 controls by default.

CIS Docker 1.6.0 Compliance

CleanStart images meet the requirements: Image from trusted source with cosign signature required, Image scanning enabled with Trivy scan at build, Content trust for image with SLSA L3+ attestation, Image with no FROM as multi-stage with pinned base, Filesystem read-only by default, Privileged container dropped all capabilities, Restrict kernel capabilities all dropped and none added, Run as non-root UID 65532 (nobody), and No shell access in image.

CIS Kubernetes 1.28 Compliance

CleanStart pod configurations meet the requirements: Enforce security policy with PodSecurityStandard: restricted, Minimize admission of untrusted images with registry whitelist enforced, Image pulling disabled with imagePullPolicy: IfNotPresent, Limit service account permissions with minimal RBAC role, Non-root container with runAsNonRoot: true, Root filesystem read-only with fsReadOnlyRootFilesystem: true, Restrict container syscalls with seccomp profile applied, and Limit resource allocation with CPU/memory limits set.

Generating Compliance Reports

Compliance audits require artifact evidence. CleanStart makes evidence generation automated and verifiable.

Extract SBOM from Deployed Image

You can retrieve SBOM from image in registry using cosign download sbom registry.cleanstart.com/ai-container:v1.2.3 > sbom.spdx.json. You can count dependencies using jq '.components | length' sbom.spdx.json, outputting 1247. You can filter to specific package types (Python, Java, C libraries) using jq '.components[] | select(.type=="library") | .name' sbom.spdx.json.

Verify SLSA Attestation

You can download and verify SLSA L3 provenance using cosign verify-attestation --attestation slsaprovenance registry.cleanstart.com/ai-container:v1.2.3 | jq '.predicate.materials'.

The output shows source commit hash and URL, build timestamp, approved builder identity, and no manual intervention.

Generate Compliance Matrix

You can perform multi-framework compliance check with a shell script that validates EU AI Act Article 9 (Risk Management), NIST AI RMF: MAP function (Understand Components), IM8: Cryptographic identity (Non-Repudiation), and CIS Kubernetes: Pod Configuration.

The script generates verification results including SBOM present with dependencies listed, provenance source-built and signed by CI/CD, no critical vulnerabilities detected, and signature verified as signed by approved CI/CD system.

Create Audit-Ready Evidence Package

You can automate evidence collection for auditors with a comprehensive script that generates image metadata, collects SBOM, retrieves SLSA Provenance, scans for vulnerabilities with Trivy, verifies signature, generates CIS compliance report, and creates summary report.

The script outputs a compliance evidence directory containing image-metadata.json, sbom.spdx.json, slsa-provenance.json, vulnerability-scan.sarif, critical-vulnerabilities.json, signature-verification.txt, cis-compliance.md, and README.md explaining the regulatory frameworks covered and files included.

Compliance Comparison: Standard vs CleanStart AI Containers

CleanStart AI containers exceed standard containers across all major regulatory frameworks. EU AI Act Article 9 requires SBOM—standard containers have none absent while CleanStart containers include SPDX SBOM with 1,247+ dependencies. EU AI Act Article 10 requires data governance proof—standard containers have none absent while CleanStart containers include model metadata annotations with training data version. EU AI Act Article 15 requires version traceability—standard versions float and are untraceable while CleanStart uses reproducible builds with SLSA attestation. EU AI Act Article 17 requires quality monitoring—standard containers have no quality monitoring while CleanStart offers continuous vulnerability rescanning with model drift annotations.

NIST GOVERN requires image signing—standard images are unsigned while CleanStart requires cosign signature with registry whitelist enforced. NIST MAP requires component visibility—standard containers provide no component visibility while CleanStart includes SBOM extracted from deployed image with dependency tracking. NIST MEASURE requires vulnerability assessment—standard assessment is manual vulnerability scanning while CleanStart offers automated trivy scan with rescanning alerts on new CVEs. NIST MANAGE requires incident timeline—standard timeline is unknown while CleanStart ensures image digest immutability with instant rollback capability.

IM8 Source Transparency requires build origin proof—standard containers have unknown build origin while CleanStart uses SLSA L3+ proving build from specific commit with approvals logged. IM8 Non-Repudiation requires cryptographic proof—standard containers lack cryptographic proof while CleanStart uses HSM-backed cosign signature with CI/CD identity verified. IM8 Access Control requires least privilege—standard containers may run as root while CleanStart enforces non-root UID 65532 with no shell and read-only filesystem. IM8 Audit Trail requires deployment approval history—standard containers lack approval history while CleanStart stores approvals in image annotations with logs proving lineage.

CIS Docker requirements are similarly mapped, with CleanStart meeting all Level 1 and Level 2 controls by default. CIS Kubernetes requirements are also fully met by CleanStart pod configurations.

Related Documentation

For additional compliance guidance, see ai-container-attack-surface.md for threat model of AI containers and supply chain attack vectors. See eu-ai-act-cra.md for Conformity Assessment Report requirements and documentation templates. See hipaa-compliance-mapping.md for HIPAA Technical and Administrative Safeguards for AI inference. See pci-dss-mapping.md for PCI DSS container requirements for payment processing in AI systems. See soc-2-compliance-ai.md for SOC 2 Type II controls mapped to container security posture. See sbom-generation-verification.md for technical guide to SBOM creation, validation, and consumption.

Quick Reference: Compliance Checklist

Before deploying any AI container to production:

Ensure SBOM is extracted and validated (no unknown dependencies), SLSA L3+ provenance attestation is signed by CI/CD system, image is signed with cosign and signature is verified before deployment, vulnerability scan shows zero critical/high-severity issues, container runs as non-root user (UID 65532), filesystem is read-only at runtime, no shell (/bin/bash, /bin/sh) present in image, all Linux capabilities dropped, pod security policy is enforced (Kubernetes restricted profile), registry whitelist is configured (only registry.cleanstart.com allowed), deployment approval chain is documented in image annotations, and audit logs are configured to capture image version, deployment time, and approver.

Audit evidence to collect:

Use cosign download sbom CONTAINER_IMAGE > sbom.json to collect SBOM. Use cosign verify-attestation --attestation slsaprovenance CONTAINER_IMAGE > provenance.json to collect provenance. Use cosign verify CONTAINER_IMAGE to verify signature. Use trivy image CONTAINER_IMAGE to scan for vulnerabilities. Use docker inspect CONTAINER_IMAGE | jq '.Config.User' to verify user context.

Last Updated: 2025-03-22 Framework Versions: EU AI Act 2024, NIST AI RMF January 2023, CIS Docker 1.6.0, CIS Kubernetes 1.28