An artifact is any file produced by your build chain (binary, container image, package, library) and meant to be deployed or reused. This course teaches you to put an artifact repository into service, to cache the public repositories behind it, to publish your packages to it, to serve images from it, then to secure it, to sign what it holds, to cut it off from the Internet and to back it up. Pulp is the reference implementation, Nexus the enterprise option, and Artifactory and Harbor the points of comparison.
Artifact management is not mere storage. A badly controlled artifact is an open flaw: malicious code slipped in through a compromised dependency, an undetected vulnerability, a secret forgotten in an image. The repository is the link that decides what runs in production, so traceability, integrity and access control sit at the heart of the approach.
Who is this course for, and what should you know first?
The course is at intermediate level and is meant for people who operate the repository rather than just use it: platform teams, system administrators, and developers building a reliable delivery chain. It assumes two skills, which you can work on first if needed.
The first prerequisite is Linux: knowing how to open a terminal, start and monitor a service, and read logs. The Linux course covers this foundation. The second is containerisation: knowing what an image and a container are, and running one with Podman or Docker. The Introduction to containerisation course (in French) covers it. Every tool is installed in a container: without these two foundations, the exercises become opaque.
What is the programme, module by module?
The programme follows the order of the course outline shown in the left-hand column, with the duration of each lesson. The Overview module is this page: it sets out the promise, the vocabulary and the choice of a manager. The Path module holds the My path page, where you follow your progress lesson by lesson and pick up where you left off.
The Understand the chain module shows where what runs comes from: the forge holds the code, the artifact repository what comes out of it, the registry the images. It has two lessons, Forges, artifact repositories and registries (in French) and container registries. It teaches you to read this chain before operating one of its links.
The Lifecycle of an artifact module teaches what an artifact is, why you build it only once, how you name it so you can find it again, and how it moves through the environments without being rebuilt. Its three lessons come from other courses and stay there: build once, name, store, retrieve, understanding OCI (in French) and promoting an artifact.
The Secure the software supply chain module states what a repository must prove about what it serves: the inventory of components, the provenance of the build, and the decision to refuse an artifact that does not carry it. It builds on four existing lessons, from software supply chain security to the SBOM, SLSA (in French) and the decision based on provenance.
The Put Pulp into service module is the reference implementation: what Pulp is, its container installation, publishing and consuming artifacts, then its use as a container registry with a Trivy scan.
The Run Pulp module gathers the steps that separate a demo instance from a service handed over to a team: access control, signing with Cosign and GPG, offline operation, backup and restore and deployment on Kubernetes.
The Nexus, the enterprise option module does not repeat Pulp: it shows what Nexus does differently, from its installation to its proxy repository and its Docker registry. Nexus is the manager most widespread in companies.
The Compare: Artifactory and Harbor module presents the two other managers on the market, Artifactory for the enterprise and Harbor for container images, and the criterion for choosing between them.
The Protect the software supply chain module closes the course. A repository is useless if it lets anything in: here you decide what crosses the door, with securing dependencies and the Varnish artifact firewall, then you serve a CI without depending on the public repositories, with the GitLab registries (in French).
What is an artifact?
An artifact is a generated file that is consumed during the build cycle of an application or an infrastructure. Depending on the context, it will be:
- an executable binary (ELF, EXE, JAR);
- a Docker or Podman container image;
- a library or module (
.jar,.whl,.so,.dll); - a system package (
.deb,.rpm,.apk); - a deliverable configuration file (Helm chart, Kubernetes manifest).
What they have in common: these files must be reproducible, traced and verifiable before they reach production. That is what sets a DevSecOps delivery chain apart from a plain scp of binaries.
The lifecycle of an artifact
A trustworthy artifact is not improvised at deployment time. It is built through five phases, each one adding security and quality guarantees.
1. Plan the requirements
The cycle begins before the first line of code. You need to identify the security and compliance constraints that apply to your sector: ISO 27001 (security management), GDPR (personal data), PCI-DSS (card transactions), CIS Benchmarks and NIST (good practice). Building these rules in from the design stage costs far less than bolting them on at the end, and avoids a production release being blocked for non-compliance.
This is also the moment to fix a dependency management policy (no unvetted libraries), environments with no hard-coded secrets, and upstream scans.
2. Develop and control the source code
The first artifacts are born here, as sources and configurations. A source code manager (Git, through GitHub, GitLab or a self-hosted forge) is unavoidable, with a few non-negotiable habits:
- clear branches and merge requests with mandatory review and approval;
- automatic scans on every MR (dependencies, secrets, quality);
- standardised commit messages (in French) for full traceability.
Dependency management deserves special attention: it is the first attack surface of the supply chain. You plug in vulnerability scanners such as Trivy or OWASP Dependency-Track (in French), and secret detectors such as Gitleaks or TruffleHog (in French). Systematically check the licence of the libraries and ban unmaintained packages.
On the quality side, static analysis (SonarQube, CodeQL) and linting (in French) feed the feedback loop before the code even runs.
3. Build trustworthy artifacts
The build turns code into artifacts through an automated and reproducible process. Every change triggers a CI/CD pipeline that chains test, build, security analysis and publication.
stages: [test, build, security, deploy]
build: stage: build script: - IMAGE_VERSION=$(git describe --tags) - docker build -t "$IMAGE_NAME:$IMAGE_VERSION" .
sbom: stage: build image: aquasec/trivy:0.72.0@sha256:cffe3f5161a47a6823fbd23d985795b3ed72a4c806da4c4df16266c02accdd6f script: - trivy image --format cyclonedx --output sbom.json "$IMAGE_NAME:$IMAGE_VERSION" artifacts: paths: [sbom.json]
security: stage: security image: aquasec/trivy:0.72.0@sha256:cffe3f5161a47a6823fbd23d985795b3ed72a4c806da4c4df16266c02accdd6f script: - trivy image --exit-code 1 --severity HIGH,CRITICAL "$IMAGE_NAME:$IMAGE_VERSION"# Sign the image after a successful scancosign sign --key cosign.key "$IMAGE_NAME:$IMAGE_VERSION"As soon as a scan reveals a critical vulnerability, the artifact must neither be stored nor promoted. Those that pass are signed to prove their integrity (see below).
4. Store and version
A validated artifact must be stored securely to guarantee its availability and its traceability. This is the job of a repository manager, the heart of this section.
Every version gets a unique tag (v1.2.0, myapp:1.2), a retention policy deletes obsolete artifacts, and continuous scans replay the analysis: a CVE can appear weeks after storage. Tools such as Trivy or Grype (in French) keep re-evaluating artifacts at rest.
5. Deploy under control
Once tested and validated, artifacts are deployed by automated processes. Before any deployment, you verify the provenance and the signature of the artifact to make sure it comes from a trusted repository and has not been tampered with. Rolling update, blue/green or canary strategies limit the impact of a bad version, and the configuration stays separate from the code (environment variables, ConfigMaps, secrets injected from a vault).
Choosing a repository manager
The repository manager centralises your artifacts, caches the public repositories and acts as the single point for CI/CD. The choice is made on three axes: the formats handled, the security model, and now the licence.
| Tool | Scope | Licence |
|---|---|---|
| Pulp | Multi-format (RPM, DEB, Python, npm, containers) | GPL (100% free) |
| Nexus | Multi-format | Community Edition (EULA + quotas) |
| Artifactory | Multi-format + JFrog Platform | Proprietary (restricted free tier) |
| Harbor | Container image registry | Apache-2.0 (free) |
The licensing model has become a decision criterion in its own right. Since 2025, the free version of Nexus is no longer the unlimited "OSS" of old: it is called Community Edition, governed by an EULA and usage quotas. Artifactory remains proprietary with a restricted free version. Against them, Pulp is the only multi-format manager that is 100% open source, with no licence to accept and no component limit: a decisive argument for sovereignty contexts, tight budgets or a homelab. For container images only, Harbor offers a specialised free alternative.
Securing access and integrity
A poorly protected repository becomes a critical flaw. Three families of controls are essential.
Access control
Apply least privilege with distinct roles: read-only for consumers (deployment servers), write for teams, administration for governance. Ban hard-coded credentials and store tokens in a vault such as HashiCorp Vault, with regular rotation of the keys.
Signature and provenance
A digital signature proves that an artifact has not been altered since it was produced. Today's reference tool is Cosign (a Sigstore project), which replaces the old Notary. You sign after a successful scan, and you verify the signature before any deployment.
SBOM and traceability
An SBOM (Software Bill of Materials, the inventory of all the components of an artifact) makes the supply chain auditable: when a CVE hits a library, you immediately know which artifacts are affected. Generate it with Syft (in French) or Trivy, in CycloneDX or SPDX format, and store it next to the artifact.
Key takeaways
- An artifact (binary, image, package) must be reproducible, traced and verifiable before production.
- Its lifecycle covers five phases: plan, develop, build, store, deploy, each with its own controls.
- The repository manager is the central point: choose according to formats, security and licence.
- On licensing, Pulp is 100% free (GPL), whereas Nexus imposes an EULA and quotas, and Artifactory remains proprietary.
- Security rests on three pillars: access control (least privilege), signature (Cosign) and SBOM (Syft), with continuous scans.
- The course aims at a repository that is in service, protected, signed, usable offline and backed up, with Pulp as the reference and Nexus as the option.