We have several supported release branches of the project which use some same versions of dependencies. A known vulnerability appears that suddenly affects many of our DT projects, but effectively it is the same error and verdict for many of them. After a human analyzes one branch in detail and confirms that other cases are identical, it makes sense to somehow export that data and apply to the other branches in one operation (as opposed to lots of checkbox and drop-down clicking and text copy-pasting).
We played with Export VEX and Export VDR, but those files seem to lack much of the information entered manually.
Per Slack discussion, "at the moment, VEX will have the current state, but lacks the entire audit trail and any comments made by users. If you need a complete export/import functionality, please raise an enhancement request on GitHub."
Proposed Behavior
Offer UI buttons and REST API to allow downloading a single or multiple component(s) which have any populated analysis properties.
A helpful option would be a way to select all components in the chosen project which have some analysis attached.
Offer UI buttons and REST API to allow uploading such files into a project, appending to its set of known analysis results. Reasonable options/tweaks for the behavior:
Ignore (default) or error-out for the components missing in the destination project: if we have a large collection of verdicts from one project branch (with many impacted components), we do not want to manually filter it and select only those components that exist in the target, adapting a copy of the file for each target project.
Apply only to components that lack any analysis results (default), or overwrite all existing matched components' results with those from the uploaded file, or if possible - merge new unique data (optional).
As a starting point, same matching as used for SBOM upload's detection of existing/new components should apply to identification of which component a verdict is for (currently based on ComponentIdentity, which includes group, name, version, cpe, purl, swidTagId). Further considerations may be the different vulnerability ID's (although it would be great to know equivalent vulns from different databases and only track one item), and perhaps matching by fewer fields if we can do so unambiguously (one project's component mentions only name/version "log4j x.y.z" and another has same name/version and also cpe... if there's only one component in each of the target and destination for upload where known fields overlap, should we consider it a good match?)
It would also be great if the document format for storage of these verdicts can be mergeable and de-duplicatable (e.g. using the CycloneDX spec and cyclonedx-cli tool), so the growing collection of verdicts can be applied to different DT instances used by the organization, tracked in Git for historic audit and reference, etc.
Originated at https://owasp.slack.com/archives/C6R3R32H4/p1717514754874479
Current Behavior
We have several supported release branches of the project which use some same versions of dependencies. A known vulnerability appears that suddenly affects many of our DT projects, but effectively it is the same error and verdict for many of them. After a human analyzes one branch in detail and confirms that other cases are identical, it makes sense to somehow export that data and apply to the other branches in one operation (as opposed to lots of checkbox and drop-down clicking and text copy-pasting).
We played with Export VEX and Export VDR, but those files seem to lack much of the information entered manually.
Per Slack discussion, "at the moment, VEX will have the current state, but lacks the entire audit trail and any comments made by users. If you need a complete export/import functionality, please raise an enhancement request on GitHub."
Proposed Behavior
Offer UI buttons and REST API to allow downloading a single or multiple component(s) which have any populated analysis properties.
Offer UI buttons and REST API to allow uploading such files into a project, appending to its set of known analysis results. Reasonable options/tweaks for the behavior:
As a starting point, same matching as used for SBOM upload's detection of existing/new components should apply to identification of which component a verdict is for (currently based on
ComponentIdentity, which includes group, name, version, cpe, purl, swidTagId). Further considerations may be the different vulnerability ID's (although it would be great to know equivalent vulns from different databases and only track one item), and perhaps matching by fewer fields if we can do so unambiguously (one project's component mentions only name/version "log4j x.y.z" and another has same name/version and also cpe... if there's only one component in each of the target and destination for upload where known fields overlap, should we consider it a good match?)It would also be great if the document format for storage of these verdicts can be mergeable and de-duplicatable (e.g. using the CycloneDX spec and
cyclonedx-clitool), so the growing collection of verdicts can be applied to different DT instances used by the organization, tracked in Git for historic audit and reference, etc.Checklist