What is SPDX and how does it make an SBOM exchangeable and verifiable?

SPDX is an open standard for exchanging component-related information. Companies can use it to express software packages, files, licenses, and dependencies, allowing different tools to read the same SBOM. It addresses how information should be described and exchanged, not just relying on file generation success to confirm software security.

First distinguish names from versions

SPDX 2.3 uses the Software Package Data Exchange name; SPDX 3.0.1 uses System Package Data Exchange with configuration files to extend information expression in different scenarios. When discussing examples or tool capabilities, specify the specific version and avoid using 2.x fields directly within a 3.x model. SPDX 2.3 and SPDX 3.0.1

Choose the version based on customer exchange requirements, tool support, and information scope. Projects needing to exchange software packages and licenses can follow existing toolchains; for expressing AI, datasets, or build relationships, assess corresponding configuration files. Do not replace compatibility validation with version updates.

What questions should a usable SBOM answer?

Firstly, clearly specify which product version and build the list corresponds to, as well as what was scanned. The perspectives on source code lists, container image lists, and final firmware lists are different; they should not be conflated into a boundaryless 'complete list'.

Secondly, accurately record component identifiers, versions, sources, verification information, and licenses. Connect the relationships between components. For uncertain information, distinguish between unknown, unanalyzed, and irrelevant data to avoid filling fields with speculation.

Lastly, save the generation tool, time, and responsible party, and associate the list with deliverables. During vulnerability response, teams can trace back from a component to its actual product version and maintenance object.

Three levels of validation after export

Format Validation: Check the fields, references, and constraints against the declared SPDX version, ensuring that the receiving tool can import. Valid syntax is just the beginning.

Content Validation: Randomly sample representative components to verify that the versions and sources are correct, relationships are not missing, and dependencies only present in packaging stages are included.

Process Validation: Use the list during a simulated vulnerability response to confirm whether affected deliverables, responsible parties, and disposition records can be found. If documents remain attached, they will struggle to maintain value over time.

Connecting the inventory to risk assessment

Software Composition Analysis (SCA) can assist in identifying components and matching known vulnerabilities and license information. However, the match results must be analyzed together with actual versions, usage methods, and patch statuses.

Does SPDX Equal Passing Security Certification? No. While the data format is compliant, it does not equate to passing security or compliance assessments.

Should we only keep the initial release list? No. Dependencies and deliverables change over time, so it's best to update with each release and maintain historical lists for traceability.