### Overview Video :tv: [Support Additional Filtering for Scan Result Policies](https://youtu.be/ZJCXFbWT6no) ### Problem to solve We've heard a number of common challenges from customers that pertain to filtering more granular security policies. We'll work to address the top priorities in this epic. The most common challenge is confusion around our status options. Today we provide all status options in a single multi-select dropdown list. However, practically speaking, not all combinations work. New vulnerabilities cannot be already confirmed or resolved. Additionally, users often want to set policies more granularly. This UX change will simplify the policy creation process and make it more logical to configure statuses. With the new creation of Vulnerability Extraction Tool (VET)'s `False positive` label, we need to allow users to optionally choose to not require approval for findings if they have been detected as a false positive. Currently False Positives can be detected for SAST [through the VET analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#false-positive-detection) and also for the Container Scanning and Dependency Scanning analyzers with the 3rd party partner of Rezilion. Additionally, we have received feedback from users that they need additional granularity in their approvals to filter based on the age of the vulnerability. This is especially relevant when users require previously detected vulnerabilities in the `Confirmed` state to be fixed before new code can be merged in. Most commonly, customers want to set rules that align with their expected fix timelines (30, 60, 180 days, etc). This is a requirement for the US federal government for example. Lastly, users need to be able to filter vulnerabilities to only require approval when a fix is available as they may not want to block an MR if there is no known solution to the problem. This is desirable internally for dogfooding as well. ### Release post Determining which results from a security or compliance scan are actionable is a significant challenge for security and compliance teams. Granular filters for scan result policies will help you cut through the noise to identify which vulnerabilities or violations require your attention the most. Four filtering changes will streamline your workflows: 1. Status: We're updating our status rules for more intuitive enforcement of new versus previously existing vulnerabilities. A new status field `new_needs_triage` will also allow you to filter only new vulnerabilities that need to be triaged. 2. Age: Create policies to enforce approvals when a vulnerability is outside of SLA (Days, Months, or Years) based on the `detected` date. 3. Fix Available: Narrow the focus of your policy to address dependencies that have a fix available. 4. False Positive: Filter out false positives that have been detected by our Vulnerability Extraction Tool, for SAST results, and via Rezilion for our Container and Dependency Scanning results. ### Proposal The following additional filtering options will be available for scan result policies: 1. **A full list of status options.** The current list of status options is not comprehensive as it does not allow users to filter out vulnerabilities that are "newly detected and dismissed" (dismissed in the merge request itself). As the status selection has conditional logic, the status options will breakdown as follows based on the user's selection between "New" and "Previously Existing": 1. New 1. Needs Triage 1. Dismissed 1. Previously Existing 1. Needs Triage 2. Confirmed 3. Dismissed 4. Resolved 2. **The age of the vulnerability.** Policy creators will be able to create separate policies that force approvals on previously detected vulnerabilities that may have been ignored. 1. Users can choose to require approvals if the age of the vulnerability is more than or less than the selected age (X Days, weeks, months, or years) 2. Age of vulnerability can only be selected when creating a policy based on previously detected vulnerabilities. 3. **Filtering by "attribute".** An expected scenario for these filters would be to create a policy that requires approvals from the Security team only when a fix **is** available and when the vulnerability **is not** a false positive. Users will be able to use an "Is" or "Is Not" operator when defining attributes. We will join each attribute with an `AND` clause only. Note: Designs show an option to also use `OR`, but this is removed from the scope. Users may alternatively create new rules that are always joined by an `OR`, but when choosing multiple attributes in a single rule, we will always use `AND`. 1. Fix Available: Whether or not a fix is available for the vulnerability (only applies to Container and Dependency Scanning) 2. False Positive: Whether or not the vulnerability has been identified as a false positive 3. ~~Auto-resolved~~ ** Removing from current scope and will carry forward in https://gitlab.com/groups/gitlab-org/-/epics/10165+ We'll also need to include the following error states for the scope of this epic. See [UX Theme ](https://gitlab.com/gitlab-org/gitlab/-/issues/368074/designs/Alert.png)for more details. 1. The policy name cannot be empty. 2. No criteria added error. 3. You must choose at least one scanner. 4. You must set the number of vulnerabilities. 5. Action cannot be empty. ### Product Acceptance Test Cases WIP: See [Google Sheet](https://docs.google.com/spreadsheets/d/1_oc-eE-19g8jSFjOCFkxDSuJC7p4UMoUlBcRJG6X4Vo/edit?usp=sharing). ### Designs **For the complete theme design, please see the** [**design issue**](https://gitlab.com/gitlab-org/gitlab/-/issues/368074/ "UX Theme: Flexible scan result policy options") **The result looks like below.** | Condition | Dropdowns | Tooltip | Error | |-----------|-----------|---------|-------| |   |  |  | | **Possible breakdown** * `UI visual changes` * `Any number of vulnerability` * `New and previously existing vulnerabilities` * `Age criteria` * `Attribute criteria` * `Ability to add and remove criteria` | UI visual changes | Any number of vulnerability | New and previously existing vulnerabilities | Age criteria | Attribute criteria | Ability to add and remove criteria | |-------------------|-----------------------------|---------------------------------------------|--------------|--------------------|------------------------------------| |  |  |  |  |  |  | ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. Create tracking issue using the the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\--> ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Ultimate" ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> ### Links / references <!-- 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 -->