How to handle disputed CVEs in your vulnerability management process
2 views
Skip to first unread message
Olle E Johansson
Sep 30, 2025, 3:31:39 AM9/30/25
to c...@owasp.org
Hi!
There is a lot of discussion on the OSS-SECURITY mailing list about CVE-2023-51767 - where there is a report of a vulnerability in OpenSSH and the OpenSSH teams disputes it heavily. It’s not the first such discussion, and not the last either.
Now, if you have OpenSSH in your SBOM it’s likely that this CVE will show up, and it is also likely to never be fixed. In some cases, customers will require a fix or some other regulation or internal company policy will require a fix, beacuse there’s a CVE.
How can this be handled in vulnerability databases and various management platforms?
As a manufacturer, how can I document it properly and convince my customers there’s nothing to fix here?
Does the current vulnerability databases handle this kind of situations well?
/O
There is a lot of discussion on the OSS-SECURITY mailing list about CVE-2023-51767 - where there is a report of a vulnerability in OpenSSH and the OpenSSH teams disputes it heavily. It’s not the first such discussion, and not the last either.
Now, if you have OpenSSH in your SBOM it’s likely that this CVE will show up, and it is also likely to never be fixed. In some cases, customers will require a fix or some other regulation or internal company policy will require a fix, beacuse there’s a CVE.
How can this be handled in vulnerability databases and various management platforms?
As a manufacturer, how can I document it properly and convince my customers there’s nothing to fix here?
Does the current vulnerability databases handle this kind of situations well?
/O
Reply all
Reply to author
Forward
0 new messages