<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> # Problem to solve As a security analyst or maintainer, I want the ability to extend the rules for each analyzer on a project-by-project basis, so that I can reduce false positives or provide coverage beyond the rules shipped by default by GitLab. Today, we rely on open source software to be both the detection engine as well as the detection rules. However, we have a growing need to allow us (or customers) to extend those rules. This would allow us a mechanism to try out rules that reduce false positive rates, provide coverage we do not currently offer, or both. ## Requirements It is convenient to think of this feature at two levels of granularity: rules and rulesets. ### Rules - Customers should be able to define new rules that are specific to their paradigm. - If customers provide a rule whose identifier matches a rule already included, it should replace the existing rule. - Customers should be able to disable rules, excluding them from the analyzer's generated reports. - Rules to be disabled should be identifiable by any identifier the pre-packaged rule provides. - Customers should *NOT* be able to modify detection patterns of existing rules. Instead they should disable existing rules and provide a new pattern with a unique identifier ### Rulesets - Customers should be able to declare new rulesets that should be included. - If customers provide a ruleset whose identifier can be matched to one already included, then the provided ruleset replaces the one already included. - Provided rulesets do not change the types of files the analyzer will scan. - Customers should be able to declare 1-N custom rulesets, with _N_ to be set by the engineering team. - Customers should be able to disable rulesets, excluding all the rules in the set from the analyzer's generated reports. - Rulesets to be disabled should be identifiable by an identifier provided by the pre-packaged ruleset. - Customers should be allowed to declare rulesets to be included from arbitrary location(s), i.e. the semgrep rule registry, provided the container has access to those locations. ### Other considerations - Not every analyzer will be able to support the full custom ruleset interface. Analyzers lacking support for portions of the above should gracefully degrade rather than fail. ## Terminology - [`analyzer`](https://about.gitlab.com/handbook/engineering/development/secure/glossary-of-terms/#analyzer) - software that performs a scan, usually wrapping a scanner - `rule` - a detection condition for identifying findings and vulnerability classification metadata - `ruleset` - a collection of rules (pre-packaged or customer provided) - [`scanner`](https://about.gitlab.com/handbook/engineering/development/secure/glossary-of-terms/#scanner) - software scanning for vulnerabilities ### Release notes - Original release notes MR (13.5) - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/64769