feat: mark SBOM from `requirements` as "incomplete"

[jkowalleck]

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

when generating an SBOM from a requirements.txt, it is currently not planned to pull transitive depednencies.
therefore, the SBOM might be incomplete.
this shall eb stated via CycloneDX compositition

A requirements file might be a complete, accect set of all depeendnecies, including constriants and such.
Or it might be just a list of first-level/promary/direct runtime dependencies - lacking the transitive dependncies and constraints.

Describe the solution you'd like

add a CLI option to set completeness according to spec - https://cyclonedx.org/docs/1.4/json/#compositions_items_aggregate

if this flag is present: generating an SBOM from a requirements.txt,
for the root component: the dependency composition completeness is set to the given value

Describe alternatives you've considered

/

Additional context

guide

• https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-SBOM-en.pdf page 59

requires

• the implementation of data models for composition
  • see [TRACKING] Complete support for CycloneDX v1.4 cyclonedx-python-lib#581

Contribution

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

[TayfurYldz]

I'd like to take this. I'll keep it focused on the requirements source: add the CycloneDX composition that marks dependency completeness as incomplete_first_party_only by default, expose the requested aggregate override through the CLI using the spec-supported values, and add focused CLI/output coverage across supported SBOM formats. I'll follow the repository's DCO and AI-disclosure requirements and run the relevant tox checks before opening a PR.

[TayfurYldz]

I traced this through the currently supported model dependency before changing the CLI and found an upstream blocker: cyclonedx-python-lib 11.12.0 still leaves Bom.compositions as a TODO, and CycloneDX/cyclonedx-python-lib#607 is the existing draft PR that owns that model/serialization support. Implementing #898 here today would therefore require bypassing the library and post-processing serialized JSON/XML, which I don't think would be an appropriate or maintainable fix. I won't introduce that workaround or hold this issue as claimed; this should be implemented cleanly once the library exposes compositions (or if maintainers prefer a different dependency path).

[jkowalleck]

re: #898 (comment)

thank you for pointing this out.
this feature is not ready, as the needed data models for composition dont exist.