feat: add sbom Makefile target

[MarkAtwood]

Summary

Adds a make sbom target that produces CycloneDX and SPDX SBOM files for wolfsentry.

• Extracts version from WOLFSENTRY_VERSION_MAJOR/MINOR/TINY macros in wolfsentry/wolfsentry.h
• Enumerates sources from src/*.c (sorted)
• Hashes each source file
• Calls gen-sbom (located via GEN_SBOM or WOLFSSL_DIR/scripts/gen-sbom)
• wolfsentry is standalone (no wolfssl dependency), so WOLFSSL_DIR is only needed to locate gen-sbom

Usage

```sh

With WOLFSSL_DIR (points gen-sbom location):

make sbom WOLFSSL_DIR=/path/to/wolfssl/source

Or with explicit gen-sbom path:

make sbom GEN_SBOM=/path/to/wolfssl/scripts/gen-sbom
```

Outputs: wolfsentry-<version>.cdx.json, wolfsentry-<version>.spdx.json

Requirements

• gen-sbom from a wolfssl tree containing scripts/gen-sbom (available on the feat/sbom-embedded branch of wolfssl)
• python3 on the build host

Test plan

• make sbom WOLFSSL_DIR=...
• Verify CDX and SPDX output files are produced

[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 a make sbom target to generate CycloneDX and SPDX SBOM artifacts for wolfsentry.

Changes:

• Extracts wolfsentry version from wolfsentry/wolfsentry.h and uses it to name SBOM outputs.
• Locates and invokes gen-sbom, generating both CycloneDX and SPDX JSON outputs.
• Captures compiler preprocessor defines into a temp header for gen-sbom input.

---

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

[dgarske]

Make sure this feedback is addressed. If it is mark resolved on those.
#85 (review)
@MarkAtwood and @sameehj

[jackctj117]

Skoll Multi-Scan Review

Modes: review + review-securityOverall recommendation: REQUEST_CHANGES
Findings: 5 total — 5 posted, 0 skipped
3 finding(s) posted as inline comments (see file-level comments below)
2 finding(s) not tied to a diff line (full detail below)

Posted findings

• [High] [review+review-security] README documents make install-sbom / make uninstall-sbom targets that don't exist — README.md:238-241
• [Medium] [review] --options-h captures bare compiler predefines, not wolfSentry's build configuration — Makefile:581-592
• [Low] [review] SBOM version extraction uses bare awk instead of the $(AWK) variable — Makefile:551

Findings not tied to a diff line

Documented .spdx tag-value output is never generated; SBOM_SPDX_TV is dead code

File: Makefile:554, README.md:236
Function: sbom
Severity: Medium
Category: Logic

The Makefile defines SBOM_SPDX_TV = wolfsentry-$(SBOM_VERSION).spdx but never references it — the gen-sbom invocation only passes --cdx-out (.cdx.json) and --spdx-out (.spdx.json). No third .spdx tag-value file is produced, and the success message only echoes the two JSON files. However, README.md line 236 lists three outputs: wolfsentry-\<version>.cdx.json, wolfsentry-\<version>.spdx.json, and wolfsentry-\<version>.spdx. Users following the docs will expect a .spdx tag-value file the target never creates. This is both a doc/behavior mismatch and an unused build variable (the review-security mode additionally flagged SBOM_SPDX_TV as dead code at Info severity; consolidated here). The stricter Medium severity is kept.

Recommendation: Reconcile docs and recipe: either pass the appropriate gen-sbom flag to emit the tag-value .spdx file (and echo it in the success message), or drop .spdx from the README output list and remove the unused SBOM_SPDX_TV variable.

Referenced code: Makefile:554, README.md:236-239 (4 lines)

---

Generated SBOM files are not removed by make clean

File: Makefile:484,558-599
Function: clean / sbom
Severity: Low
Category: Convention

The sbom target writes $(BUILD_TOP)/wolfsentry-\<version>.cdx.json and .spdx.json into BUILD_TOP, but CLEAN_RM_ARGS (line 484) is not updated to remove them, so make clean leaves these artifacts behind. Every other build product in the tree is registered for cleanup.

Recommendation: Add $(BUILD_TOP)/$(SBOM_CDX) $(BUILD_TOP)/$(SBOM_SPDX) (and the .spdx tag-value file if it is ever produced) to CLEAN_RM_ARGS so make clean fully cleans the build tree.

---

Review generated by Skoll

[jackctj117]

🔴 [High] README documents make install-sbom / make uninstall-sbom targets that don't exist · Logic

The new README section instructs users to run make install-sbom and make uninstall-sbom, but the Makefile diff in the same PR only adds a single .PHONY: sbom target. A grep confirms no install-sbom, uninstall-sbom, or datadir rules/variables exist anywhere in Makefile, Makefile.analyzers, or Makefile.maintenance. Any user following the docs will hit make: *** No rule to make target 'install-sbom'. Stop.. Additionally, the comment references $(datadir)/doc/wolfsentry/, but this project has no datadir variable — it uses INSTALL_DIR/INSTALL_LIBDIR/INSTALL_INCDIR — so the documented install path is also fictional. Severity views differ: the review mode rates this High/BLOCK (docs advertise non-existent make targets and will fail outright); the review-security mode rates it Low. The stricter view is kept because the documented commands are guaranteed to fail.

Fix: Either implement install-sbom/uninstall-sbom targets (mirroring the existing install/uninstall pattern, using INSTALL_DIR/DESTDIR) or remove these two lines from README.md until the targets exist. Do not ship docs that reference non-existent make targets or a fictional datadir path.

[jackctj117]

🟠 [Medium] --options-h captures bare compiler predefines, not wolfSentry's build configuration · Logic

The recipe generates the options header via $(CC) -dM -E -I'$(SRC_TOP)' -x c /dev/null, which dumps only the compiler's built-in predefined macros for an empty translation unit. It does not pass $(CFLAGS), so none of wolfSentry's actual build-time feature macros (WOLFSENTRY_NO_JSON, WOLFSENTRY_SINGLETHREADED, WOLFSENTRY_NO_IPV6, WOLFSENTRY_LWIP, etc.) are reflected in the file passed as --options-h. If gen-sbom's --options-h is meant to record how the library was configured, this produces a misleading options set. The Makefile already produces exactly such a file: $(OPTIONS_FILE) ($(BUILD_TOP)/wolfsentry/wolfsentry_options.h, generated by scripts/build_wolfsentry_options_h.awk from the real CFLAGS), which would be a far more accurate source.

Fix: Confirm what gen-sbom expects from --options-h. If it is the build configuration, pass the existing $(OPTIONS_FILE) (adding it as a prerequisite of the sbom target) instead of a bare compiler-defines dump; if only a compiler baseline is intended, document that.

[jackctj117]

🔵 [Low] SBOM version extraction uses bare awk instead of the $(AWK) variable · Convention

The Makefile defines AWK := awk at the top (line 22) and uses $(AWK) elsewhere (e.g. line 311). The new SBOM_VERSION line invokes awk directly, breaking the established convention and defeating the point of the AWK override variable.

Fix: Use $(AWK) to stay consistent with the rest of the Makefile: SBOM_VERSION := $(shell $(AWK) '/^\#define WOLFSENTRY_VERSION_MAJOR/{maj=$$3} ...