Secure your software supply chain from build to deployment

Prevent unscanned, unsigned or vulnerable container images from reaching production. This guide shows how private registry controls, vulnerability scanning, artefact signing and Kubernetes admission policies create an enforceable workflow across the software supply chain. 
Get StartedManaged Private Registry
Domain names illustration

Verify every component in your pipeline

Software supply chain security means continuously verifying every dependency, package and artefact in a CI/CD pipeline. Trust must cover source, public packages, external technology, third-party components, build elements, registries and the final release. A threat may enter through altered dependencies or compromised processes. Start by identifying each customer-facing component against a recognised framework, such as NIST guidance or SSCS principles. Teams can then learn where evidence is missing, apply secure coding practices, and sign outputs with Cosign. This framework-led approach lets you enforce assurance throughout the chain rather than rely on one checkpoint. Each party can trace what entered the build, how it was handled and which evidence supports deployment.
[object Object]

Build release assurance on verifiable controls

Private Harbor projects, Trivy policies, Cosign signing and European jurisdiction
Community@2x.png
Restrict registry access
Cyber Security@2x.png
Block known vulnerabilities
Magnifying Glass Check@2x.png
Verify origin and resilience

Protect every stage attackers can target

What is supply chain security in a modern container environment?

What is supply chain security in a modern container environment? It protects the route from source code and third-party dependencies through build systems, image storage and deployment endpoints. Software supply chain security treats these processes as connected because an attack at one end can weaken every later control.

Source repository protection

A source repository is a clear target. An attacker may steal credentials, alter code, disable a review rule or introduce a dependency that appears legitimate. Controlled download sources, mandatory peer review and protected branches form the first line of defence. Teams should also lock dependency versions and verify checksums, licences and origins rather than accept changing inputs for each build. These checks reduce the risk of importing malicious or unauthorised software from another party.

Build infrastructure attack paths

Build infrastructure presents different attack paths. Compromised runners, exposed secrets or mutable base images can modify an artefact after developers approve its source. Isolate build processes, use short-lived credentials and record exact inputs. This approach supports container image security by making unexpected code changes easier to trace.

Registry-to-cluster controls

The registry-to-cluster route needs independent controls. An attacker might replace an approved image, reuse an old tag or exploit excessive deployment permissions. Least-privilege access restricts what each identity can publish or retrieve. Immutable references connect manifests to precise images, while Kyverno can reject releases that lack trusted evidence or breach security requirements.

Effective software supply chain management begins with an inventory. Record first-party and third-party libraries, base images, licences and build tools used by each application. Connect every software bill of materials (SBOM) to the project, commit and pipeline run that produced its artefact. This relationship helps cybersecurity teams identify services affected when a sensitive component is compromised. Choose a tool that exports machine-readable evidence and compares releases through automation. The inventory should develop alongside the software, rather than depend on periodic manual work. Assign a contact for dependency topics, exceptions and remediation so ownership remains clear.
Run security testing early enough to give developers actionable results. Pipeline automation can examine source dependencies, container layers and configuration before promotion. Define CVE scanning thresholds according to workload exposure and business impact, then route failed results to the responsible team. A failed check should stop progression instead of generating an unread alert. Record the issue, affected package, severity and approved response. This evidence helps protect release quality while keeping software supply chain security decisions consistent across applications.
Image signing proves which controlled process approved an artefact. Sign each image by immutable digest after required tests pass, then retain provenance that identifies the source revision, builder and workflow. Avoid signing mutable tags alone, since a tag can later reference different content. Separate signing permissions from general developer and pipeline access. Verification should use trusted identities or public keys defined by your organisation. A compromised build process cannot then create acceptable evidence unless it also satisfies the signing policy.
A Kubernetes admission controller provides the final decision point before workloads enter a cluster. Configure it to reject unsigned images, unapproved registries, failed vulnerability criteria or missing provenance. Kyverno and OPA Gatekeeper can express these conditions as version-controlled policies. Test each rule against representative workloads before production enforcement. Begin in audit mode to find legitimate exceptions, then place mature controls into blocking mode. Maintain an authorised exception path with an owner, reason and expiry date. The cluster can then evaluate release evidence consistently, even when an earlier control is bypassed or misconfigured.
Effective software supply chain management begins with an inventory. Record first-party and third-party libraries, base images, licences and build tools used by each application. Connect every software bill of materials (SBOM) to the project, commit and pipeline run that produced its artefact. This relationship helps cybersecurity teams identify services affected when a sensitive component is compromised. Choose a tool that exports machine-readable evidence and compares releases through automation. The inventory should develop alongside the software, rather than depend on periodic manual work. Assign a contact for dependency topics, exceptions and remediation so ownership remains clear.

