Security Analyzer Exclusions

Overview

Cybersecurity products enforce detection rules to identify flaws/weaknesses/vulnerabilities. Detection rules aren't perfect and can generate false positives. Users can control false positives via exclusions. In some cases, exclusions may apply before security flaws are identified--so the flaws never generate findings at all (exclude this path, exclude this rule). In other cases, exclusions may be apply after flaws are detected--so the flaws are filtered out/ignored (sometimes temporarily for a specified time period), of the results. Some products allow customers to both exclude rules and exclude findings, but managing exclusions and ignores are two different concepts.

Goal

This issue aims to propose an ideal, consistent analyzer workflow that can be applied to all GitLab analyzers.

Initial steps are to document what types of objects each analyzer might need to add to an exclusion list--whether excluded before or after a scan.

Context

The SD group is building a UI-based exclusion list, which will enable customers to exclude specific patterns, values, or paths. Solution validation and competitive research ( https://gitlab.com/gitlab-org/gitlab/-/issues/480066, https://gitlab.com/gitlab-org/gitlab/-/issues/464686) so far has indicated that most users prefer analyzer-specific lists, rather than one unified list that contains a wide variety of objects. If we build analyzer-specific exclusion lists, we want a design that can be extended to all analyzers (if it makes sense to) in order to provide customers with a consistent experience.

Outlining potential exclusions on a per-analyzer basis ahead of time allows us to ensure the design could be extended to other analyzers in the future.