Surface security policy violations details (Diff view) (#10975) · Epics · GitLab.org

Surface security policy violations details (Diff view)

### Release notes  ### Problem to solve  As security and compliance teams enable scan result policies, policy violations impact the ability for engineering teams to complete their work and merge their MRs. Scan result policies identify risk in an MR and require approvals by particular reviewers, such as security and compliance professionals who may need to validate the change will not introduce a significant vulnerability or a license compliance issue into production applications. This is all good and well, but the rules governing these controls can be varied, and the results can at times require time and attention from security, compliance, and engineering to understand the violation, understand the results that cause the violation, and then assess the impact and how to action the violation moving forward. This could result in approving the MR in spite of the violation, creating an issue to follow-up and address a vulnerability within an SLA, or it could be discovered that a result is a false positive or not relevant in the context of the particular repo/project. To state the problem succinctly, **it's often not evident to users of security policies today what violation is requiring action from them, if the violation itself is accurate or expected, and what exactly caused the violation**. What caused a violation can also vary. Here are a few potential scenarios that can cause a violation: - (Happy path) A policy rule may have been violated, such as when an MR attempts to introduce code that has a critical security finding from a SAST scanner. - (Not so happy path) Misconfiguration of a policy, such as scanners not matching between source and target branches and requiring approval due to an artifact not being available to evaluate. - (Not so happy path) Similar to above, an invalid rules may be created where the approvers required to review a violation don't have access to the project. This can lead to the MR being blocked and a potential vulnerability may be present, but the policy rules are invalid as they don't have eligible approvers to review the MR due to access issues. - (Not so happy path) A bug/error in security policies or the UX resulting in policies failing closed and requiring approval. Some of the states above may be "expected" from our end, but I've labeled the not so happy path items as this is not the desired result from users. The desired state is to have policies detect vulnerabilities and only when necessary create a blocking state, requiring review/approval from necessary parties. Why is this important? Understanding the dynamics of security policies, how findings are compared, and the resulting approval states builds confidence for users that when a violation occurs, the logic aligns with their expectations. By providing more clarity around which policy rules were violated, what caused the violation, and by making the logic more explicit, it will make cross-functional teams much more efficient in validating the findings are accurate, that they align with their expectations, and they can more more swiftly to take action. Without violations, security policies can feel more like a black box, leaving customers hopeful that the results will be what they expect, without giving them tools to better understand or troubleshoot behaviors. Or, in the case of system/product errors, it's more difficult to deduce and raise meaningful support tickets to get bugs address by GitLab. ### Intended users  1. [Amy, Application Security Engineer](/handbook/product/personas/#amy-application-security-engineer) 1. [Isaac, Infrastructure Security Engineer](/handbook/product/personas/#isaac-infrastructure-security-engineer) 1. [Alex, Security Operations Engineer](/handbook/product/personas/#alex-security-operations-engineer) 1. [Sasha, Software Developer](/handbook/product/personas/#sasha-software-developer) ### User experience goal  1. Violations and details related to any violations should be evident in merge requests for all personas to clearly understand which violation(s) occurred, what caused each violation, and potentially (nice-to-have) the confidence in the violation. 2. For developers, violations should also be consumable via the IDE. In a [cross-functional UX effort between Create and Sec](https://gitlab.com/gitlab-org/gitlab/-/issues/389441/), a few designs were proposed for displaying security violations: | MR - Changes tab | MR - Policy details | | ------ | ------ | | ![image](/uploads/b7cc8eee2c02978d48dbbcc9e7f82193/image.png) | ![image](/uploads/405c3cb81be0c7a372efb364dbe43fa1/image.png) | | MR - Policy drawer | MR - Filter to only policy violations | | ------ | ------ | | ![image](/uploads/fa2716c91fb34103a789cdd79068a812/image.png) | ![image](/uploads/07b493a6f3db61155b066bf59a5c377e/image.png) | ### Proposal  1. Create a list of policy violations within a given MR 2. Display policy violations in the MR changes tab 3. Allow users to open the policy drawer within the MR to view more details 4. Allow users to filter all findings in an MR to only findings that violated a security policy 5. Provide a path for users to trace back a violation to the policy it violated, including the policy rules/details to gather more context 6. [Not currently in design] We may need a generic way to display violations that are not tied to a specific finding. This may be when there's a misconfiguration or an invalid rule. 7. [Not currently in design] We could display log related detail that helps show how the evaluation logic determined the results and flagged a finding as a violation. For example, a way to trace back to the pipelines that ran the scanners that were compared. ### Further details  * A related epic discusses a plan to [Display Security Policy Errors](https://gitlab.com/groups/gitlab-org/-/epics/6770). This epic contrasts from simply displaying errors, as violations are expected and proper working behavior, but the detail available today explaining why a violation occurred is lacking. Errors, on the other hand, relate primarily to scanners not running when a scan execution policy is enabled, and gives security teams visibility into related failures. There could be some overlap in some cases between these two epics which we can further delineate as we break down the issues. ### Permissions and Security  ### Documentation  ### Availability & Testing  ### Available Tier  ~"GitLab Ultimate" ### Feature Usage Metrics  * \# of MAU that open the policy drawer within an MR * \# of MAU that filter findings by security policy violations ### What does success look like, and how can we measure that?  Primarily, our priority is to improve adoption of security policies. Gaining clarity about the behavior of policies, being able to utilize them more efficiently, and building trust in the policies working as intended will ease adoption and make it easier to successfully complete POC/POVs. A secondary success metric would be reducing the time it takes to complete a POV for security policies. A third success metric would be retention. This capability could make security policies much stickier as it builds confidence in the behavior due to the fact that it would be more observable. And the ability to more easily detect issues and raise bug requests will tighten our feedback loop and continue improving accuracy and align with customer expectations. ### What is the type of buyer?  CISO, Security Directors ### Is this a cross-stage feature?  Yes, this feature would cut across the merge request experience in ~"devops::create" ~"group::code review". ### What is the competitive advantage or differentiation for this feature? Security policies are differentiators in that they offer a single pane view for creating and managing security/compliance controls across the DevSecOps lifecycle through GitLab's single application. While we offer a single application that is tested together, we also have many integrated solutions within the platform. Security policies help to create a streamlined workflow for the security and compliance persona, while ensuring separation of duties as well as separation of concerns across the cross-functional teams. By introducing violation details, we can bring more insight into the behaviors for security/compliance teams and developers, making them more efficient in resolving vulnerabilities and managing enforcement of policies, and make it easier to self-service when issues do arise. ### Risks * This is a cross-stage effort, which often results in slower development, as more time and effort is required for collaboration across stages, aligning priorities, and allowing teams to propose changes into other team's codebases (which then require their time to review). This can extend a small 1 milestone effort into 3+ milestones. To mitigate this, we can work to start with the smallest possible MVCs with the largest value to offer. * In addition to the above, making changes to the merge request experience can have a major impact on existing customers. We'd have to increase the level of testing and quality before releasing, as we can't afford to negatively impact the performance or UX. ### Links / references   *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.*

epic