feat: add make sbom target

[MarkAtwood]

Adds make sbom and a cmake sbom target to wolfMQTT, producing CycloneDX and
SPDX output for CRA compliance. Customers asking for an SBOM can then self serve
(support tickets 22020, 22165).

Usage

autotools:

./autogen.sh && ./configure
make
make sbom WOLFSSL_DIR=/path/to/wolfssl/source

cmake:

cmake -B build -DWOLFSSL_DIR=/path/to/wolfssl/source .
cmake --build build
cmake --build build --target sbom

Outputs: wolfmqtt-<version>.cdx.json, wolfmqtt-<version>.spdx.json,
wolfmqtt-<version>.spdx. make install-sbom installs them under $(docdir);
plain make install does not, so the SBOM is opt in.

Requirements

• WOLFSSL_DIR points at a wolfssl source tree containing scripts/gen-sbom,
  which has been on wolfssl master since feat: SBOM generation and OmniBOR build provenance (CRA compliance) wolfssl#10343 merged.
• python3 and pip install spdx-tools on the build host.

Design

scripts/sbom.am is the canonical fragment from wolfSSL/wolfssl, vendored
byte-identical; diff scripts/sbom.am <wolfssl>/scripts/sbom.am is empty.
Makefile.am declares only the wolfMQTT-specific inputs. Keeping it verbatim
means fixes to the canonical recipe apply here by re-copying, with no local
divergence to reconcile.

Feature macros come from the generated wolfmqtt/options.h via
SBOM_OPTIONS_H rather than config.h, because wolfMQTT uses no AC_DEFINE.

Both build systems stage an install and hash the library that actually gets
installed, record wolfSSL as a dependency component, and validate the SPDX with
pyspdxtools. CI exercises both paths and asserts the wolfSSL DEPENDS_ON
relationship, so an SBOM that silently dropped the dependency fails the build
rather than passing on file existence alone.

The two build systems agree on package metadata, license, option fingerprint and
the wolfSSL dependency. The recorded file name and checksum differ by design,
since autotools installs the SONAME-versioned library and cmake an unversioned
one, and each hashes what it actually installs.

Changes since the last review

• Re-vendored scripts/sbom.am from the canonical unified copy, per @sameehj.
  The previous copy predated feat: SBOM generation and OmniBOR build provenance (CRA compliance) wolfssl#10343 and was missing
  SBOM_CONFIG_H, the AM_CFLAGS/CFLAGS capture, and sbomdir = $(docdir).
• cmake: pass --config $<CONFIG> to cmake --install. Without it, multi-config
  generators (Visual Studio, Ninja Multi-Config) fall back to Release and the
  target fails on a library built in any other configuration.
• cmake: record the wolfSSL dependency component, which this path was omitting
  while autotools recorded it. Passed behind a gen-sbom --help probe, mirroring
  scripts/sbom.am, so an older gen-sbom still emits a valid SBOM.
• cmake: derive the installed artifact directory rather than assuming lib, so
  a Windows DLL is found where CMake actually routes it.
• CI: added a cmake job and a content assertion on the dependency relationship.
• Dropped the AGENTS.md rewrite and the AI/ build guides that had accumulated
  on this branch. They were unrelated to SBOM and the build documentation they
  added duplicated README. This PR now has zero deletions.

Verified

• autotools: autogen.sh, configure, make, make sbom all exit 0;
  pyspdxtools validates the SPDX; PackageLicenseDeclared: GPL-3.0-or-later;
  feature macros captured from wolfmqtt/options.h; wolfSSL recorded at 5.9.2.
• cmake: single-config and multi-config both exit 0. The multi-config failure
  above was reproduced before the fix and confirmed resolved after.
• The older-gen-sbom fallback was exercised with a stub that hides
  --dep-wolfssl from --help; it degrades to a valid SBOM without the
  dependency instead of failing.
• The new CI assertion was checked for vacuousness: it passes on the fixed SBOM
  and fails on one built without the dependency.

[Copilot]

Pull request overview

Note

Copilot couldn't run its full agentic review because no GitHub Actions runner was available. Make sure your repository has a runner available to run Copilot's review, or add a copilot-setup-steps.yml file specifying one with the runs-on attribute. See the docs for more details.

Adds new autotools make sbom workflow to generate and install SBOM artifacts (CycloneDX + SPDX) for CRA compliance, plus updates repo guidance/docs.

Changes:

• Add SBOM-related make sbom, make install-sbom, make uninstall-sbom targets (staging install, calling gen-sbom, validating SPDX).
• Extend configure.ac to expose libtool version components and discover SBOM tooling (python3, pyspdxtools, git).
• Add/update contributor and build documentation under AI/, plus refresh AGENTS.md and ignore common AI tool local files.

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
configure.ac	Exposes version components + finds SBOM tool executables for substitution into make rules
Makefile.am	Implements SBOM generation/validation and install/uninstall targets
AI/contributing.md	New contribution guidelines (workflow, CI rules, testing)
AI/build-windows.md	New Windows build guide
AI/build-linux.md	New Linux/macOS build guide
AI/build-embedded.md	New embedded/RTOS build guide
AGENTS.md	Replaces prior agent guidance with repo overview + links to new docs
.gitignore	Ignores common AI-tool local configuration directories/files

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[embhorn]

Hi @MarkAtwood - Please address the Copilot feedback first

[embhorn]

Skoll Code Review

Scan type: review
Overall recommendation: REQUEST_CHANGES
Findings: 8 total — 8 posted, 0 skipped
8 finding(s) posted as inline comments (see file-level comments below)

Posted findings

