Secure Your Software Supply Chain with OVHcloud Managed Private Registry (MPR): SBOMs, Scanning, Signing, and the Practical Path to “Trusted Images Only”

AI generated image for Secure Your Software Supply Chain with OVHcloud Managed Private Registry (MPR): SBOMs, Scanning, Signing, and the Practical Path to “Trusted Images Only”

Software supply chain security is having a moment. Unfortunately, it’s not the fun kind of moment—more like the “your CI runner just started mining crypto and it’s not even good at it” kind of moment.

In mid-February 2026, OVHcloud published a detailed walkthrough titled Secure your Software Supply Chain with OVHcloud Managed Private Registry (MPR), written by Aurélie Vache and posted on February 13, 2026. citeturn1view0

The post is essentially a hands-on guide to turning a container registry into a security control point—not just a place where images go to wait for Kubernetes to pull them at 3 a.m. It covers SBOM generation, vulnerability scanning, image signing, and tag immutability in OVHcloud’s Managed Private Registry (MPR), which is based on the CNCF Harbor project and supports OCI images and Helm charts. citeturn0search0turn1view0turn2search0

This article expands on that foundation, adds industry context (NIST, CISA, SLSA, in-toto), and tries to answer the real-world question: what does “secure your supply chain” look like on an average Tuesday when you’re shipping microservices, patching CVEs, and occasionally debating whether “latest” is a version tag or a cry for help.

Why registries became the new battleground

If you build and ship software today, you’re likely assembling it from thousands of components you didn’t write: base images, OS packages, language modules, build tools, GitHub Actions, and the occasional “tiny helper” that turns out to be a full dependency graph of its own. The supply chain is not a line—it’s a mesh network with opinions.

OVHcloud’s blog post opens with the key premise: malicious code can be introduced at multiple points—dependencies, CI, packaging, or by modifying artifacts in a registry—and the impact can cascade across many downstream projects. citeturn1view0

That framing matters because it implies something important: your container registry is no longer a dumb storage bucket. It’s a distribution hub. If it distributes the wrong thing, you scale the wrong thing.

SolarWinds and Log4Shell weren’t “one-offs”

As Aurélie Vache notes, incidents like SolarWinds and Log4Shell were not isolated, and the broader severity trend has pushed organizations to treat supply chain controls as core security work, not “nice-to-have after the release”. citeturn1view0

The modern response has converged on a handful of practical controls that work well for containers:

  • Know what’s inside your images (SBOMs).
  • Know what’s wrong with what’s inside (vulnerability scanning, plus context like VEX).
  • Know who produced it (signing + verification policy).
  • Stop “version drift” (immutability + digest pinning practices).
  • Log it all (audit trails).

MPR’s feature set maps almost comically well to that list, which is exactly the point of the product category: make the registry a gate, not a parking lot. citeturn0search0turn1view0

What OVHcloud Managed Private Registry (MPR) actually is

OVHcloud positions MPR as a fully managed private registry for storing and distributing OCI images and Helm charts, built on open-source components like Docker registry and the CNCF Harbor project. citeturn0search0

That “based on Harbor” detail is more than marketing. Harbor has become one of the most common enterprise-grade registry stacks because it bundles features teams repeatedly reinvent (poorly) around raw registries: RBAC, projects/namespaces, scanning integrations, replication, retention policies, and increasingly, OCI artifact features like SBOMs and signatures. citeturn2search0turn2search4

OVHcloud’s MPR page calls out several security primitives explicitly:

  • RBAC, namespaces, and service accounts (robot accounts).
  • Logging for traceability and compliance.
  • Automatic vulnerability analysis (Trivy is prominent in both OVHcloud and Harbor guidance).
  • Content Trust with Cosign for verification and validation of images.
  • Replication and automated deletion (retention).

All of those features are interesting; a few of them are decisive. If you can enforce “only signed images can be pulled,” your registry becomes an enforcement point that developers cannot accidentally bypass just because they’re in a hurry. citeturn0search0turn2search0

Operational reality: availability is part of security

Supply chain security controls can also become failure points. So service-level commitments matter. OVHcloud publishes a Managed Private Registry SLA (effective January 6, 2024) with monthly availability commitments that vary by plan (e.g., 99.90% or higher depending on plan). citeturn0search5

In other words: if the registry goes down, your deployments might too—and your “security controls” will be blamed for breaking production. That’s why managed offerings exist: to make the control plane someone else’s pager problem.

The core supply chain controls MPR highlights (and why they matter)

