### Release notes ### Problem to solve To adhere to regulatory standards and to provide evidence of compliance, I need to be able to generate a report for auditors detailing the last date/time each of my repositories were scanned by each security scanner. I would leverage this data to also action against projects that are out of compliance to bring them into compliance and ensure that scanners are properly enabled/enforced to run. ### Intended users ### User experience goal ### Proposal Create new adherence checks, one per scan type. The check would confirm that each scanner is properly configured (either through the CI configuration or via scan execution policies) and whether or not there have been compliance violations, which would require tracking the latest scan to determine the last datetime the particular scanner ran within the repo. These checks would initially be enabled within the `GitLab Standard` but in the future we'd anticipate it could be linked to multiple different standards. Checks include ([aligned with our marketing page here](https://about.gitlab.com/stages-devops-lifecycle/secure/)) : * SAST * Secret Detection * Dependency Scanning * Container Scanning * License Compliance * DAST * API Security * Fuzz Testing * Code Quality | New Security Scan compliance checks | |-------------------------------------| | {width="988" height="566"} | ### Further details 1. **Date the security scan last ran:** We should be able to easily indicate the last time each of the scan jobs executed. This value may be different than the current supported field "date since last status change". 2. **Reporting window:** The user needs a way to know if the projects are successful based on a time interval. For example, a scan check may satisfy multiple frameworks/requirements, however the audit window may vary for each. To comply with one framework, the user may need to look back 6 months. For another, they may need to look back one year. The time interval may be a 1 year period to evaluate if they were compliant last year. Therefore, we may need additional capability within the reporting to set the reporting window. 3. **Export window:** The reporting window should also affect the date range for creating an export. 4. **API support:** Users should be able to programmatically generate a report without using the UI to create a .CSV export. 5. **What determines success for compliance?** 1. The minimum requirement is to show proof a scan of a given type ran. 2. To prove successful configuration of the scanner and that the scan ran with the proper configuration may require additional deeper evaluation and we'll consider out of scope for the initial checks. ### Permissions and Security ### Documentation ### Availability & Testing ### Available Tier ### Feature Usage Metrics ### What does success look like, and how can we measure that? ### What is the type of buyer? ### Is this a cross-stage feature? ### What is the competitive advantage or differentiation for this feature? ### 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 -->