• [High] CMake sbom target uses shell redirection > which does not work in add_custom_target COMMAND (VERBATIM) — CMakeLists.txt:516-517
• [Medium] CMake sbom target uses cmake -E rm which requires CMake 3.17 but project minimum is 3.16 — CMakeLists.txt:535-536
• [Medium] CMake sbom target hardcodes libwolfmqtt.so, breaking static / macOS / Windows builds — CMakeLists.txt:525
• [Medium] New Linux build doc recommends non-existent autotools flags --with-wolfssl / --with-wolfssl-tree — AI/build-linux.md:46-49
• [Medium] AGENTS.md states GPLv2, contradicting the GPLv3-or-later licensing used everywhere else (including this PR) — AGENTS.md:5
• [Medium] New CMake sbom target has no CI coverage — .github/workflows/sbom.yml:88-163
• [Low] CMake and autotools feed different inputs to gen-sbom --options-h, undercutting the 'byte-comparable SBOM' claim — CMakeLists.txt:502-517
• [Low] pull_request branches filter '*' misses slash-containing base branches — .github/workflows/sbom.yml:6-7

Review generated by Skoll

[embhorn]

Hi @MarkAtwood

Very cool! I was able to generate the SBOM files.

Please review the skoll comments and then it should be ready.

## Document Information
SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: wolfmqtt-2.0.0
DocumentNamespace: urn:uuid:d3437452-0edc-5202-a2e4-3089e486b663

## Creation Information
Creator: Organization: wolfSSL Inc.
Creator: Tool: wolfssl-sbom-gen-1.2
Created: 2026-07-10T10:15:17Z

## Package Information
PackageName: wolfmqtt
SPDXID: SPDXRef-Package-wolfmqtt
PackageVersion: 2.0.0
PackageSupplier: Organization: wolfSSL Inc.
PackageDownloadLocation: https://github.com/wolfSSL/wolfmqtt
FilesAnalyzed: false
PackageChecksum: SHA256: d6a8b093aba36f2e1abb6c2ed429df9ed113e4dea493ac21764ccfb99ad9d4ef
PackageLicenseConcluded: GPL-3.0-or-later
PackageLicenseDeclared: GPL-3.0-or-later
PackageCopyrightText: Copyright (C) 2006-2026 wolfSSL Inc.
PackageComment: Build configuration defines: ENABLE_MQTT_TLS, SIZEOF_LONG, WOLFMQTT_BROKER, WOLFMQTT_DISCONNECT_CB, WOLFMQTT_MAX_QOS, WOLFMQTT_PROPERTY_CB, WOLFMQTT_V5
ExternalRef: SECURITY cpe23Type cpe:2.3:a:wolfssl:wolfmqtt:2.0.0:*:*:*:*:*:*:*
ExternalRef: PACKAGE-MANAGER purl pkg:github/wolfSSL/wolfmqtt@v2.0.0
ExternalRef: SECURITY advisory https://github.com/wolfSSL/wolfmqtt/security/advisories

## Package Information
PackageName: wolfssl
SPDXID: SPDXRef-Package-wolfssl
PackageVersion: 5.9.2
PackageSupplier: Organization: wolfSSL Inc.
PackageDownloadLocation: https://github.com/wolfSSL/wolfssl
FilesAnalyzed: false
PackageLicenseConcluded: GPL-3.0-only
PackageLicenseDeclared: GPL-3.0-only
PackageCopyrightText: NOASSERTION
ExternalRef: PACKAGE-MANAGER purl pkg:github/wolfSSL/wolfssl@v5.9.2

## Relationships
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-Package-wolfmqtt
Relationship: SPDXRef-Package-wolfmqtt DEPENDS_ON SPDXRef-Package-wolfssl

## Annotations
Annotator: Tool: wolfssl-sbom-gen-1.2
AnnotationDate: 2026-07-10T10:15:17Z
AnnotationType: OTHER
SPDXREF: SPDXRef-Package-wolfmqtt
AnnotationComment: wolfssl:sbom:hash-kind=library-binary

Annotator: Tool: wolfssl-sbom-gen-1.2
AnnotationDate: 2026-07-10T10:15:17Z
AnnotationType: OTHER
SPDXREF: SPDXRef-Package-wolfmqtt
AnnotationComment: wolfssl:sbom:hash-source=lib

[sameehj]

@MarkAtwood

SBOM generation is standardized on the canonical scripts/sbom.am fragment in wolfSSL/wolfssl#10343 (merged). The canonical was deliberately unified to be a superset — it now supports both options.h (via SBOM_OPTIONS_H) and config.h/AM_CFLAGS.

Review: This PR's fragment is the older 206-line copy. It has the SBOM_OPTIONS_H branch wolfMQTT needs (feature flags come from wolfmqtt/options.h, not config.h), but it's missing the SBOM_CONFIG_H override, the AM_CFLAGS/CFLAGS capture, and sbomdir = $(docdir).

How to address: Re-vendor the unified canonical verbatim. It keeps SBOM_OPTIONS_H, so nothing is lost:

cp /path/to/wolfssl/scripts/sbom.am scripts/sbom.am
diff scripts/sbom.am /path/to/wolfssl/scripts/sbom.am # must be empty
Confirm Makefile.am still sets SBOM_OPTIONS_H = $(builddir)/wolfmqtt/options.h, then re-run make sbom WOLFSSL_DIR=... and verify the generated SBOM still captures the wolfMQTT feature macros.

[embhorn]

Looking good. Just a couple suggestions.

[embhorn]

Is this eventually going to make it into wolfSSL? It seems short sighted to document the PR in the Readme

[embhorn]

wolfMQTT does not require wolfSSL if configured with --disable-tls. I suggest adding that config as a test case here (and expecting no dependencies).