ENH: Generate SPDX 2.3 Software Bill of Materials at configure time

[Copilot]

ITK lacks a machine-readable SBOM describing third-party dependencies, versions, and licenses for a given build configuration. The existing NOTICE file is static, not build-aware, and not parseable by SBOM tooling.

This adds SPDX 2.3 JSON SBOM generation at CMake configure time, producing sbom.spdx.json in the build directory with all enabled ThirdParty modules and their metadata.

Changes

• CMake/ITKSBOMGeneration.cmake (new): Core SBOM generation module
  • itk_generate_sbom() — iterates ITK_MODULES_ENABLED, filters ThirdParty modules, emits SPDX 2.3 JSON with packages, relationships, and extracted licensing info for custom LicenseRef-* identifiers
  • itk_sbom_register_package() — public API for remote modules to register their own SBOM entries
  • SPDX metadata (license ID, version, download URL, supplier) for all 24 ThirdParty modules plus optional FFTW (GPL)
• CMakeLists.txt: ITK_GENERATE_SBOM option (default ON), SBOM generation hook after ITKModuleEnablement, install rule for sbom.spdx.json

Remote module extensibility

# In a remote module's CMakeLists.txt:
itk_sbom_register_package(
  NAME "MyRemoteModule"
  VERSION "1.0.0"
  SPDX_LICENSE "Apache-2.0"
  DOWNLOAD_LOCATION "https://github.com/example/MyRemoteModule"
  SUPPLIER "Organization: Example"
  COPYRIGHT "Copyright Example Inc."
)

Output structure

Default build produces 22 packages (ITK + 21 ThirdParty deps) with DESCRIBES and DEPENDS_ON relationships, hasExtractedLicensingInfo for public-domain custom license refs (NIFTI, GIFTI, SLATEC). Disabled via -DITK_GENERATE_SBOM=OFF.

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

Refer to the ITK Software Guide for
further development details if necessary.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Generate a Software Bill of Materials at Build Time</issue_title>
<issue_description>

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.

</issue_description>

<agent_instructions>Implement this feature (generate SBOM at build time)</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Generate a Software Bill of Materials at Build Time #4302

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.