Assign ownership across four governance priorities

Trusted code and vendor governance

A named leader should define trusted source and vendor criteria, supported by procurement, engineering and security resources. Use SLSA as guidance for stronger build integrity and provenance without assuming a particular attainment level. Scale reviews to organisation size and software supply chain risk.

Policy enforcement and compliant infrastructure

Security and platform owners should translate compliance obligations into measurable policy enforcement across code, cloud and infrastructure. Define who may approve exceptions, what evidence they must provide and how controls meet internal requirements.

Documentation, audits and evidence

Assign an accountable resource to maintain documentation for decisions, dependencies and control changes. Regular audits should test whether records match operational practice. Give reviewers enough support to trace an issue to its owner, affected release and resolution.

Incident readiness and remediation ownership

A security leader should coordinate response roles before an attacker tests them. Maintain a plan to address potential issues, covering triage, containment, stakeholder communication and recovery. Each action needs a responsible owner, supporting resources and timelines suited to the organisation's risk exposure.

Operate Harbor through four security pillars

Control access precisely

Harbor supports project- and team-level RBAC for separating enterprise workloads and responsibilities. Issue scoped robot accounts for CI/CD push and pull tasks instead of sharing broad human credentials. Match each identity to one purpose, rotate its secret and remove unused access. This practice limits the impact of credential exposure while securing day-to-day publishing.

Detect unsafe components continuously

Combine continuous Trivy checks with software composition analysis (SCA) and dependency management. These tools detect known vulnerabilities, outdated packages and indicators of malicious code within each component. Produce a clear report for every release, including severity, location and remediation status. Teams can then distinguish blocking findings from accepted exceptions and notice when new intelligence affects stored artefacts.

Connect development workflows

Integrate the platform with GitLab CI, Tekton and other approved development workflows. Keep policy decisions close to the pipeline so a failed check returns useful feedback before promotion. Source code management (SCM) references should link each artefact to its commit, build run and owner. DevSecOps teams then have a consistent record rather than separate evidence scattered across systems.

Prepare operational response

Maintain an incident response plan for compromised credentials, unsafe images and failed controls. Define who pauses distribution, removes an affected version, investigates access and approves recovery. Alerts need an owner and an expected response route; generating them alone does not reduce risk. Run exercises to confirm that security and platform teams can find the relevant report, isolate content and communicate decisions. This operational pillar turns detection into timely action across the delivery platform.

Preserve trustworthy evidence for each release

Release visibility depends on evidence that shows who produced an artefact, where it came from and how it was tested. Generate and retain Trivy results, software bill of materials data and signatures for every image and set of Helm charts. This allows the organisation to identify each content type and investigate a potential security issue. Integrate checks with GitLab CI to automate developer feedback before software enters the controlled environment. Consistent testing also supports security awareness by showing why a release failed. Protect Cosign signing keys through OVHcloud Key Management Service, using FIPS 140-2 HSM-backed storage. Centralised key management helps ensure each generated signature is tied to controlled key material rather than an exposed pipeline secret.
[object Object]
Enforce your container release policy with OVHcloud
Build a controlled route from CI/CD output to Kubernetes deployment with Managed Private Registry and Managed Kubernetes Service. Evaluate how registry validation, release evidence and cluster enforcement can stop unscanned, unsigned or vulnerable images before production. Discover Managed Private Registry, then assess the Kubernetes integration for your workloads, policy model and operational responsibilities.
Explore registry path