Skip to content
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

fix(scan): skip false alarm for Black v>=24.3.0 (CVE-2024-21503) #4770

Closed

Conversation

JigyasuRajput
Copy link
Contributor

Fixes issue #4471 where cve-bin-tool was incorrectly flagging our installed Black version (24.8.0) as vulnerable to CVE-2024-21503 (which affects Black 24.3.0).

Changes Made:

  • In sbom_detection.py, added a condition to skip marking Black as vulnerable when its version is ≥24.3.0.
  • In test_vex.py, added a unit test (test_black_version_not_flagged) using a dummy package to ensure that Black 24.8.0 is not flagged.

Copy link
Contributor

@terriko terriko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I think this type of fix is a good idea, but I don't think this code is quite the way we want to do it. It'd be too easy for the code to balloon with a bunch of exceptions, and as written it's going to affect sbom scans but not if you scanned a requirements.txt file with the same version of black in it, so that's not great.

I think we want stuff like this to be applied more like a triage layer and possibly the definition of CVE-2024-21503 may need to be changed so this isn't occurring for anyone else.

So I guess the questions are

  1. Why is this false positive occurring? Are we mis-reading the data fro CVE-2024-21503 or is the data there claiming that it applies to black >= 24.3.0?
  2. What would we need to provide as triage to fix this? Some mapping saying that CVE-2024-21503 does not apply for >= 24.3.0? I'm guessing just using a VEX isn't going to work for that but I don't know off the top of my head how it handles version ranges. Should we be applying this triage directly to the database or as something we do after the scan is run?
  3. What's the best way to store this kind of triage so it's all in one spot and easy to edit and applies to all types of scans rather than just to sbom ones?
  4. How should we be maintaining this kind of thing if the CVE definition updates so that it's no longer needed? Should there be a test that checks and warns us if our rules are no longer needed?

I'm not sure what the right answers are here.

@terriko
Copy link
Contributor

terriko commented Mar 21, 2025

As pointed out in the bug, this issue isn't occurring any longer and I've closed it, so I'll close this PR as well.

@terriko terriko closed this Mar 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants