Open denniebouman opened 2 weeks ago
Notes:
Differentiating between "last analysis" and "last upload" is only relevant when the analysis can change without the source code (or other artefacts) changing. This is mainly the case with tools that track known vulnerabilities in dependencies.
DependencyTrack seems to use the metrics.lastOccurrence
field from the /api/v1/project/project_uuid
endpoint response for the "Last Measurement" timestamp displayed in the UI. This field contains a unix timestamp, like the lastBomImport
field.
The current SourceUpToDateness
metric is supported by these sources.
From a migration point of view it seems best to introduce the new "analysis up-to-dateness" metric and then add support for it on a source by source basis.
Is your feature request related to a problem? Please describe. DependencyTrack can display when an SBoM was last uploaded and when it was last analyzed (regardless of the upload date). The first date is currently used for the “source up-to-dateness” metric. Because DependencyTrack scans possible (new) vulnerabilities using a scheduler (separate from a more recent SBoM upload), this (execution) date is also important, but serves a different purpose, more as a “health check”.
Describe the solution you'd like Add a new metric type, which can report on the “last executed/analysis date” and use the last analysis date specific for DependencyTrack.
Multiple sources may be able to be mapped to this new metric, for example: SonarQube last analysis date, PerformanceTest last execution date, OWASP last analysis date, etc. Source-up-to-dateness could then remain a typical naming convention for example a file in Gitlab.
Proposal for the new metric name: Last run date? Last executed date?
Describe alternatives you've considered Change the current metric to use the last analysis date, but both serve a different purpose.