Secure your container image supply chain

Store images in a private, RBAC-controlled registry

The foundational control of a secure software supply chain is a registry that is closed by default, with per-project or per-team RBAC. Not a shared bucket everyone can push to, and not a public registry with images visible by default.

Robot accounts do the rest of the work:
•    Scope each robot account to a single project.
•    Give build steps write-only push permissions, and deployment steps read-only pull permissions.
•    Run one project per team, so a compromised project stays contained.
•    Apply one central policy across every project, centrally audited.
•    Keep personal and admin credentials out of automated builds entirely.

Scan every image for CVEs at push and on pull

Vulnerability scanning needs to happen at two points:
•    At push, so a new image is scanned the moment it's built.
•    At pull, so a policy check runs again before an older image is deployed against a newer vulnerability database.

An image that was clean in March may carry three known vulnerabilities by June, and only a pull-time check will detect them.

Scanning asynchronously at push doesn't slow the build. The scan runs in parallel while the pipeline continues, and results are available before the image is promoted toward production.

Sign artifacts with Cosign or Notary v2

Signing an image cryptographically records who built it and confirms it hasn't been tampered with in transit. It establishes a chain of trust from the build system to the cluster.

Trust is what an attacker is really targeting. The xz-utils backdoor worked because trust in one maintainer had accumulated for years, and attackers are patient enough to exploit a maintainer rather than a firewall.

Cosign, part of the Sigstore project, and Notary v2 are the two dominant open source approaches for container image signing today.

Without a signature and a policy that checks for one, there's no way to prove after an incident that the image running in production is the exact artifact your pipeline built. An unsigned image and a tampered one are indistinguishable at deploy time.

Enforce a deployment policy before images reach Kubernetes

Scanning and signing only matter if something enforces them. A Kubernetes admission controller, Kyverno or OPA Gatekeeper being the two common choices, checks every image at deploy time and rejects anything failing policy:
•    Unresolved critical CVEs.
•    A missing or invalid Cosign signature.
•    An image from an unapproved registry.

That is the control that makes the others enforceable, and the one an attack has to defeat. It turns image scanning from a reported metric into a hard gate, so no unscanned image reaches production, which is the actual compliance requirement.

The two enforcement points are complementary. The registry blocks the push, the cluster blocks the deploy, and an attack that gets past one still meets the other. Both sit on top of a cluster you don't have to operate yourself when you run OVHcloud Managed Kubernetes Service.

These four technical controls sit alongside, not instead of, the organizational practices that reduce the risk more broadly. Practices of this type are cheap next to an incident, and each is a practice an auditor can verify.

These are the practices that turn a secure design into a secure system, and each one is a central practice, not an optional extra:

•    Regularly update dependencies and third-party components to protect against known exploits.
•    Limit access to sensitive build systems and signing keys.
•    Educate employees and run security awareness training, so engineers recognize a compromised package or a phishing attempt against a maintainer account.
•    Conduct drills against an incident response plan, so a team knows how to respond fast when a control fails.
•    Verify the integrity of software continuously rather than assuming it, so every artifact stays secured by a check rather than by habit.

Any potential security gap in this list is usually a process gap, not a tooling gap.
Each software component you pull in, and each transitive component below it, is a decision someone made once and rarely revisits. A modern application includes hundreds of such components, most from an external party nobody has met.

Component inventory is therefore the practice everything else depends on. Dependency management, knowing which software and which components come from a third party, is what makes an SBOM (software bill of materials) useful once you have one.

An SBOM lists every component and every version, which turns a new CVE advisory into a five-minute query instead of a week of archaeology. Without one, the honest answer to whether you are exposed is that nobody knows.

Harbor under the hood: CNCF-graduated, OCI-standard, open source

Managed Private Registryis a fully managed instance of Harbor, a CNCF-graduated open source technology built for container and Helm chart storage, with security as a first-class feature rather than an add-on.

Self-hosting Harbor means running and patching PostgreSQL, Redis, Harbor's core services and the scanner, plus TLS and upgrades across every one of those components.

OVHcloud removes that operational layer. You create a registry, push images and configure policy, while the Harbor infrastructure underneath is OVHcloud's responsibility. That frees your cybersecurity team for threat modeling and supply chain resilience rather than patching a database.

Because Harbor is open source and standards-based, there's no proprietary lock-in. Images sit in the standard OCI format, so migrating to self-hosted Harbor or another OCI-compliant registry needs no conversion step and no proprietary pull format to unwind.

That transparency is itself a security property. A global community of reviewers, not a single vendor, reviews the code that runs your registry.

A central project with many reviewers detects a malicious commit faster than a closed one, and threat intelligence about Harbor or Trivy vulnerabilities reaches you through the same public channels every other user relies on.

Vulnerability scanning with Trivy: CVE detection at push and pull

OVHcloud Managed Private Registry includes Trivy, Harbor's built-in scanner, activated at the project level.

Configure scan-on-push so every image is checked as it lands, then set a CVE severity threshold. Warn on HIGH, block on CRITICAL is a recommended starting policy.

A scan at pull time then re-checks an older image against a newer vulnerability database.

A Harbor deployment policy prevents pulling images with unresolved CRITICAL CVEs into production namespaces, which is what makes the scan result actionable rather than informational.

Image signing with Cosign and Notary v2

The service is Harbor-based, so it supports the vulnerability scanning and Helm chart storage documented for the product.

Image signing itself runs through standard Cosign open source tooling in your CI/CD pipeline, pointing at the OVHcloud registry rather than a proprietary signing service.

Policy enforcement: block critical-CVE images before deploy

The registry-side policy, block on CRITICAL CVE and require a valid signature, is only half the enforcement story.

The other half runs in Kubernetes itself. A Kyverno or OPA Gatekeeper admission policy rejects any image without a valid Cosign signature, or with an unresolved severe vulnerability, regardless of how it was deployed or by which actor.

Together they give policy-enforced CVE blocking end to end. It is a configuration you set up deliberately, not an automatic guarantee.

Helm chart storage (OCI-compliant)

Helm charts are stored in the same OCI-compliant format as container images, in the same project structure, with the same RBAC and robot accounts.

Teams packaging deployments as Helm charts get one registry for both artifact types, instead of a separate chart repository to secure and maintain.

Robot accounts: write-only push for builds, read-only pull for deploys

Create one Harbor project per team or application, then issue robot accounts scoped to exactly what each stage needs: write-only push for the build stage, read-only pull for the deployment stage.
Never embed admin or personal credentials, or a robot

account's key file, in a build definition. A leaked pull-only robot account is a contained incident. A leaked admin credential in the hands of an external actor is not.

For Cosign signing keys specifically, OVHcloud OVHcloud Key Management Service supports bring-your-own-key with FIPS 140-2 HSM-backed storage, which keeps your keys off developer laptops and CI runners.

GitHub Actions example: build, scan, sign and push

A single stage covers the whole gate:
1.    Build the image.
2.    Push it with a write-only robot account.
3.    Wait for the Trivy scan result.
4.    Sign with Cosign only if the scan clears the configured CVE threshold.

This sequence keeps a hard gate between an image existing and an image being trusted enough to sign, rather than signing unconditionally at build time.

The same pattern applies whether the build runs on GitHub Actions, GitLab CI, or Tekton. Only the syntax for calling the registry and the scanner changes, regardless of the programming language your application is written in.

Kyverno admission policies on Managed Kubernetes Service

On OVHcloud Managed Kubernetes Service, a Kyverno policy, defined as a standard Kubernetes policy file, checks every incoming pod spec for a valid Cosign signature and rejects the deployment if the signature is missing or invalid.

Combined with the registry-side CVE policy, this closes the loop between what you build and what the cluster may run. An unsigned or unscanned image never starts, whoever requested the deploy.

Container images carry IP, and CLOUD Act exposure with them

A container image bundles application code, configuration layers and sometimes environment variables: a meaningful slice of your organization's intellectual property. A central registry is where that intellectual property concentrates, which is why its jurisdiction matters. Storing that image with a US-headquartered provider, even one with EU data centres, places it under US CLOUD Act jurisdiction, because exposure follows the parent company, not the storage location. The same logic applies to any AWS ECR, Google Artifact Registry, or Docker Hub deployment: US CLOUD Act jurisdiction attaches regardless of region.

European HQ, no US parent, GDPR by jurisdiction

A container image bundles application code, configuration layers and sometimes environment variables: a meaningful slice of your organization's intellectual property.

A central registry is where that intellectual property concentrates, which is why its jurisdiction matters.

Storing that image with a US-headquartered provider, even one with EU data centres, places it under US CLOUD Act jurisdiction, because exposure follows the parent company rather than the storage location.

The same applies to any registry operated by a US-headquartered provider: US CLOUD Act jurisdiction attaches regardless of region.

European HQ, no US parent, GDPR by jurisdiction

OVHcloud is a European operator with no US parent company, so there's no structural CLOUD Act exposure on anything stored in the registry.

Registry infrastructure runs under GDPR by jurisdiction rather than by policy commitment.

The legal protection comes from where the company and the infrastructure sit, not from a contractual promise layered on top of infrastructure a foreign authority could still compel.

3-AZ availability in Paris and Milan, 99.99% Availability SLA on MKS Standard

The registry runs 3-AZ in Paris with built-in high availability. A single zone failure stops neither your builds nor your deployments, which matters because a registry outage blocks both.

Managed Kubernetes Service Standard runs 3-AZ in Paris and Milan with a 99.99% Availability SLA, so the registry and the cluster pulling from it share one availability posture instead of one being the weak link.

MKS Free to start, MKS Standard for production

Managed Kubernetes Service has a free tier for development and staging, enough to validate the full software supply chain: registry, scanning, signing and admission policy, before committing to a production cluster.

Version pinning on your policy files keeps that validation reproducible.

When you're ready for production traffic, MKS Standard adds the 3-AZ tier with a 99.99% Availability SLA, and the same Kyverno or OPA Gatekeeper policies carry over unchanged across both tiers.

Teams running several clusters add Managed Rancher Serviceon top for one control plane across them.

Get started: activate your registry and ship secure images today

Create a Managed Private Registry project, push an image, and turn on scanning and signing. MKS Free covers development and staging at no cost, so you can validate the whole policy chain before production traffic depends on it. For multiple production clusters, regulated sectors or GPU node pools, an OVHcloud Solutions Architect will help size it. The Container orchestration hub is where to learn the rest.