Policy-Driven Code Reviews

Role: Lead Designer
Team: 2 PMs, 1 EM, 1 Mid-level Designer
Result: 35% decrease in time spent reviewing security findings

TL;DR

The problem

Security findings in GitLab Merge Requests (MRs) were overwhelming developers and security teams. A severity-based system flooded MRs with hundreds of results, making distinguishing business-critical vulnerabilities from less relevant ones difficult. Planned technical limits on the number of findings risked hiding critical issues entirely.

The challenge

We needed a way to reduce noise without compromising security—developers needed clarity, and security teams needed control.

The solution

Instead of showing findings based on severity alone, we linked security findings to policy violations:

Only vulnerabilities that violated security policies were surfaced in MRs.
Non-policy findings were deprioritized but remained accessible.
A new filtering system allowed teams to customize their security priorities.

My role

As Lead Designer, I:

Led contextual inquiries with developers, security engineers, and compliance officers to uncover pain points.
Facilitated cross-functional collaboration between security, engineering, and product to define a scalable solution.
Designed the policy-driven filtering system, shifting security reviews from severity-based noise to policy-driven clarity.
Built an interactive prototype that surfaced only policy-violating findings, making security reviews faster and more actionable.
Conducted usability testing to validate the new system, ensuring it improved efficiency without sacrificing security.

The impact

Cut security findings per MR by up to 60%, reducing alert overload.
35% decrease in security review time, improving efficiency.
Zero business-critical vulnerabilities were hidden due to UI limitations.
Developers and security teams reported greater clarity and ease of use.

Key lesson

Showing less information can actually improve security. Developers don’t need to see every finding—just the ones that matter. By shifting to a policy-driven model, we made security reviews faster and more effective and ensured critical vulnerabilities were never ignored.

Situation

Security vulnerabilities play a critical role in software development, but how they surfaced in GitLab Merge Requests (MRs) was causing real problems for developers and security teams.

At the time, security findings in MRs were listed solely by severity, overwhelming developers with hundreds of results and making it difficult to distinguish critical vulnerabilities from less relevant ones. Security teams feared that important issues were getting lost in the noise. The problem became urgent when GitLab’s engineers planned to cap the number of findings shown to maintain performance. Without a smarter filtering system, this risked hiding business-critical vulnerabilities, allowing dangerous issues to be merged unnoticed.

Security and Compliance teams needed a better way…

…to surface the vulnerabilities that mattered while keeping the system scalable. As the lead designer, I was responsible for redesigning the experience so that security reviews were efficient, effective, and safe.

Task

The challenge was twofold. First, we needed to drastically reduce the number of findings displayed in an MR so that developers were no longer overwhelmed. Second, we had to ensure that business-critical vulnerabilities were never hidden due to technical constraints.

Rather than showing all findings based on severity alone, we needed to tie security findings to the policies they violated. This would allow us to filter out non-relevant issues, ensuring that only the vulnerabilities that directly impacted compliance and security policies were prominently surfaced.

If successful, this change would:

Reduce the number of security findings displayed in MRs, eliminating analysis paralysis.
Ensure that business-critical vulnerabilities are never ignored or hidden.
Prevent developers from merging code with unresolved compliance violations.

The outcome would be measured by:

A significant reduction in the number of findings surfaced in an MR without impacting security.
A decrease in time spent reviewing security findings, making the process more efficient.
Zero instances of business-critical vulnerabilities being missed due to UI limitations.

Action

To understand the problem, I led contextual inquiry studies with developers, security engineers, and compliance officers. It quickly became clear that developers weren’t ignoring security findings out of neglect—they were overwhelmed. Meanwhile, security teams struggled with severity-based sorting, as some “Critical” issues were low-risk, while “Medium” findings violated key policies.

With these insights, we collaborated across design, engineering, and security to shift from a severity-first model to a policy-driven approach, mapping out a new system that prioritized compliance violations.

Instead of displaying every security issue detected in an MR, we introduced a system that automatically filtered out non-relevant findings, ensuring that developers only saw vulnerabilities that explicitly violated their organization’s security policies.

End-to-end vulnerability detection model, used to show how the system worked prior to the changes

I isolated the aspects we would be improving and used this to communicate the new workflow

Early wireframe used to communicate the initial concept to engineering and product counterparts

I built an interactive prototype that surfaced only policy-violating findings within the MR, providing clear inline indicators for:

Which policy was being violated
Why the finding mattered
What action was needed

Non-policy findings were deprioritized, reducing alert overload while remaining accessible if needed.

Testing

Remote testing confirmed that policy-based filtering significantly reduced cognitive overload, helping developers focus on critical issues while security teams enforced compliance more effectively. Based on feedback, we introduced severity-based sorting for added flexibility. In-person testing with GitLab’s engineering teams further validated the approach, showing a notable drop in review times. Most importantly, business-critical vulnerabilities consistently surfaced as top priorities, ensuring they were never overlooked.

Result

The new policy-aware security findings UI was not just a success but a testament to our team’s dedication and problem-solving skills, leaving us with a sense of accomplishment and pride.

Designs highlighting the design patterns and states we’d be introducing to the workflow

Merge request — overview

Merge request — changes, collapsed inline finding

Merge request — changes

Merge request — changes, filter step 1

Merge request — changes, filter blockers

Merge request — changes, filter applied

Merge request — changes, policy violations

Merge request — policy violations, finding details

Merge request — finding details with policy drawer

Sample specification of the states that were delivered to the engineering team

Sample specifications of the states in the code diff, delivered to the engineering team

By tying security findings to policy violations, we cut the number of findings displayed in MRs by up to 60% (internally), providing significant relief from the overwhelming flood of security alerts that had previously paralyzed developers and security teams.

At the same time, this change saved the product from a potentially disastrous situation. The engineering team had already planned to limit the number of findings shown in an MR to maintain performance. Still, without our redesign, this would have meant randomly hiding security findings based on an arbitrary cutoff. Instead, our new policy-driven approach ensured that business-critical vulnerabilities always surfaced, preventing significant security risks from being merged undetected.

The impact was undeniable:

35% decrease in time spent reviewing security findings, making security reviews faster and more efficient. (Internal benchmark)
Zero instances of business-critical vulnerabilities being missed due to UI limitations.
Positive feedback from developers and security teams, who found the new system both easier to use and far more effective than the previous severity-based approach.

Conclusion & lessons learned

This project reinforced a key lesson: showing less information can improve security. Developers don’t need to see every single security finding—they need to see the ones that matter.

By prioritizing policy violations over severity, we reduced noise, improved efficiency, and prevented critical vulnerabilities from slipping through the cracks.

It also highlighted the importance of design and engineering collaboration. Without our design intervention, the planned technical limit on security findings could have accidentally hidden dangerous vulnerabilities. Instead, by working closely with engineers and security teams, we created a solution that improved usability and ensured the integrity of GitLab’s security review process.

What’s next

Looking ahead, there are still opportunities to refine this system further. Future iterations will introduce AI-powered recommendations, suggest remediation steps based on policy violations, and allow teams to customize their security policies dynamically.

Ultimately, this project was not just about improving security findings—it was about protecting the security of the product itself, ensuring that GitLab users can ship secure, compliant code with confidence.