Analysis decisions in multiple project versions

[rkg-mm]

Current Behavior

E.g. 10 versions of the same project exist in Dependency-Track. A vulnerability is found in a component which is contained in 9 of these. Now, somebody needs to go through all versions and do the analysis decision/possibly suppression in each version separately.

Addition: If the vulnerability was suppressed, because it has no relevance for this project, and a 11th project version is added, you need to suppress it again (and for each later version again.)

Proposed Behavior

When doing analysis decisions, a checkbox should be available "Apply to all versions of this project, now and in future". If selected, the same should be applied to all currently existing project versions of the same project, and any newly added version, or later uploaded bom in any version of the same project, the same decision should be taken over.

See also: https://app.slack.com/client/T04T40NHX/C6R3R32H4/thread/C6R3R32H4-1668779395.683739

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[valentijnscholten]

I like this idea because for this very reason we are only importing 1 version of each project currently. It could be 2 checkboxes to separate for existing and future versions. Not everyone might want to apply the analysis automatically to all unseen future versions.

Did you think about the implementation? Currently every version needs its own analysis object/record. This is / can become quite inefficient. I have no idea what the long term vision with regards to project hierarchy is, but I've seen others using a "empty project without a version" to act as a parent of other projects. Could a analysis for "all" (existing and future) version be maintained at that level? Or possibly the analysis model could be changed to have a 1-N relationship with versions (or components in reality).

[rkg-mm]

Yea the implementation so far is a bit of a question for me, since I saw the same struggle with the current way the data is stored. Putting it on an upper level could become difficult UI wise probably, also it would be another struggle to get the relation to the parent which itself does not have that vulnerability..

if somebody has a good idea it would be welcome. Only Idea I have so far is checking by project name which is - as you say - could get inefficient. Though, considering how this could be queried (vulnerability found in a project > optimized DB query to find projects with same name (index on project name) with a JOIN on audit decision for that vulnerability ID and a LIMIT 1 condition) and considering that there likely are not THAT many audit decisions within the same project, I think it would not be a big issue... Only if we try to load without optimized SQL query I see a problem there.

[chovyy]

For Dependency Check, you have a suppressions.xml under version control to suppress once identified false positives in future checks. It would be cool if Dependency Track supports a simililar format which can be uploaded together with the BOM.

[syalioune]

Hey @chovyy Dependency Track kinda have the same thing with VEX. You can refer to the different links in this issue https://github.com/DependencyTrack/dependency-track/issues/2741 for examples on how to use it to achieve the same thing as Dependency Check suppressions.

[chovyy]

Thanks, @syalioune. That's look promising. I will try that.

[acdha]

Has anyone been working on tools around this? It feels like the VEX mechanism could be part of the solution but that would also require some kind of indefinite time delay to deal with BOM processing and some conditional logic for things along the lines of “suppress CVE x if optional dependency y is not installed” to avoid copy-paste errors, which starts sounding like another full service to run.

Most of the other tools of this class which I've used support having an override file in the source code, which is good for having that list follow the code as new versions are released so it feels like part of this could be having a little tooling to merge a VEX list into the BOM after #1872 is resolved, but that also raises concerns about review of that list and wouldn't help much with multiple related projects which all need to reflect some shared dependency which isn't easily updated. @nscuro's dtapac looks interesting in that regard but would have a somewhat steep usability curve for some security analysts and means running a second full authenticated network service.