Reference to dependency in CBOM missing #2

Activity

1. thebenignhacker commented on Jul 27, 2026

   

   thebenignhacker

   on Jul 27, 2026

   Member

   More actions

   Thank you for the detailed report, and especially for the two contrasting
   examples. They made the problem obvious.

   You were right on both counts. The CBOM emitted only the algorithm component,
   carrying the dependency's version but never its name, so RSA at version
   1.3.2 was unattributable exactly as you describe.

   Fixed in #3. Each dependency is now emitted as its own library component with
   a bom-ref, and the CycloneDX dependencies graph links each algorithm to the
   library that provides it:

   pkg:pypi/cryptography@41.0.0
       -> crypto:RSA
       -> crypto:ECDSA
       -> crypto:Ed25519
   pkg:pypi/pyjwt
       -> crypto:RS256
       -> crypto:ES256
   

   Your second example surfaced a separate problem. "version": "${java-jwt.version}"
   is an unresolved Maven build property being reported as though it were a
   version. Emitting it states a version that does not exist, and the same applied
   to ranges like >=2.0 where CycloneDX expects a concrete version. Now only
   pinned versions are reported as versions. Where the constraint cannot be
   resolved to one, the version is omitted and the declared constraint is preserved
   in the component description, so the information is still there without claiming
   to be something it is not.

   Two related defects fixed in the same PR: every CBOM carried the same hardcoded
   all-zero serial number, and some primitive values were outside the CycloneDX
   enum, which fails schema validation for the whole document. The output now
   validates cleanly against the official CycloneDX 1.6 schema.
2. thebenignhacker

   closed this as completedin 89c986fon Jul 27, 2026