ORAS

ORAS leverages the Open Container Initiative (OCI) Distribution Specification to manage non-container artifacts. This means you can store model weights, SBOMs, Helm charts, and WASM modules in any standard container registry. By using the same infrastructure for all artifacts, teams eliminate the need for separate storage silos and unify their supply chain tooling. The tool handles the packaging of arbitrary files into OCI-compliant manifests and layers, ensuring compatibility with existing registry authentication and authorization mechanisms.

Every artifact pushed with ORAS is identified by a cryptographic digest (SHA-256), not just a mutable tag. This provides content-addressable storage, where the address of the artifact is derived from its content. Key benefits include:

• Tamper-proofing: Any alteration to the artifact changes its digest, immediately breaking references.
• Deduplication: Registries automatically deduplicate identical layers across artifacts, saving storage.
• Reproducibility: A specific digest always resolves to the exact same bytes, enabling deterministic deployments and audit trails.

ORAS implements the OCI Referrers API, which allows you to establish typed relationships between artifacts. For example, you can attach an SBOM, a vulnerability scan result, or a Cosign signature directly to a model artifact in the registry. This creates a queryable graph of supply chain metadata. A user can discover all attestations and related objects for a given model digest without needing a separate metadata database, enabling in-registry provenance tracking.

ORAS provides powerful commands for moving artifacts between registries without local storage. The oras copy command performs a registry-to-registry transfer, pulling manifests and blobs from a source and pushing them to a destination. This is critical for:

• Air-gapped deployments: Copying verified models from an internet-connected staging registry to a disconnected production registry.
• Promotion workflows: Moving an artifact from a development registry to a production registry after passing all policy checks.
• Mirroring: Replicating artifacts across geographically distributed registries for low-latency access.

ORAS is available as both a command-line interface (CLI) and a Go library. The CLI is designed for human operators and CI/CD pipelines, offering intuitive commands like oras push, oras pull, oras attach, and oras discover. The Go library allows developers to embed OCI artifact management directly into custom tools and platforms. This dual approach means infrastructure teams can script artifact workflows while platform engineers build native registry interactions into their MLOps and DevSecOps systems.

ORAS serves as the foundational transport layer for Sigstore and SLSA compliance in AI supply chains. When combined with Cosign, artifacts pushed via ORAS can be keylessly signed using workload identities. The resulting signatures are stored as referrer artifacts alongside the original content. This enables:

• Deploy-time verification: Admission controllers can verify signatures before allowing a model to be loaded.
• Non-repudiation: The signing identity is recorded in the Rekor transparency log, providing undeniable proof of origin.
• Policy enforcement: Tools like Open Policy Agent (OPA) can query the referrer graph to enforce that only models with verified SBOMs and passing scan results are deployed.

An extension of the SBOM concept to machine learning, cataloging every component of a model's supply chain. An MBOM stored as an OCI Artifact via ORAS includes:

• Training dataset identifiers and provenance
• Preprocessing code and hyperparameters
• Model architecture and framework dependencies
• Evaluation results and fairness metrics ORAS enables pushing an MBOM alongside model weights to the same registry, creating a single source of truth for auditors.

A cryptographically signed statement asserting a verifiable fact about a software artifact. In the ORAS context, attestations are stored as separate OCI Artifacts linked to a model manifest. Common attestation types include:

• Provenance attestations: who built the model, when, and from what source
• Vulnerability scan attestations: results of security scanning
• Test result attestations: evaluation metrics and benchmark scores ORAS enables pulling these attestations alongside model weights for automated policy enforcement.

A registry feature preventing a specific tag from being overwritten. When combined with ORAS workflows, immutable tags ensure that a reference like my-model:v1.0 always resolves to the exact same content digest. This property is critical for:

• Reproducible deployments: the same tag always pulls identical weights
• Audit compliance: no possibility of silent model swapping
• Supply chain integrity: prevents an attacker from replacing a benign model with a backdoored version under the same tag

A security mechanism using digital signatures to verify both the integrity and publisher of an artifact. ORAS integrates with Docker Content Trust and Sigstore to enable:

• Publisher verification: confirming a model came from an authorized team
• Integrity verification: detecting any tampering since signing
• Policy enforcement: registries or admission controllers can reject unsigned models This is the foundational security primitive that transforms a container registry into a trusted model distribution channel.