[IDEA] feat: library mode

[jkowalleck]

Is your feature request related to a problem? Please describe.

if i build a SBOM for a library, i do not want to have non-bundled component listed as if they were concrete.
These dependencies are extraneous/"external" and the version of them is not clear - it is resolved on install-time .
Also, transitive dependencies of those are not clear until install-time.

This should be reflected in the SBOM.

Describe the solution you'd like

Spec: CycloneDX/specification#321

add a way to have

• only the bundled dependencies and the direct dependencies as components in the SBOM result.
  • to be discussed, as python packaging does not declare this at the moment - see in contrast PEP770
• non-bundled' components must have no version.
• non-bundled's components must have a version range - specification#321
• non-bundled are marked as "external" - specification#321
• the dependency composition completeness is set to "incomplete_first_party_only" - see https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-SBOM-en.pdf page 59

UX

to be discussed - see #1041 (comment)

option to exisitng subcomamnds

option could be called (list of ideas)

• --library-mode
• --mark-extraneous/--mark-externals
• add your idea in the comments

new option MUST imply --omit dev

new option MUST be disabled bu default
new option MUST be marked as experimental in help page
new option might set `--mc-type=library'

Describe alternatives you've considered

• instead of adding an option to existing sub-commands, we might add a specific sub command. -- to be discussed.
• we could make it, so that the existing option `--mc-type=library' causes this behavior by default, but that would be a breaking change

Additional context

for libraries, non-bundled components are "external" - this is discussed in specification#321

pyrproject.toml knows the concept of

• platdform-depenedncies -- Feature Request: Include Python version in SBOM #597
• direct-dependencies
• optional dependencies (might be controlled by "extras")
• dev-dependencies - no intention to be shipped.
  might shadow all of the above on build-time

the library-moed SBOM genertated by the tool might be merged with an extra SBOM to create an entire SBOM for PEP770

Contribution

• I am willing to provide an implementation
• I will wait until somebody else implements it

[jkowalleck]

see discussion #1040 and others

[jkowalleck]

still undecided hot the user experience should look like

proposed:

enrich the currently existing subcomamnds

cyclonedx-py environment --library-mode --pproject ... # this just makes no sense: analyzing an env is not needed to get the unspecific component declarations in an package manifest

cyclonedx-py requireemnts --library-mode --pproject pyproject.toml ... # shure, why not
cyclonedx-py pipenv       --library-mode --pproject pyproject.toml ... # shure, why not
cyclonedx-py poetry       --library-mode --pproject pyproject.toml ... # shure, why not

alternatives

dedicated subcommand

• manifest ...
cyclonedx-py manifest --pproject pyproject.toml ...
  • ❗ this might require implementation of alternative pyproject manifest standards for uv, poetry2 etc
    ...
• wheel
  • cyclonedx-py wheel ... something.wheel
  • ❗ analyzes the wheel description and searches for runtime depednencies

---

❗ adding a dedicated subcommand would probably the most non-breaking UX that gives us the most freedom - implementation wise and on the UX side