Generate a Software Bill of Materials at Build Time

[tbirdso]

Overview

We should explore generating a Software Bill of Materials (SBOM) to describe ITK components and dependencies at build time. This could extend or replace the existing NOTICE file to describe third party dependencies / supply chain components and their respective licenses.

Background

An SBOM is a human- and machine-readable description of component dependencies that can be used for software supply chain tracking, allowing customers to identify licenses and vulnerabilities in software components. Industry support for SBOM standards has grown following the related 2021 “Executive Order on Improving the Nation’s Cybersecurity.”

Supply chain discovery, i.e. the ability to trace through third party dependencies and their components, is important for several scenarios:

1. Research partners and commercial entities want to be able to trace through licenses involved with a given ITK distribution and understand potential impact on downstream licensing and distribution (i.e. copyleft, closed source)
2. Not all components will be included with every build. For instance, standard ITK distributions are not built with FFTW since it is licensed under GPL (copyleft), but developers may create custom ITK builds with FFTW that would in turn be subject to copyleft licensing.
3. In the event that a vulnerability is discovered in an upstream dependency, developers should be able to backtrace and understand what ITK distributions are affected.

Existing Efforts

ITK's NOTICE document serves as a legal notice of all of ITK's third party dependencies and their licensing. While this is a good start and likely sufficient from a legal perspective, there are several pain points for supply chain discovery:

1. Not generated at build time: no document exists that exactly describes the configuration of a given build (i.e. if FFTW is turned on, etc)
2. Not machine readable: no existing SBOM tools can parse the ITK NOTICE for supply chain review.
3. No versioning information: developers must manually trace through ITK (specifically CMake) to understand what dependency versions are retrieved, and the information is not packaged with a build distribution.

Proposed Efforts

We should pursue efforts to align with an existing SBOM standard. VTK has recently adopted SPDX. For maintainability it would be reasonable for ITK to follow suit.

A migration plan could follow a structure similar to the following:

1. First, replace NOTICE with an sbom.json document reflective of third party dependencies and their licenses that could possibly be built with a fully configured ITK distribution.
2. Then, explore adding SPDX headers to ITK source files to describe licensing on build generation.
3. Then, implement config/build integration with a CMake-configurable sbom-build.json.in such that building ITK generates sbom-build.json descriptive of ITK dependencies. sbom-build.json must include a) each dependency component that is enabled at build time, b) the version of the component, and c) the license of the component.

This migration is unlikely to happen overnight, but is in the best interest of long term ITK adoption as SBOM documentation continues to gain traction in supply chain security.

Additional Information

It is unclear how building ITK with remote modules may impact SBOM validity. It would be good to explore that effort and possibly introduce CMake mechanisms to allow remote modules to extend SBOM components description before sbom-build.json is generated in the ITK build.

[hjmjohnson]

SPDX/SBOM Progress Update (2026-04-15)

Three PRs address all three phases of the original roadmap:

Phase 1+3: Build-time SBOM — PR #5817 (draft, CI running)

• SPDX 2.3 JSON SBOM generated at configure time with itk_generate_sbom()
• Per-module SPDX metadata in each itk-module.cmake (all 23 ThirdParty modules)
• Version info for 11 modules cross-checked against UpdateFromUpstream.sh
• Remote module extensibility via itk_sbom_register_package()
• Validation CTest + version consistency test

Phase 2: SPDX file headers — PR #6063 (draft, CI running)

• // SPDX-FileCopyrightText: Copyright NumFOCUS + // SPDX-License-Identifier: Apache-2.0 added to 5,503 ITK source files
• VTK convention (lines before /*=== block)
• KWStyle template updated to match
• Migration script at Utilities/Maintenance/AddSPDXHeaders.py

Phase 2 extension: Remote modules — skill created, not yet applied

• Reusable script for propagating SPDX headers to remote modules
• Tested on AdaptiveDenoising (8 files)

Remaining work

• Merge ENH: Generate SPDX 2.3 Software Bill of Materials at configure time #5817 and STYLE: Add SPDX license identifiers to all ITK source files #6063 after CI is green
• Propagate SPDX headers to ~60 remote module repos (one PR per module)
• Add reuse-lint pre-commit hook for ongoing enforcement
• Consider REUSE.toml for bulk SPDX annotation of files that can't have inline headers
• DCMTK/GDCM multi-license SPDX expressions need expert review
• 12 ThirdParty modules without SPDX_VERSION (track master/SHA)