Fix CycloneDX vulnerability-component linking (#980)#981
Fix CycloneDX vulnerability-component linking (#980)#981
Conversation
Add affects field to vulnerabilities to link them to their components. Previously bom-refs didn't match, making it impossible to trace vulnerabilities to affected packages. Fixes pypa#980
| # BomTarget expects str in type hints, but accepts BomRef at runtime | ||
| affects=[BomTarget(ref=c.bom_ref)], # type: ignore[arg-type] |
There was a problem hiding this comment.
I don't love the idea of ignoring the type hints here, even if it incidentally works -- that strongly suggests undocumented API behavior that could change at any time.
Is there a reason we can't use c.bom_ref.value instead? From the API docs, that seems to produce a str that should correspond to the right value to pass into a BomTarget.
There was a problem hiding this comment.
The thing is, the approach depends on whether bom_ref is manually set vs auto-generated.
When components have auto-generated bom_refs (which is the case in pip-audit), c.bom_ref.value returns None
The .value approach works when bom_ref is manually set as a string ( like in CycloneDX/cyclonedx-python-lib#547 )
Since pip-audit uses auto-generated bom_refs (no manual bom_ref= assignment), we need to pass the BomRef object itself rather than its .value property. The type mismatch is a quirk of the cyclonedx-python-lib API - the type hint says str, but the implementation handles BomRef objects for auto-generated refs.
The # type: ignore is unfortunate but necessary to work around the library's type annotation not matching its runtime behavior.
There was a problem hiding this comment.
I also noticed that the Vulnerability class itself accepts bom_ref: str | BomRef (as shown in the docs), suggesting the library has a pattern of accepting both types even when type hints indicate otherwise. This supports using the BomRef object directly for auto-generated refs.
( https://cyclonedx-python-library.readthedocs.io/en/latest/autoapi/cyclonedx/model/vulnerability/index.html )
There was a problem hiding this comment.
Ah, that's kind of not ideal -- do you think we could get those type hints fixed upstream? My experience with this CycloneDX dependency is that there have been significant breaking changes over time, so I'm hesitant to merge something that works unless it's actually encoded in the types.
As a stop-gap, I'd be okay with merging this if we also add a "backstop" test, i.e. add a test for the CycloneDX APIs themselves to ensure they don't deviate between releases. That way at least the tests will fail on dependency updates, which will give us advance warning if they change things 🙂
There was a problem hiding this comment.
hmm good idea will write the test
woodruffw
left a comment
There was a problem hiding this comment.
Thanks @AryanBagade! One question, otherwise this looks great to me. I appreciate you sending a patch for this!
Add affects field to vulnerabilities to link them to their components. Previously bom-refs didn't match, making it impossible to trace vulnerabilities to affected packages.
Fixes #980
Changes
affectsfield toVulnerabilityobjects usingBomTargetBomTarget(ref=c.bom_ref)