DependencyTrack / DependencyTrack/dependency-track
Track "First Seen" Date for Vulnerabilities
- Dominant language
- Java
- Stars
- 4.2k
- Forks
- 811
- Avg merge
- 8h 39m
- Merged PRs (30d)
- 237
Description
### Current Behavior:
As of v4.3.2 provides:
* "Published" date for vulnerabilities on the Vulnerabilities page.
* "Attributed On" date for individual vulnerabilities, displayed on "Audit Vulnerabilities" tab of project page.
There is no way to see when a vulnerability first entered the portfolio.
If a BOM is uploaded with vulnerable component X then an attribution date will be recorded
If a new project is created every date for the next 99 days with component X then there will now be 100 attribution dates. Every single one will be different... and only one will be the "original" (ie, oldest) date. The only way to know which is the oldest is to manually inspect each project, do some heavy API parsing, or query the database directly.
### Proposed Behavior:
Record "First Seen" date for each vulnerability that affects the portfolio, and display the date on the "Vulnerabilities" page.
**Use case one**. Compare "Published" and "First Seen" dates. Is there a lag between the two? To illustrate, at time of writing, CVE-2021-29425 is displayed in DT with a Published Date of 13 Apr 2021. But after 4 months it is still not in OSS Index data. But it will be... some day. But when?
**Use case two**. If every instance of a vulnerability in the portfolio is addressed then there will be no more attribution dates for that vulnerability. But the "First Seen" date would remain. Thus, if the vulnerability is reintroduced to the portfolio, one would know that it has been seen before... it is not actually "new".
**Use case three**. Notifications configured ONLY for "NEW_VULNERABILITY" are alerting on every attribution. This creates a lot of noise and (for me) make notifications unusable. This was reported as #389. Perhaps the notifications should be suppressed if "First Seen" is already populated (or something along those lines)?
Contributor guide
Assessment
This issue has not been assessed yet.