Standards and Frameworks
Normative references and standards underpinning the content requirements
This section lists the standards and frameworks that form the basis for SBOMs, VEX files, and VDRs submitted under these requirements. The document does not define its own structure, field names, or terminology. Instead, it builds on existing and widely adopted standards, providing guidance on how they should be applied in this context.
Field definitions that are already clearly established in standards such as CycloneDX or SPDX are not repeated here. The focus is on identifying high-level requirements, indicating whether they are required (must) or recommended (should), how they are expected to be used, and why they are relevant for evaluation and processing.
Important note: This site does not reproduce the structure or field definitions of standards like CycloneDX or SPDX. Instead, it references those specifications where applicable. Suppliers must always refer to the official specifications for syntax and structure, and use the examples and rationale provided here to ensure proper representation.
Standards
Two widely used and standardized formats are accepted for expressing software metadata: CycloneDX and SPDX. Both formats are supported and serve as the foundation for the structure and semantics of SBOMs, VEX files, and VDRs.
-
CycloneDX — developed and maintained by the OWASP Foundation. A mature standard with a strong focus on software supply chain security. Well suited for modern DevSecOps workflows. Supports detailed information about component origin, dependency relationships, cryptographic hashes, and metadata relevant for vulnerability management. Standardised as ECMA-424. cyclonedx.org
-
SPDX — developed by the Linux Foundation's SPDX Workgroup. A mature standard originally created to support license compliance, since evolved into a comprehensive model for representing software components, licensing, relationships, and provenance. Widely used in open source compliance workflows. Standardised as ISO/IEC 5962:2021. spdx.dev
Both formats are supported by a growing ecosystem of tools and communities. While they share common goals, they differ in structure and terminology. No single format is mandated. However, all required content listed in the sections for SBOM, VEX and VDR requirements must be included and correctly represented.
Quality frameworks
The following frameworks help inform the interpretation of software transparency, quality, and traceability. While not mandatory, they provide useful context for why certain requirements are included and support a shared understanding between those producing and consuming SBOMs, VEX files, and VDRs.
| Framework | Publisher | Purpose |
|---|---|---|
| OWASP SCVS | OWASP | Maturity model for assessing completeness and trust in software component metadata |
| SLSA | OpenSSF | Progressive levels for securing the software supply chain, with emphasis on provenance and build integrity |
| CSAF | OASIS | Structured format for communicating vulnerability status, relevant for VEX and VDR artifacts |
| NTIA Minimum Elements | U.S. NTIA / CISA | Core fields required to make SBOMs useful and actionable across systems |
| CISA Minimum Elements 2025 (draft) | U.S. CISA | Updated core fields for SBOMs |
The requirements defined on this site take precedence in cases of overlap or conflict with external frameworks.
Tooling references
A wide range of open source SBOM generators is available today. These tools differ in scope, ecosystem coverage, and the formats they support. No single tool is universally suitable for all environments, and many organizations use a combination of tools to achieve complete and reliable coverage.
| Tool | Category | Primary targets | Typical strengths | SBOM formats |
|---|---|---|---|---|
| Observer CLI | Multi-engine SBOM generator | Filesystems, builds, container images, Kubernetes | Uses multiple open-source scanners; supports build-time capture; normalizes output and metadata | CycloneDX, SPDX |
| Trivy | Scanner / SBOM generator | Container images, filesystems, Kubernetes | Strong OS and application package coverage; broad container/K8s support; simple CI/CD integration | CycloneDX, SPDX |
| Syft | SBOM generator | Container images, filesystems, language ecosystems | Detailed package discovery across many ecosystems; good for host and image SBOMs | CycloneDX, SPDX |
| cdxgen | Application-centric generator | Source repositories, build manifests, application projects | Infers dependencies from code and manifests; well suited for CI/CD integration | CycloneDX |
| CycloneDX Maven plugin | Build-integrated generator | Java/Maven builds (and analogous plugins for other ecosystems) | Generates SBOMs from build metadata tied to specific artifacts and versions | CycloneDX |
| Microsoft SBOM Tool | Platform-specific generator | Windows/.NET builds, MSBuild, Azure DevOps | Native fit for Windows and .NET; integrates with Microsoft build tooling | SPDX, CycloneDX |
| Build Observer | Build-time dependency analyzer | Build systems and compilers | Extracts dependencies during build; complements SBOM generation in C/C++ or mixed-language applications | CycloneDX |
| OSV Scanner | Vulnerability and dependency scanner | Source repositories, manifests | Identifies dependencies via manifests and checks against OSV database | CycloneDX, SPDX |
| OSS Review Toolkit (ORT) | Dependency and license analysis | Source repositories, package managers | Comprehensive dependency resolution and license analysis | CycloneDX, SPDX |
References
| Reference | Notes |
|---|---|
| CycloneDX v1.6 | Bill of materials specification |
| SPDX v2.2.2 | Bill of materials specification |
| ECMA-424 | CycloneDX 1.6 as ECMA standard |
| ISO/IEC 5962:2021 | SPDX 2.2.1 as ISO standard |
| Package URL (types) | Package URL specification v1.0.X |
| CPE v2.3 | Software identification standard from NIST |
| SWID | Software identification standard from NIST |
| SPDX License List | Standardized short identifiers |
| SPDX License Expressions | License expression syntax (normative) |