Selective allow / ignore lists for vulnerability management
Problem to solve
Every organization's security needs are unique. The findings from GitLab's Secure scanners or those of an integrated 3rd party are a critical part of a mature security strategy. However, not all findings will apply equally to each organization's specific security policies and practices. There are cases where it makes sense to automatically exclude or ignore a specific vulnerability or weakness type in at a Project, Group, or even Instance level. For example, there may be a commonly used library that has known web socket vulnerabilities. But if your organization does not use the web socket functionality—or has a mitigating control such as a firewall rule to block inbound web socket traffic—these vulnerabilities will continue to persist even though they do no require direct remediation and will show up with each new project added that uses the same library. Without a way to set up such proactive "ignore lists", engineering and security teams must continue to manually dismiss the same vulnerabilities over and over.
Intended users
User experience goal
I should be able to create and manage rules for an ignore list at an Instance, Group, and Project level. Rules defined at a higher level are automatically inherited by all levels below. I should also be able to definitively tell when a detected vulnerability has been ignored because it matched one of these lists.
Proposal
Further details
Cascading Rulesets
As an example of how the rules cascade, an Instance-level rule would cascade down to all Groups and Projects. I can also override an inherited rule as follows:
- disable the inherited ruleset and define a new local ruleset
- cascading still applies to the new ruleset; if I disable an Instance ruleset at the Group level, any child Projects will inherit the new Group ruleset (and have the Instance ruleset disabled)
- extend the inherited ruleset by defining an additional local ruleset
- cascading still applies to the new ruleset; if I create a new Group level ruleset, any child Projects will inherit both the new Group ruleset and the active Instance ruleset
When I am creating a ruleset, I can do so by specifying an identifier, file/directory path, or a specific filename. Identifiers must be exact (e.g. CVE-2020-123 or CWE-456). Paths and filenames should allow for basic wildcard matching such as *
to specify any character.
It is also possible that a vulnerability will match more than one ruleset. In this case, we should consider letting the user see all of the matching rules. It should be clear at which level each ruleset was applied.
Ignored Status
There needs to be a way to definitively tell when a detected vulnerability matched a ruleset. Since these vulnerabilities are intended to be ignored and not require human intervention first, they should go right to a "closed" state (like a Dismissed or Resolved vulnerability). One suggestion is to make a new status, something like Ignored
. It also needs to be easy to determine which ruleset caused the ignore. For instance, if I ignore something on a Project but the matched ruleset was actually inherited from the parent Group, this should be clear.
Retain Change History
Rulesets will evolve over time as individual rules are added, modified, and even disabled/removed. We need to store a complete change history so that ignored vulnerabilities will always still point at the exact rule(s) that was triggered. It will be necessary to include the timestamps of the rules as well so it is clear when the triggered rule was in effect.