DependencyTrack
Offer a query language to perform searches
Current Behavior
The Dependency-Track UI has multiple views where users can filter displayed items through a search field.
For the Vulnerabilities view, here's what the search looks like:
It works fine if the user knows roughly what they are looking for (i.e., they know the vulnerability ID), but for any other query, the search is not really useful. Some example queries that users may be interested in doing:
- Vulnerabilities that where published in 2021 with severity CRITICAL
- Vulnerabilities with CVSSv3 score higher than 7, that affect 5 projects or more
- Vulnerabilities associated with CWEs 123, 456, or 789
A fuzzy search across all properties of a vulnerability is not helpful, as it will always return too much data, and makes "drilling down" very hard or even impossible.
On the technical side, text entered in the search field is sent to the API server via searchText query parameter.
Behind the scenes, searchText is made available as filter variable to the context of incoming requests. It is then up to individual query methods as to what to do with that filter value. For the Vulnerabilities example above, it will be used to construct a match ("contains") query on vulnerability IDs:
https://github.com/DependencyTrack/dependency-track/blob/924a007cd6a37d75a2c4a8ea048814975fb85fcd/src/main/java/org/dependencytrack/persistence/VulnerabilityQueryManager.java#L297-L300
The Components search is a bit more sophisticated, as it allows for filtering based on different criteria:
However, it lacks support for multiple criteria. For example, it is possible to search for:
- Components with PURL
pkg:maven/foo/[email protected] - Components with MD5 hash
3858f62230ac3c915f300c664312c63f
But it is not possible to search for:
- Components with PURL
pkg:maven/foo/[email protected]and MD5 hash not matching3858f62230ac3c915f300c664312c63f
Additionally, the current search logic primarily treats inputs with "contains" semantics. There is no way for users to decide when something should be an exact match, or a fuzzy match.
Proposed Behavior
This is similar to https://github.com/DependencyTrack/dependency-track/issues/2673.
I do not believe in adding input fields for all the various types of properties and comparison operators. It will clutter the UI, and will be hard to test.
What I'd like to see instead is support for a query language similar to Jira's JQL (as mentioned in https://github.com/DependencyTrack/dependency-track/issues/2673#issuecomment-1636459224).
It should be possible for users to search for, say, vulnerabilities using expressions like this:
published.year == 2021 && severity == CRITICAL
cvssv3 >= 7.0 && affectedProjects >= 5
It may be possible to leverage CEL. As long as the CEL library exposes the AST to us, we can "transpile" CEL expressions to JDOQL or SQL filter expressions. There is a project in Go that transpiles CEL to BigQuery filters: https://github.com/cockscomb/cel2sql
If CEL transpiling turns out to not be an option, we could investigate writing our own DSL with ANTLR4.
For a better UX, input fields for search expressions should offer autocomplete. There should be a mechanism that allows users to discover available fields (e.g. a dropdown next to the search bar).
Checklist
- [X] I have read and understand the contributing guidelines
- [X] I have checked the existing issues for whether this enhancement was already requested
Would love to see this ability for both vulnerabilities and components.
