system wide vulnerability management

[bovy89]

Hi, I would congratulate with you because that is a great project but I'm going to describe some "usability problems" that for me needs an improvement to make this project even better:

Our environment:

• dependencytrack version: 4.4
• a lot of projects - use cases:
  • in a CI environment: CI pipeline will fail if a vulnerability >= high will be found 
  • to analyze stale projects for new vulnerabilities based on latest uploaded bom

Usability problems:

1) A new vulnerability used by almost all projects has been published but not fixed yet (e.g. https://github.com/advisories/GHSA-57j2-w4cx-62h2). If a fix on our projects needs to be released it will be blocked by CI pipeline check. Right now I must suppress and manage that vulnerability on every project. It would be great if we can also manage vulnerabilities "globally": managing vulnerabilities on every project is not sustainable and leads to errors. 2) Right now we can suppress/manage a vulnerability on every project but there is not a view of active/made suppressions (I need to track it somewhere else and if combined with problem 1 that is a huge management problem). It would be great if there was a recap view with all managed/suppressed vulnerabilities so we can figure out what is suppressed and need to be patched when a fix will be released

[stevespringett]

Thanks for the suggestions. Global auditing of vulnerabilities was supported from v1.0 to v3.8 and was removed in v4.0. This was a much needed change that opens up new use cases never previously possible. One of the many issues with global auditing is that it's not possible to rely on a components cpe, purl, or coordinates for identity. These were hard lessons learned from older versions of DT. So more in-depth analysis of the components provenance, pedigree, and resulting hash values are necessary to determine if a component is the same or not. This is logic the database layer will not be able to perform, thus would have a big impact on the DT application itself if implemented. For these scenarios, many orgs assume the risk of misidentification and use simple scripts to automatically suppress findings across all projects, and have a way (based on expiration time) to un-suppress findings. Such a script could easily be created in a few minutes. There should be no reason why orgs have to manually suppress findings across their portfolio of projects.

I like the idea of having a global view of suppressed findings and a way for a centralized security team to manage that. Many orgs currently use general purpose BI tools to obtain this type of data and present in custom dashboards. But this specific capability would be a welcome addition to DT.

[bovy89]

Thanks. I was thinking about a new "allowlist" feature...for example:

allowlist > add >
- vulnerability name: GHSA-57j2-w4cx-62h2
- comment: fix not available

---> CI pipeline not blocked anymore.

From allowlist tab you can also delete/list allowed vulnerabilities.

Regards the "scripts automation" solution, do you have something ready (or just an example) in order to avoid to reinvent the wheel?

[stevespringett]

Oh, an allowlist. Thats interesting. Never occurred to me. Will need to give that some thought. Possibly doable.

I don't have any scripts handy, however, I know folks in the Slack channel have created similar script previously. Some may be able to share.

https://dependencytrack.org/slack/invite https://dependencytrack.org/slack

[eldis80]

We have a bit similar situation but in our case it's the OS level vulnerabilities that we'd like to "disable" based on our own criteria. For example CVE-2021-3711 is found in most of our projects from the base image even though it's already fixed in the Debian package we use.

I think in both of these cases there would need to be a way to modify the vulnerability itself in DependencyTrack. We would like to add some exclusion rule like if the package version is 1.1.1d-0+deb10u7 or higher then DependencyTrack wouldn't attach the vulnerability even if the CPE from NVD matches.

In @bovy89's case there could be a way to mark the vulnerability itself as excluded or attach an exclusion rule with a wildcard match to it.

[stevespringett]

DT v4.5 will have the ability to add/edit private vulnerabilities. However, the functionality is scoped to only private vulns and not vulns retrieved from public sources (e.g NVD). If we added the ability to modify public vulns, the edits would get overwritten whenever the next synchronization occurs. So modifying the affected components isn't really an option.

I do like the idea of having an exclusion rule or list which would be maintained independently of the vulnerability itself.

@eldis80 in your case, would you want the ability to openly allow CVE-2021-3711 on any project or do you want to only allow it based on the identity of a component (PURL or CPE)?

Additionally, do you want an automated analysis decision and audit trail made for every affected component in every project? For example, CVE-2021-3711 would be identified on the component, but an automated analysis decision would have been made marking the finding as 'not an issue' with an explanation that it was in the allow list, and the finding being suppressed so that metrics are not impacted?

[eldis80]

@stevespringett We don't want to openly allow it in every project but rather add some exclusion rule based on PURL/CPE. I think we'd prefer that the vulnerability wouldn't even get attached to project/components if the exclusion rule matches. We currently have a script we can use to suppress the findings but it reappears whenever there's a new version of the openssl Debian package and therefore a new component for the project. It doesn't happen very often in this case but the script can only be run retroactively so it's a bit of a PITA.

[bovy89]

Any update on that? (at least a global allowlist)

[bovy89]

Another example of CVE affecting a multitude of projects where a global allowlist would be useful: https://github.com/FasterXML/jackson-databind/issues/3590

[SaberStrat]

We'd also love a centralized way to whitelist vulnerabilities for multiple projects, but not necessarily all. So we'd definitely like this system wide ignore list to have some kind of filter for vulnerabilities.

Managing 'unfixable' vulnerabilties centralized within Dependency-Track would be definitely be more elegant than a DIY script. At the very least placed before metrics get calculated and notifications sent out.

[nscuro]

IMO for use-cases like this one (and many others, like policies) we need something like OPA. Some form of lightweight, sandboxed script or DSL. Otherwise we'll end up in configuration-/input-field-hell.

I built an external integration that uses OPA to make automatic analysis decisions (https://github.com/nscuro/dtapac), precisely for the reason that allowlists and denylists do not work in practice. There are many factors that can go into an analysis decision, and oftentimes you want the decision to be scoped, like @SaberStrat is implying.

OPA can be embedded into Go applications, or used as an external service. DT is a Java application, and adding yet another external service is most likely not something we want, so maybe alternatives like GraalVM's JavaScript could work.

[valentijnscholten]

I think a global suppress/exclude/whitelist list would already be very helpful and is easy to implement and use. A scripting framework sounds harder to implement and also harder to use. Not everyone dealing with these audit decisions is able to or willing to write scripts to "simple exclusions".

[lsoumille]

Having this webhook mechanism is indeed a nice way of handling decisions based on several inputs but having a global static filter on the dependencytrack side would ease management of global unwanted findings

[SaberStrat]

@nscuro I’d take what I can get. If it’s a scripting field, so be it. But I’d probably also be grateful for a regex field under every entry in theVulnerabilities menu, in line with all the other regex fields used to filter stuff in DT (like defining internal components in the settings). Might not be the best UX solution ever, but it works and would be consistent with the rest of DT. Or, a drop down filter-button like “Suppress for projects” like in the notification filters, which would look and feel even better.

Though I can’t tell which would be truly easier to implement and use in practice.

[stgarf-sx]

Dependency-Track is a wonderful project but this is a huge pain point that leads to many many false positives being presented in the interface which leads to a lot of cleanup work (since obviously auditors want to see accurate data! among other reasons).

I also have the problem of multiple "false positive" CVEs detected across a large number of projects and there's no easy way to manage all of them at once. Ideally there'd be a sort of checkbox next to each CVE for each project in a global vulnerability view where you could choose which projects you wanted to manage the status of the CVE for and then mass edit those projects to suppress/validate etc.

I see there is a PR in the works with some enhancements on the way but I think bulk-management should be apart of that PR/enhancement.

[sithmein]

We are in a situation where we use one library in many projects which has many versions (and more to come). Due to bad NVD and OSSIndex metadata the component associated with a CVE which is clearly wrong (apparently the maximum version is not taken into account). Therefore it would be useful to add global suppressions, similar as it's possible in Dependecy Check but may be a bit more fine-grained. In this concrete example it would be tremendously useful if I could add simple rule that says "if componentA.version >= x.y.z then ignore CVE-xxxx-yyyy". I believe making use of PURL in this contexts makes a lot of sense since, therefore every part of a PURL should be usable in such expressions. Then you can also suppress false positives that result from a wrong component detection. One possible way would be to have custom metadata on CVEs, where you could add a ignore list based on a PURL. You can already use regular expressions for PURLs when creating policies so why not use the same concept for such an ignore list. At least in the first iteration because version (ranges) are probably a bit awkward to model with regexes but it should work. The evaluation process would be quite simple then: if a CVE has been found for a component check whether the component's PURL matches the CVE's ignore list and if so drop it.

[Selaron]

These two things would help me either:

1) Ability to suppress a vulnerability on a given component within a given project on current and future versions of that component.

2) Ability to audit a given CVE on all affected projects at once, including management of (1).

When using OWASP dependency-check I can provide suppressions via xml file as described in #2579 but there is no equivalent available on DT.

[nscuro]

Hey all, we're currently looking into this and have put some documentation down here: https://github.com/DependencyTrack/hyades/issues/930

High-level overview:

• Use CEL expressions instead of RegEx / PURL equality to match with components
• Allow for an entire analysis (state, justification, vendor response, details) to be applied, instead of just suppression
• Application of analyses populates the audit trail, just as if it was done manually
• Integrate this directly into the vulnerability analysis process, such that suppressed findings won't trigger notifications or block CI pipelines
• Policies can be managed externally (e.g. in Git), or as usual via UI

Feedback and any kind of feedback would be much appreciated! :)