Artifact Assurance¶
The IHL Artifact Assurance Bundle is the publication model for security and engineering evidence associated with an exact immutable artifact digest. Its purpose is to help consumers identify what was released, understand which controls were performed, verify integrity and origin, and evaluate known limitations.
Availability boundary
This page defines the required evidence model; it is not itself a release record. A bundle exists only when a catalog entry links to evidence for a named digest. No generally available artifacts are currently listed in the Container Catalog.
Digest-first evidence¶
Source and inputs
↓
Authorized build process
↓
Immutable OCI digest
↓
Assessment · Tests · Provenance · Attestations · Signature
↓
Artifact Assurance Bundle
A version label or mutable tag is not sufficient evidence identity. The bundle and its records must refer to the exact digest under evaluation. A rebuild produces a new artifact and therefore requires a new or explicitly related evidence set.
Bundle contents¶
Product profiles may require different evidence, but a published bundle must inventory every included and omitted evidence class. Common evidence includes:
| Evidence | Consumer question |
|---|---|
| Artifact metadata | What is this artifact, version, platform, purpose, and support state? |
| OCI digest | Which exact immutable content does the evidence describe? |
| SBOM | Which software components were discovered? |
| Vulnerability report | Which findings were reported at assessment time? |
| VEX | Which findings are affected, not affected, fixed, or under investigation—and why? |
| Functional tests | Did the artifact perform its declared functions under the tested conditions? |
| Runtime security tests | Did tested runtime properties match the intended security profile? |
| Provenance | Which source, inputs, and authorized build context produced the artifact? |
| Attestations | Which verifiable claims were issued about the artifact or process? |
| Signature verification | Can artifact identity and integrity be validated under the release trust policy? |
| Exceptions | Which approved deviations or residual risks affect the claim? |
| Certification state | Is any separate certification applicable, and what exactly is its scope? |
Assurance is compositional¶
No single record establishes complete security:
- an SBOM inventories discovered components but does not assess behavior;
- a scanner compares observed components or code with known intelligence;
- VEX records assessed applicability but depends on evidence and scope;
- provenance establishes origin and process traceability, not source correctness;
- a signature establishes identity and integrity under a trust policy, not suitability; and
- tests provide evidence only for the conditions and behaviors they cover.
The value of the bundle comes from using these records together and preserving their relationship to the same artifact.
Publication and sensitivity¶
Public bundles should expose useful verification information and material consumer limitations. They should not disclose private signing keys, credentials, internal network topology, runner credentials, sensitive pipeline configuration, private vulnerability intelligence, or detailed internal exception records.
Publication rule¶
Each release record states which evidence is present, its creation or assessment time, the subject digest, and any material limitations. An omitted record is marked not produced, not applicable, or withheld, with a public rationale when safe. Evidence formats and retention may evolve, but a newer bundle must not silently rewrite the historical state of an older digest.