Artifact Fundamentals
Terminology, requirement levels, roles, and core concepts for transparency artifacts
Requirements terminology
This documentation uses a consistent set of terms to indicate the importance of each requirement. The terminology is based on common usage in technical standards (such as RFC 2119), adapted to ensure clarity when preparing and evaluating SBOMs, VEX files, and VDRs.
- Must / Shall / Required — the item is mandatory. It must be included or fulfilled to comply with the requirements.
- Should / Recommended — the item is strongly advised, but not strictly mandatory. In specific cases, valid reasons may exist to omit it.
- May / Optional — the item is not required. Its inclusion is at the discretion of the supplier or dependent on the use case.
Negative forms such as not required or not recommended follow the same logic.
These terms are applied throughout this site to help distinguish between essential elements, preferred practices, and areas where flexibility is allowed. They are also used as a basis for automated validation, where tooling can check whether submitted artifacts meet mandatory requirements and highlight deviations from recommended practices.
Terminology
The following terms are used throughout this site. Definitions are based on commonly accepted usage within the software supply chain and SBOM standards. Where applicable, meanings are consistent with those in CycloneDX and SPDX.
| Term | Full name | Description |
|---|---|---|
| Advisory | Security Advisory | An official statement from an organization related to a security vulnerability, providing information, guidance, or mitigation about a threat |
| Artifact | — | The specific file(s) and other digital material that make up the software described by the SBOM |
| Component | — | A distinct unit of software, such as a library, module, framework, or service, that is part of a larger software product or system |
| CPE | Common Platform Enumeration | A structured naming scheme for software components used in vulnerability databases such as the NVD |
| CSAF | Common Security Advisory Framework | A standardized framework for publishing vulnerability information, including VEX statements |
| CVE | Common Vulnerabilities and Exposures | An identifier given to a unique vulnerability in software, maintained by the Mitre Corporation |
| CWE | Common Weakness Enumeration | A community-developed list of software security weaknesses, serving as a common language for describing vulnerabilities |
| CycloneDX | CycloneDX | A lightweight SBOM standard format designed for use in application security contexts and supply chain component reviews |
| CycloneDX VEX | CycloneDX Vulnerability Exploitability Exchange | An extension of CycloneDX for conveying exploitability details of specific software vulnerabilities |
| Dependency | — | A software component that another component requires in order to function correctly. Dependencies can be direct or transitive |
| EPSS | Exploit Prediction Scoring System | A system predicting the likelihood that a vulnerability will be exploited in the wild within the next 12 months |
| OpenVEX | Open Vulnerability Exploitability Exchange | A format for conveying details of how specific software vulnerabilities can be exploited |
| Provenance | — | The origin and history of a component, including where it came from and how it was built |
| PURL | Package URL | A standard identifier for software packages used to describe component origin in a consistent format |
| SCA | Software Composition Analysis | An automated process that identifies open source components in software |
| SBOM | Software Bill of Materials | A list detailing components that make up software — an "ingredients list" for software |
| SLSA | Supply-chain Levels for Software Artifacts | A framework describing assurance of software artifacts based on the robustness of their software supply chain |
| SPDX | Software Package Data Exchange | A standard format for communicating SBOM information including component license, copyright, and security details |
| SBOM Subject | — | The software described by the SBOM document |
| VDR | Vulnerability Disclosure Report | A report detailing vulnerabilities in software, issued after discovery and vendor coordination |
| VEX | Vulnerability Exploitability eXchange | A format for conveying details of how specific software vulnerabilities can be exploited |
| Vulnerability | — | A weakness or flaw in software, hardware, or online service that can be exploited to perform unauthorized actions |
Roles
This section defines the primary roles involved in producing, delivering, and using the artifacts described on this site.
Supplier
The Supplier is any organization responsible for producing and delivering SBOMs and related artifacts. This role may be fulfilled by software vendors, system integrators, manufacturers, or other entities in the software supply chain.
The Supplier's responsibility covers the entire software stack delivered, including components from subcontractors, integrators, or open source maintainers.
Consumer
The Consumer is any entity that receives and processes SBOMs, VEX files, and VDRs from Suppliers. Consumers can represent different stakeholders depending on the context, such as procurement teams, operators, application security functions, compliance officers, or industry partners.
Grouping these varied needs under one role provides a consistent way to refer to those who rely on SBOMs and related artifacts for risk assessment, compliance, and operational assurance.
See the Role-based Guides for detailed workflows per role.