Request to publish new version

[vmatyus]

Dependency check reported CVE-2024-21503 in black, this way it is suggested to update to use version 24.3.0.

I see the update already was made on the main branch thanks to dependabot.

I would like to request a new release from this package, because there is a need for the vulnerability fix in our project.

[vmatyus]

Turned out there is no need for a new release here.
Thanks for your work.

[vmatyus]

Based on the answer from Dependency Check's support team, they suggest to release a new version from autohooks-plugin-black which uses at least black 24.3.0
See their response.

[aikebah]

A new release is not what I suggested, though it would solve the false positive that occurs right now.

[vmatyus]

@aikebah Would you share your point of view regarding what other options are available as a solution? Could you elaborate it more?

[aikebah]

The regular way for open source projects in case of a false positive (something that is almost unavoidable due to how ODC links software to CPEs which are the key to 'known vulnerabilities' with the NIST NVD data) is to file a 'False-positive Report' type issue with the project, which typically leads to a suppression added into the scanner after a triage of the report.

For python they typically take a bit longer to process as one of the maintainers needs to build and test the suppression. Other language ecosystems have an automatic suppression generation that allows a low-effort triage and approval by one of the project maintainers to be automatically added by the automation to the suppressions.

So the recommended course of action is to open your dependencycheck report (to be able to copy some values over that are asked for in the false positive report) and use the information within to open a new issue of type 'False Positive report' in the DependencyCheck project.

With the information requested in that form the DependencyCheck we would be able to create an appropriate rule within the hosted suppressions file so that the autohooks plugin is no longer detected as black itself (while still checking the transitive black dependency (which is already at a fixed version as you indicated in your question ticket)

[vmatyus]

@aikebah Based on your feedback, I created this False Positive report: jeremylong/DependencyCheck#6570

Please note that I could not find the CPE value, this way I wrote there unknown.
Could you please review my issue and provide me with details if I need to modify on something?

[aikebah]

@vmatyusGitHub The identifiers we would need (as far as present) can be found in the dependency-check-report.html that the CLI should create when you run it and it signals the FP.

I would expect an 'identifiers' section in there, which would look similar to (copied this from an unrelated other FP report's dependencycheck run:

The 'package-url' for the FP report should be the value from such an identifiers section that starts with pkg:, the CPE is expected to be listed in there as well, otherwise I would not expect the False positive to be raised on the library.

Feel free to share the report with me (stripped of sensitive data if needed) at aikebah-github-issues (at) aikebah.net if with this extra info you can't find the items in the report.