Aurélie Vache’s post is structured like a practical playbook. Let’s take the same four pillars—SBOMs, scanning, signing, immutability—and expand them into a broader “how to think about this” model.

1) SBOMs: ingredient lists for containers (finally, inside the registry)

An SBOM (Software Bill of Materials) is the “ingredients list” of an artifact: OS packages, libraries, and other components that make up what you deploy. Vache’s post explains that SBOMs help you understand image vulnerabilities and licenses. citeturn1view0

CISA and NSA (with international partners) have also emphasized SBOMs as a foundational practice for transparency and risk management in modern software, describing SBOMs as an ingredient list that helps organizations identify components and assess risk. citeturn5search1

Manual vs. automatic SBOM generation

In the OVHcloud MPR UI (Harbor-based), SBOMs can be generated manually for an image, or configured to generate automatically on push at the project level. Vache’s post notes that Harbor/MPR generates SBOMs with Trivy and outputs them in SPDX format, stored as an accessory to the image. citeturn1view0

This matches upstream Harbor’s direction: Harbor 2.11 introduced “SBOM generation and management,” including manual or automatic SBOM generation and handling them as first-class artifacts. citeturn2search4

Why registry-managed SBOMs are a big deal

Most teams can generate SBOMs in CI today. The hard part is getting SBOMs distributed, stored, and associated with the exact immutable artifact that got deployed. Registries are a natural home for this because they already manage the “artifact identity” via digests.

Also: SBOMs aren’t just for security. They show up in compliance, audits, incident response, and license governance. If you’re ever asked, “where is OpenSSL used?” you want an answer that is not, “somewhere in the Dockerfile history, probably.”

2) Vulnerability scanning: useful, noisy, essential

Vulnerability scanning is the supply chain control everyone implements first—partly because it’s tangible (“Look! Red CVEs!”) and partly because it’s easy to automate. The OVHcloud post recommends scanning to ensure images are free of known vulnerabilities, patched, and compliant with policies. citeturn1view0

OVHcloud MPR uses Trivy as the default scanner, while also allowing additional scanners to be configured. citeturn1view0turn2search0

On-push scanning, scheduled scanning, and the “CVE time machine” problem

Scanning “on push” catches issues when the image is created. But vulnerabilities are discovered later. That’s why Vache’s post also discusses scheduling scans (hourly/daily/weekly/custom) so existing images are re-evaluated as new CVEs are published. citeturn1view0

This matters more than many teams admit. Your image built last month didn’t change, but the world’s knowledge about it did. Scheduled scanning is how you close that gap.

Blocking pulls: turning scanning into policy

The most meaningful security outcome comes when scanning results affect behavior. OVHcloud MPR/Harbor can prevent vulnerable images from being pulled based on severity thresholds, effectively making the registry a gatekeeper. citeturn1view0

This is where DevSecOps gets real: developers can still build images, but production deployments can be blocked until risk is reduced or exceptions are justified.

False positives, “not exploitable,” and why VEX exists

Scanning will inevitably surface CVEs that are not actually exploitable in your context. Vache’s post highlights “exploitable vulnerabilities” and introduces VEX (Vulnerability Exploitability eXchange) as a standard to express whether a vulnerability is exploitable for a specific product/context, and notes that OpenVEX support is planned for OVHcloud MPR in the future. citeturn1view0

Even before native VEX support, Harbor provides pragmatic workarounds, such as CVE allowlists/whitelists with optional expiry. That’s not as elegant as signed VEX attestations, but it’s a real-world mechanism to prevent your “block on high severity” policy from collapsing under the weight of irrelevant CVEs. citeturn1view0

3) Signing: shifting from “I hope it’s mine” to “I can prove it’s mine”

SBOMs and scanning tell you what’s inside and what might be wrong. Signing answers a different question: who produced this artifact, and has it been tampered with?

Vache’s post recommends signing images so you can ensure they haven’t been modified and that they originate from your CI/CD pipeline. It also frames signing as protection against compromised registries and unauthorized image replacement. citeturn1view0

Cosign and Notation: two roads to “trusted artifacts”

OVHcloud MPR supports signing with Sigstore Cosign and Notation, and can enforce verification policies at the project level. citeturn1view0turn2search0turn2search7

Upstream Harbor guidance similarly recommends Cosign and Notation for OCI artifact signing and highlights that you can enforce “allow only verified images” at the project level. citeturn2search0turn2search7

OCI 1.1 referrers: why signatures and SBOMs are getting easier to manage

Modern supply chain tooling is moving toward attaching “related artifacts” (signatures, SBOMs, provenance) to an image as OCI artifacts, discovered via the Referrers API rather than weird tag conventions.

The OCI 1.1 Referrers API introduces an endpoint to fetch artifacts that reference a given digest, and includes capabilities like pagination and filtering by artifact type. One of the advantages: if a registry supports the Referrers API, you don’t need fallback tags to store signatures/SBOMs. citeturn2search3turn2search6

This is not just plumbing trivia. It’s the difference between a maintainable artifact relationship model and a “please don’t delete the mysterious tags” model.

Reality check: version mismatches and ecosystem bugs

Supply chain security tooling is powerful, but it’s also young enough to have sharp edges. Vache’s post warns that Harbor-based MPR does not currently recognize signatures generated by Cosign v3 as “verified” in the UI (the signature appears, but the green verified indicator stays red), and notes an upstream fix is expected in Harbor 2.15. citeturn1view0

This is a good reminder to treat signing enforcement as a system: registry version, client version, OCI feature support, and policy configuration all have to align. (Yes, it’s a lot. No, the attackers won’t be patient while you upgrade.)

Attesting SBOMs (and beyond)

Vache’s post also demonstrates attaching attestations (for example, an SBOM) to an image using Cosign, which is increasingly how teams package “evidence” with artifacts. citeturn1view0

This is where the supply chain story starts connecting to frameworks like SLSA and in-toto.

4) Tag immutability: the underrated control that prevents “surprise upgrades”

If you’ve ever deployed :1.0.0 and later discovered that :1.0.0 is… somehow different now… then congratulations, you’ve met mutable tags.

Vache’s post explains that by default tags are mutable, and that from a security perspective a mutable tag does not guarantee the artifact in the registry matches the artifact originally pushed for that version. It also notes an upstream OCI distribution limitation: Harbor doesn’t enforce a strict link between tag and digest, meaning tags can be reassigned and “migrate” across artifacts, leaving old artifacts tagless. citeturn1view0

Harbor and OVHcloud MPR support tag immutability rules so that once a tag is marked immutable, it can’t be overwritten or altered via push/retag/replication and cannot be deleted. Vache’s post shows configuring these rules per project, and notes a limit of 15 immutability rules per project. citeturn1view0

Immutability vs. digest pinning

Immutability is a registry control. Digest pinning is a deployment practice (Kubernetes manifests referencing @sha256:... instead of tags). They complement each other:

  • Immutability prevents “retagging attacks” and accidental overwrites.
  • Digest pinning ensures your cluster pulls the exact artifact you tested.

Most mature orgs end up using both: tags for human readability, digests for machine-level certainty.

How this fits into bigger frameworks: SSDF, SLSA, and in-toto

Security teams love frameworks. Developers love finishing tickets. The good news is: the controls discussed here aren’t abstract—they map directly to common guidance.

NIST SSDF: make secure building blocks part of your process

NIST’s Secure Software Development Framework (SSDF) is widely referenced as a baseline for integrating security practices into the software lifecycle. In practice, SBOMs, scanning, signing, and auditability are exactly the kinds of controls you’d expect to be implemented as part of a secure development process—especially for artifact integrity and traceability.

(If that sounds like a polite way of saying “you will be asked for this in audits,” yes. It is.)

SLSA provenance: evidence about how artifacts were built

SLSA (Supply-chain Levels for Software Artifacts) defines a provenance model for describing where, when, and how an artifact was produced, using an in-toto attestation predicate type (for example, https://slsa.dev/provenance/v1). citeturn5search0

While OVHcloud’s blog post focuses on registry-level controls rather than end-to-end provenance generation, the connection is straightforward: registries that support attaching and enforcing OCI artifacts (signatures, attestations) become distribution points for provenance, not just images.

in-toto: cryptographically verify the chain, not just the end artifact

in-toto is a framework and metadata standard designed to secure the integrity of software supply chains by providing verifiable evidence of steps performed throughout the chain. citeturn5search6

SLSA’s own community notes that SLSA v1 is focused on build aspects and provenance, and that other in-toto predicate types can complement SLSA with contextual information—SBOMs (SPDX, CycloneDX), verification summaries, and more. citeturn5search4

That matters because “sign the image” is great, but “sign the image plus attest that tests passed, SBOM was generated, and the build ran in a hardened builder” is the direction the industry is heading.

A practical implementation blueprint (that won’t ruin your sprint)

Let’s turn the features into a realistic adoption plan. Not a perfect plan—just one that you can implement without rewriting your entire platform engineering backlog.

Step 1: Start with projects, RBAC, and robot accounts

MPR supports RBAC, namespaces/projects, and service/robot accounts. citeturn0search0turn2search0

Practical advice:

  • Create separate projects for dev, staging, and prod.
  • Use robot/service accounts for CI pushes, with the minimum permissions needed.
  • Restrict who can change project configuration (scanning, signing policies, immutability).

Why? Because supply chain security often fails through “configuration drift” and over-permissioned automation. Least privilege is not glamorous, but it’s very hard to exploit.

Step 2: Enable automatic vulnerability scanning on push

Enable scanning on push for each project and decide on a severity threshold policy. OVHcloud’s post explains how to run scans manually, automatically on push, or on a schedule, and how to block pulls above a given severity. citeturn1view0

Practical advice:

  • Start by monitoring (don’t block) to measure noise.
  • Then block Critical for production projects.
  • Add an allowlist process with expiry for exceptional cases.

Step 3: Turn on automatic SBOM generation

Configure SBOM generation on push for projects where it matters (which is increasingly “all of them”). MPR’s UI-driven automation is helpful here because it reduces reliance on every team remembering to generate and upload SBOMs correctly. citeturn1view0turn2search4

Practical advice:

  • Use SBOMs for incident response queries (“where is X used?”).
  • Feed SBOMs into your governance tooling if you have one.

Step 4: Sign images in CI, then enforce “verified only” pulls in production

Use Cosign or Notation in CI to sign images, and then enforce verification policies in the production project so only verified images can be pulled. OVHcloud MPR supports both tools and allows enforcement per project. citeturn1view0turn2search0turn2search7

Practical advice:

  • Begin with a single “golden path” service to validate the workflow.
  • Roll out enforcement gradually to avoid stopping deploys unexpectedly.
  • Standardize key management and rotation (don’t leave keys on runner disks).

Step 5: Add tag immutability for release tags

Configure immutability rules for release tags (v*, semantic versions, etc.) in production projects. As Vache notes, immutability prevents overwrites and deletion for immutable tags and protects against tag reassignment issues. citeturn1view0

Step 6: Plan for the next layer: provenance and policy engines

Once you can reliably attach and distribute SBOMs and signatures, the next layer is attestations like SLSA provenance and policy evaluation (e.g., requiring a provenance attestation from a trusted builder).

This is where OCI artifacts, the referrers model, and tools like in-toto and SLSA start to pay off. citeturn5search0turn5search4turn2search3

MPR vs. “roll your own Harbor”: the make-or-buy reality

Because MPR is Harbor-based, some teams will ask: “Why not just deploy Harbor ourselves?”

Valid question. Here’s the trade-off in plain terms:

  • Self-host Harbor: maximum control, maximum responsibility (upgrades, storage, backups, HA, auth integration, monitoring, incident response).
  • Managed MPR: less operational overhead, predictable plans, SLAs, but you live within the provider’s cadence and constraints.

OVHcloud highlights predictable pricing, included traffic, and plan tiers with different storage/concurrency/SLA characteristics. citeturn4view0turn4view1turn0search5

If you already run a platform team with strong Kubernetes operations and you want deep customization, self-hosting might fit. If your registry is mission-critical and you’d rather not run it like a pet, managed is usually the pragmatic route.

What to watch in 2026: VEX, better referrers support, and “evidence everywhere”

The OVHcloud post explicitly mentions two “not yet but planned / upstream” items that are worth tracking:

  • VEX/OpenVEX support in MPR/Harbor (planned), which would make “not exploitable” claims more standardized and portable than allowlists. citeturn1view0
  • Cosign v3 signature recognition issues in Harbor-based environments, with an upstream fix expected in Harbor 2.15. citeturn1view0

Meanwhile, the industry trend is clear: OCI artifacts and referrers-based discovery are making it more natural to store and distribute “security evidence” alongside artifacts—SBOMs, signatures, provenance, policy outcomes. That’s the direction that reduces bespoke integrations and makes verification more automatable across environments. citeturn2search3turn2search6turn5search0

Takeaways: what “good” looks like for container supply chains

If you want a simple mental model for container supply chain security in 2026, it’s this:

  • Every image has an SBOM (generated automatically, stored with the artifact).
  • Every image is scanned continuously (on push and on schedule).
  • Production only pulls verified images (Cosign/Notation policy enforced).
  • Release tags are immutable (no silent overwrites).
  • Everything is logged (audit trails, compliance, forensics).

OVHcloud’s Managed Private Registry is interesting because it bundles those controls into a managed service and places them where they’re most effective: at the distribution choke point. citeturn0search0turn1view0turn2search0

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org