groups: - id: registry.artifact type: attribute_group display_name: Artifact Attributes brief: > This group describes attributes specific to artifacts. Artifacts are files or other immutable objects that are intended for distribution. This definition aligns directly with the [SLSA](https://slsa.dev/spec/v1.0/terminology#package-model) package model. attributes: - id: artifact.filename type: string stability: development brief: > The human readable file name of the artifact, typically generated during build and release processes. Often includes the package name and version in the file name. note: | This file name can also act as the [Package Name](https://slsa.dev/spec/v1.0/terminology#package-model) in cases where the package ecosystem maps accordingly. Additionally, the artifact [can be published](https://slsa.dev/spec/v1.0/terminology#software-supply-chain) for others, but that is not a guarantee. examples: [ "golang-binary-amd64-v0.1.0", "docker-image-amd64-v0.1.0", "release-1.tar.gz", "file-name-package.tar.gz", ] - id: artifact.version type: string stability: development brief: > The version of the artifact. examples: ["v0.1.0", "1.2.1", "122691-build"] - id: artifact.purl type: string stability: development brief: > The [Package URL](https://github.com/package-url/purl-spec) of the [package artifact](https://slsa.dev/spec/v1.0/terminology#package-model) provides a standard way to identify and locate the packaged artifact. examples: [ "pkg:github/package-url/purl-spec@1209109710924", "pkg:npm/foo@12.12.3", ] - id: artifact.hash type: string stability: development brief: > The full [hash value (see glossary)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf), often found in checksum.txt on a release of the artifact and used to verify package integrity. note: | The specific algorithm used to create the cryptographic hash value is not defined. In situations where an artifact has multiple cryptographic hashes, it is up to the implementer to choose which hash value to set here; this should be the most secure hash algorithm that is suitable for the situation and consistent with the corresponding attestation. The implementer can then provide the other hash values through an additional set of attribute extensions as they deem necessary. examples: ["9ff4c52759e2c4ac70b7d517bc7fcdc1cda631ca0045271ddd1b192544f8a3e9"] - id: artifact.attestation.id type: string stability: development brief: > The id of the build [software attestation](https://slsa.dev/attestation-model). examples: ["123"] - id: artifact.attestation.filename type: string stability: development brief: > The provenance filename of the built attestation which directly relates to the build artifact filename. This filename SHOULD accompany the artifact at publish time. See the [SLSA Relationship](https://slsa.dev/spec/v1.0/distributing-provenance#relationship-between-artifacts-and-attestations) specification for more information. examples: [ "golang-binary-amd64-v0.1.0.attestation", "docker-image-amd64-v0.1.0.intoto.json1", "release-1.tar.gz.attestation", "file-name-package.tar.gz.intoto.json1", ] - id: artifact.attestation.hash type: string stability: development brief: > The full [hash value (see glossary)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf), of the built attestation. Some envelopes in the [software attestation space](https://github.com/in-toto/attestation/tree/main/spec) also refer to this as the **digest**. examples: ["1b31dfcd5b7f9267bf2ff47651df1cfb9147b9e4df1f335accf65b4cda498408"]