Withdrawn vulnerabilities still showing up

[rkg-mm]

Current Behavior:

Recently I stumpled several times over vulnerabilty reports by Dependency-Track, which are actually withdrawn and marked as such in the vulnerability databases. Dependency-Track does still show these as vulnerable.
For example:
GHSA-8v27-2fg9-7h62

Steps to Reproduce:

Add for example NPM package static-eval 2.1.0 as dependency, and see vulnerability results.

Expected Behavior:

GHSA-8v27-2fg9-7h62 should not be reported, since it is withdrawn.

Environment:

• Dependency-Track Version: 4.4.2
• Distribution: Docker

[nscuro]

Marked as enhancement b/c "handling withdrawn vulnerabilities" appears more like a feature than a defect. In any case, definitely something we should take into account.

[jerrylogansquare]

We also noticed this too, sort of pain to address these 'withdrawn' vulnerabilities. It really screws up our metrics gathering and having to explain 'oh no, that one critical vuln is not really a vuln' etc. This is no fault of DT of course. Should we be badgering Github Advisory Database maintainers to remove?

[msymons]

I do not think that advisories should be removed... that would lead to confusion when vulnerabilities just poof from VEX, etc.

I think that it is important to be able to mantain a full audit trail of such "state changes".

Remember also that this problem will affect more than just GHSA. I have seen withdrawn CVE. Then there's Snyk, Sonatype OSSIndex, etc.

I would expect analyser APIs to handle this, and then DT be able to process things correctly. And maybe it would be possible to also argue for an enhancement to the VEX part of the cyclonedx specification?

[msymons]

I have done even more thinking (I know, always dangerous).

I believe that a fix for this should be done properly and that means a tweak to VEX that would then allow DT to perform more nuance traige. Thus, I logged CycloneDX/specification/issues/168

Perhaps DT could then add functionality to automatically update audit analysis (state) to Rejected?

[rylyade1]

@msymons am I assuming correct that this ticket is blocked by CycloneDX/specification#168 or you have planned this already for a specific version.

[msymons]

@rylyade1, the enhancement request for the specification was added to the v1.5 milestone and a PR raised. An RFC was issued 3 days ago. This will stay open for 28 days (total) before the PR can be merged.

The v1.5 specification has an ETA of Q2 2023 (this is not secret... it was in a webinar earlier today 😄 )

Once the specification is implemented then that will inform DT developers on how to correctly go about implementation: how to handle importing VEX and how to generate VEX correctly, whether UI changes are needed, etc

Remember also that it might be necessary to chase analysis providers (OSS Index etc) to support provision of such status in their APIs.

FYI @ken-duck (Sonatype)

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.