Generate a Software Bill of Materials at Build Time

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:

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)
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.
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:

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)
Not machine readable: no existing SBOM tools can parse the ITK NOTICE for supply chain review.
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:

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.
Then, explore adding SPDX headers to ITK source files to describe licensing on build generation.
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.

STYLE: Add SPDX license identifiers to all ITK source files

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)

STYLE: Add SPDX license identifiers to all ITK source files

ENH: Add SPDX 2.3 SBOM generator at configure time

@bauer-tom

I reviewed this roadmap and the companion PRs — #6084 (bulk SPDX tagging) and #5817 (SBOM infrastructure) — and researched the case for including this infrastructure. My conclusion: this substantially lowers the friction for ITK's commercial audience (FDA/EU regulatory burden) while simultaneously strengthening the open-source tree for every user (automated CVE tracking, clearer licensing, REUSE compatibility). Net effect hoped for: more commercial adoption → more commercial support cycling back into ITK maintenance → more resources for the whole community.

Evidence, citations, and community-benefit analysis are in the collapsible sections below — read only what interests you.

🏥 Regulatory drivers make SBOM + SPDX a hard requirement

ITK's own FDA guidelines page positions the toolkit as off-the-shelf software for FDA medical-device submissions. Three converging regulations make SBOM + SPDX a legally required artifact for that audience:

US FDA Section 524B(b)(3) (21 USC 360n-2, effective 2023-03-29) — every "cyber device" premarket submission must include a machine-readable SBOM listing "commercial, open-source, and off-the-shelf software components." (statute text, FDA guidance Sept 2023)
IEC 81001-5-1:2021 — EU-harmonized cybersecurity standard (harmonized under MDR since May 2024). Annex E.2.4 explicitly references SBOM; clause 4.3 requires per-component categorization. (ISO page)
EU Cyber Resilience Act (Regulation 2024/2847) — machine-readable SBOM obligations apply from 2027-12-11. (EU page)
IEC 62304 SOUP documentation — the SPDX_VERSION / SPDX_LICENSE / SPDX_DOWNLOAD_LOCATION fields we emit are the verbatim SOUP fields required for every vendored dependency.

The NTIA minimum elements document (PDF) restricts SBOM formats to SPDX, CycloneDX, or SWID. SPDX (ISO/IEC 5962:2021) is what VTK already chose — adopting it keeps the ITK/VTK stack aligned for shared downstream consumers.

💼 Commercial-user evidence from ITK Discourse

The 2019 ITK community survey (link) documented 32% commercial users and 74% medical-imaging focus. Real incidents showing these users already pay the friction tax this PR series eliminates:

#7452 (March 2025): @bauer-tom, a commercial user, discovered non-commercial ACM-licensed rpoly.f buried 19 years deep in VNL. Per-file SPDX + reuse lint in CI would have caught this at import time.
#7632 (Sep 2025): @Rosie manually triaging optional modules for "license infection" — FFTW (GPL), OpenSlide (LGPL), etc. The generated SBOM lists every enabled module's license in one machine-readable place.
#7748 (April 2026, 5 days ago): @dclunie posted GDCM CVE-2026-3650; @lassoan explicitly asked commercial GDCM users to contribute back. With PURLs in the SBOM, a downstream vendor runs osv-scanner sbom ... and answers "is my ITK build affected?" in seconds.
#5555 (Dec 2022): @hapap — "We are dealing with a regulated medical device and including Python library into the software would cause all kind of validation and verification hassle." Concrete confirmation that regulated C++ ITK users exist and carry V&V burden.
#5159 (July 2022): @martinpare asking for an ITK vulnerability database "to document known vulnerabilities and security related bugs." The SBOM + PURLs are that database.
#1317 (Sep 2018): @jhlegarreta found 7+ remote modules missing LICENSE files entirely. REUSE compliance + CI reuse lint prevents this class of drift going forward.

The vocabulary the community already uses — "license infection," "not commercial-friendly," "V&V hassle" — maps one-to-one onto what this infrastructure automates.

🌱 Open-source adoption benefits (not just a regulatory tax)

The infrastructure benefits every ITK user, not only commercial ones:

