What it means
Artifact repository integrity protects packages, containers, models, and build outputs from unauthorized replacement, deletion, downgrade, or ambiguous reuse.
Why it matters
Delivery controls fail when a trusted repository can serve a different object under the same name or when consumers cannot verify what they retrieved.
Practical focus
- Define the system boundary, accountable owner, approved purpose, material risks, and decision authority for Artifact Repository Integrity
- Use immutable versions, strong authentication, authorization, signatures, retention, quarantine, malware scanning, replication, and monitored administrative changes.
- Collect and protect this evidence: digests, signatures, upload identities, promotion records, access logs, scan results, retention events, and restore tests.
- Exercise this failure scenario as a planned test: an attacker replaces a previously approved package version and downstream deployments accept it because they reference only a mutable tag.
Common mistakes
- Using the label Artifact Repository Integrity without defining the exact systems, data, people, decisions, and time period in scope
- Treating a policy statement or tool demonstration as proof that Artifact Repository Integrity operates consistently in production
- Failing to retain digests, signatures, upload identities, promotion records, access logs, scan results, retention events, and restore tests in a form that lets an independent reviewer reconstruct decisions and changes
- Testing only the normal path and never rehearsing what happens when an attacker replaces a previously approved package version and downstream deployments accept it because they reference only a mutable tag.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: