feat: optional CBOM generation via cdxgen, plus CBOM pipeline recipes - #300
Draft
aurangzaib048 wants to merge 8 commits into
Draft
feat: optional CBOM generation via cdxgen, plus CBOM pipeline recipes#300aurangzaib048 wants to merge 8 commits into
aurangzaib048 wants to merge 8 commits into
Conversation
CBOM_GENERATE=true (action input cbom-generate) generates a Cryptography Bill of Materials from the LOCK_FILE project via cdxgen --include-crypto (Java and Python projects, JS/TS source analysis, keystores, certificates) and uploads it with bom_type=cbom. The flag implies BOM_TYPE=cbom and requires LOCK_FILE; Docker images, pre-authored SBOM_FILE input, and conflicting BOM_TYPE values are rejected. Augmentation and enrichment stay off, matching the passthrough contract. Only the cdxgen filesystem generator claims include_crypto inputs, so the orchestrator can never hand CBOM generation to a generator that would produce a plain SBOM. Pins @cyclonedx/cdxgen to ^12.0.0 (was git master).
Contributor
There was a problem hiding this comment.
Pull request overview
Adds first-class, opt-in CBOM generation to the sbomify-action pipeline by routing a “crypto inventory” request to cdxgen, while preserving the existing verbatim-upload contract for non-SBOM artifact types.
Changes:
- Introduces
CBOM_GENERATE/cbom-generateto generate a CBOM fromLOCK_FILEvia cdxgen--include-crypto, and forcesBOM_TYPE=cbomwith guard rails in config validation. - Threads a new
include_cryptoflag through the generation protocol and ensures non-cdxgen generators decline such inputs. - Pins
@cyclonedx/cdxgento a released semver range and documents CBOM recipes in the README, plus adds tests for the new behavior.
Reviewed changes
Copilot reviewed 13 out of 14 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
sbomify_action/cli/main.py |
Adds cbom_generate config, validation guard rails, and passes crypto flag into lockfile generation path. |
sbomify_action/generation.py |
Threads include_crypto through public generation helpers into GenerationInput. |
sbomify_action/_generation/protocol.py |
Extends GenerationInput with include_crypto flag. |
sbomify_action/_generation/generators/cdxgen.py |
Appends --include-crypto for filesystem generation when requested; declines crypto inputs for image generator. |
sbomify_action/_generation/generators/{trivy,syft,cyclonedx_py,cyclonedx_cargo}.py |
Ensures non-cdxgen generators decline include_crypto inputs. |
tests/test_config.py |
Adds config validation tests for CBOM_GENERATE behavior. |
tests/test_generation_plugin.py |
Adds generator-level tests for --include-crypto argument behavior and non-cdxgen declination. |
README.md |
Adds CBOM documentation section and example workflows/recipes. |
action.yml |
Adds cbom-generate action input and maps it to CBOM_GENERATE env var. |
package.json |
Pins @cyclonedx/cdxgen to ^12.0.0. |
bun.lock |
Updates lockfile to reflect the pinned cdxgen version and transitive changes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…stry capability Review findings on the CBOM generation PR: CBOM_GENERATE was read only by load_config(), which production never calls; the Click cli() entrypoint had no such option, so the shipped input was a silent no-op (a plain SBOM uploaded with no error). cli() now carries --cbom-generate/--no-cbom-generate with the standard bool-envvar callback and threads it into build_config; regression tests drive the real entrypoint via CliRunner for the env var, the flag, and the default. Crypto generation is now an opt-in registry capability instead of an opt-out guard pasted into seven supports() methods: the registry skips any generator without supports_crypto=True for include_crypto inputs, so a future generator can never silently satisfy a CBOM request with a plain SBOM. Only CdxgenFsGenerator opts in.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 11 out of 12 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (2)
sbomify_action/generation.py:98
- The new
include_cryptoparameter is not documented ingenerate_sbom()’s docstring, so API consumers won’t know how to request CBOM/crypto-asset inclusion.
include_crypto: bool = False,
sbomify_action/generation.py:153
process_lock_file()now acceptsinclude_crypto, but the docstring doesn’t describe it. This makes the new CBOM/crypto flag easy to miss for callers using the public API.
include_crypto: bool = False,
…ument include_crypto, decline crypto in image generator
…availability in registry crypto test
Additional-packages-only mode would otherwise proceed and upload an empty document labeled cbom when additional packages are configured.
…to when it is a method
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 11 out of 12 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
sbomify_action/cli/main.py:352
- In the CBOM_GENERATE validation, the allowlist includes an empty-string BOM_TYPE (""), but BOM_TYPE is already validated against VALID_BOM_TYPES earlier in validate(), and "" is not a valid value there. This makes the "" branch effectively unreachable and can be removed to avoid confusion.
if self.cbom_generate:
if self.bom_type not in (None, "sbom", "cbom"):
…CBOM_GENERATE Both steps rewrite the generated document; a CBOM must be preserved as generated, and package dependencies/hashes belong to SBOM output.
aurangzaib048
marked this pull request as draft
July 24, 2026 15:39
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #291. Closes #290.
What
CBOM_GENERATE=true(action inputcbom-generate) generates a CBOM from theLOCK_FILEproject via cdxgen--include-cryptoand uploads it withbom_type=cbom. Covers Java and Python projects plus JS/TS source analysis, keystores, and certificates.patternverified against their action.yml), and pass through any other CycloneDX CBOM verbatim.@cyclonedx/cdxgento^12.0.0(was tracking git master).Guard rails
CBOM_GENERATEimpliesBOM_TYPE=cbom; a conflicting explicitBOM_TYPEis rejected.LOCK_FILE;DOCKER_IMAGEand pre-authoredSBOM_FILEare rejected (container CBOMs stay parked per container-image CBOMs via cbomkit-theia (stretch) #292).CdxgenFsGeneratorclaimsinclude_cryptoinputs; every other generator declines them, so the orchestrator can never satisfy a CBOM request with a plain SBOM.Tests
LOCK_FILE, rejects docker image, pre-authored file, and conflicting type; forces augment and enrich off.--include-cryptopresent and absent on the cdxgen argv; cyclonedx-py, syft, and trivy decline crypto inputs.