Automated CVE tracking. With PURLs in the SBOM, any user (academic, hobbyist, commercial) can pipe sbom.spdx.json into OSV-Scanner / Trivy / Grype / Anchore Syft and get a security report in seconds. Today this is manual per-module work.
Clear license provenance for every file. Per-file SPDX headers make the licensing legible to scancode-toolkit, fossology, REUSE — tools that downstream distributions (Debian, Fedora, conda-forge) already use.
Lower onboarding friction for contributors. The pre-commit hook catches missing SPDX headers at commit time instead of after a CI cycle; contributors learn the convention immediately.
Defense in depth against rpoly.f-class drift. A future ThirdParty update that accidentally imports GPL-tainted code is caught by REUSE lint or SBOM review, before it becomes a 19-year-old buried problem.
Ecosystem alignment. VTK already adopted SPDX; adopting it here keeps the ITK/VTK/Slicer/MITK stack on a single supply-chain format.

None of this is "just for the commercial users."

🚀 Expected benefits to the ITK community

Concrete outcomes I expect from this infrastructure landing:

Lower barrier to commercial adoption → more commercial support for ITK. Every regulated-device vendor that considered ITK but balked at the V&V burden of building an SBOM from scratch now has that artifact shipped with ITK. One fewer reason to walk away.
Reduced maintainer time on license questions. Threads like #7452, #7632, and ENH: updating remote modules #1317 consume maintainer bandwidth that per-file SPDX + REUSE eliminate by making the answer machine-readable.
Faster security response cycle. When the next GDCM-class CVE lands, the workflow is osv-scanner sbom ... | grep <cve> instead of Discourse threads asking "is ITK affected?" manually.
Easier upstream contribution. Pre-commit catches SPDX header omissions immediately. New contributors learn the convention from the hook, not from a CI failure.
Virtuous cycle for funding. More commercial ITK-based products in the market → more companies with a stake in ITK's health → more pressure and resources for continued maintenance. The funding model for open infrastructure like ITK depends on this feedback loop working.
Pays down technical debt. Legacy files with Insight-Software-Consortium headers or ambiguous licensing (fdstream, dsrc2c) are now explicitly annotated via REUSE.toml. The tree stops accumulating license-provenance ambiguity.

None of these depend on every ITK user being commercial. They accrue to the community as a whole.

📚 Supporting documents and full-detail references

The two PRs (#6084 + #5817) are stacked and bound — neither functions without the other. Merge order: #6084 first onto main, then #5817 rebased onto the new main.

Local validation of the combined stack:

Full build: 5,968/5,968 targets, 0 warnings, 0 errors
Full CTest suite: 3,218/3,218 pass (1 unrelated NumericLocale skip)
All 4 SBOM CTests pass (with pip install spdx-tools for the reference-validator test)
pre-commit run --all-files passes every hook on 5,700+ files
reuse lint reports 0 non-ThirdParty compliance gaps
spdx-tools validate_full_spdx_document() passes on the generated SBOM

Phase mapping to the original 3-phase roadmap in this issue:

Phase 1 (replace NOTICE with sbom.json for ThirdParty deps) → ENH: Generate SPDX 2.3 Software Bill of Materials at configure time #5817 commit 1 (SBOM generator) + commit 2 (per-module metadata)
Phase 2 (SPDX headers on ITK source) → STYLE: Add SPDX license identifiers to all ITK source files #6084 (single commit, 5,698 files + KWStyle template)
Phase 3 (build-time sbom-build.json generated by CMake) → ENH: Generate SPDX 2.3 Software Bill of Materials at configure time #5817 commit 1 (same generator produces it)

All three roadmap phases are addressed together.

Full supporting materials (validation reports, code review, regulatory citations with URLs):

Support worktree: .claude/worktrees/pr-6063-spdx-support/
Key files: CLEANUP-PHASE-1-PLAN.md, validation-report.md, justification-expanded.md, code-review.md

Navigation Menu

Repository navigation

Generate a Software Bill of Materials at Build Time #4302

Overview

Background

Existing Efforts

Proposed Efforts

Additional Information

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Generate a Software Bill of Materials at Build Time #4302

Description

Overview

Background

Existing Efforts

Proposed Efforts

Additional Information

Activity

hjmjohnson commented on Apr 15, 2026

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

hjmjohnson commented on Apr 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions