-
-
Notifications
You must be signed in to change notification settings - Fork 579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Take CycloneDX 1.2 patches into account when analysing CVE exposure #919
Comments
I'm going to move this out a bit. CycloneDX v1.4 will likely include some updates to the way it handles vulnerabilities and it would be best to wait for v1.4 to be released so that DT can align. |
I'd be happy to help out with this one. |
Hi, is there any progress in shifting information about the status of the cves in dtrack over the sbom? I just saw the option to use the combination of cycloneDX and vex, but I can't figure out how to do it if I want to upload it once, because the referenzes are missing. Has someone a solution for getting patched yocto cves into dtrack directly? |
Whilst I have re-assigned this enhacement request to the 4.9 milestone, I have also labelled it as "help wanted". PRs are always welcome. On the plus side, understand that a re-assignment means that 4.8 will be seen a wee bit quicker, all other things being equal. |
Hey @nscuro, it would be great if we could plan this into a milestone again! 🙂 Afaik there currently still isn't a "cleaner" way of handling CVE patches on the build system side than:
Or am I missing something? |
CycloneDX 1.2 have added support for Pedigrees such commits and patches. It is possible to specify that a patch/commit resolves vulnerabilities. This can make sense in some scenarios where patching components in a build system is preferred as a better option than upgrading the component (short term)
It would be great if this information could be taken into account when analysing CVEs for the components in DT, and that those CVE ids listed as resolved in an imported BOM is regarded as resolved by DT as well. The exact resolvent category to use in this case I am not sure of. I see that when auditing a CVE these possible values could be specified when suppressing the CVE
Not sure if any one of them fits. I guess from a monitoring point of view, it would be nice to get to know what CVE has been patched.
Current Behavior:
Proposed Behavior:
The text was updated successfully, but these errors were encountered: