Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Secure UX


Secure tools help your team follow and enforce security best practices effortlessly as part of the DevOps cycle. The Secure UX team’s goal is to provide the best experience in taking pre-emptive security measures before deploying your code, while the Defend UX team’s goal is to provide the best experience in keeping your application safe after your code is in production. See the Defend and Secure UX page for more about our team and how our two teams work together.


We have different user types we consider in our experience design effort. Even when a user has the same title, their responsibilities may vary by organization size, department, org structure, and role. Here are some of the people we are serving:

Generally, developers are the users of the vulnerability reports in the MR/pipeline while security professionals are the users of the Security Dashboards.

UX scorecards

Primary jobs to be done (JTBD)

Static Analysis

Product Category JTBD Walkthrough Recommendations Score Rescore
SAST When committing changes to my project, I want to be made aware if I am adding risk through vulnerable code, so that I know my changes can be merged without increasing the risk of my project. view issue view issue D  

Composition Analysis

Product Category JTBD Walkthrough Recommendations Score Rescore
License Compliance When new licenses are added to a project I want to be aware so I can commit work that is compliant with my organization's rules. view issue view epic D  
License Compliance When my organization has license compliance rules to follow I want to be able to whitelist or blacklist licenses so that I can ensure any new code merged in a project is in compliance. view issue view issue F  
License Compliance When a merge request is disallowed, I want to know why, so I can resolve the issue and proceed with the MR. view issue   C  
License Compliance When new vulnerabilities are detected in a merge request, I want to disallow the merge request, so the team can review the vulnerabilities to resolve or decide on the next steps. view issue   D  
Dependency Scanning When dependencies are out-of-date, I want to be made aware so I can update them to reduce potential security vulnerabilities and avoid the potentially high cost of larger updates. view epic      
Dependency Scanning When my dependencies have reported vulnerabilities, I want to learn more about the information, so I can make an informed decision on taking action against on how to proceed. view issue      
Dependency Scanning When my organization has a compliance policy with dependencies, I want to be aware if I’m breaking a company policy, so I can make sure my project dependencies are in compliance with my org compliance. view issue      
Dependency Scanning When I need to audit 3rd party licenses and dependencies, I want to be able to view them, so I can have them on record for auditing purposes and be able to share them with auditors and customers. view issue      


Product Category JTBD Walkthrough Recommendations Score Rescore
Shared   view issue view issue C  
Shared When reviewing vulnerabilities for multiple projects, I want to see them all in one location, so that I can prioritize my efforts to resolve or tirage them while seeing the larger picture. view issue view issue D  
Shared When I want to configure my security tools, I want to be able to configure them to address my own business risk policies, so that I can be assured my company is monitoring risk based on our business risk policies. view issue      


Team structure

We've divided the Secure stage into dedicated experience groups to align with a similar split undertaken by our engineering and PM counterparts.

Security Testing

Group Features Designer(s)
Static Analysis SAST, Secret Detection, Malware Scanning Becka Lippert
Dynamic Analysis DAST, IAST Camellia Yang

Compliance & Auditing

Group Features Designer(s)
Composition Analysis Dependency Scanning, Container Scanning, License Compliance Kyle Mann

The Secure & Defend UX teams work closely together and have shared coverage in the following areas:

This segmentation gives us a better opportunity to:

Read more about how we've created these dedicated experience groups here.

How we work

We follow the GitLab workflow with additional dates and actions that directly tie to our work.

Team meetings

Our Secure UX weekly meeting is to discuss topics relevant to Secure design, UX, and research. Some example topics could include:

Some topics are better suited for a dedicated meeting, and should be created on an as-needed basis:

Labels we use

We have 4 scoped labels to help us identify which experience group a particular issue falls into and which designer should be subsequently assigned.

Secure UX::Shared

Secure UX::Security Testing & Scanning

Secure UX::Compliance & Auditing

Secure UX:: Prevention & Detection

See our UX Workflow page for more on how we use labels.

Problem and solution validation issues

When working on a workflow::problem validation or workflow:solution validation issue requiring implementation in the next 2 releases, ensure there is a placeholder implementation issue. This issue must be attached to the epic, have a tentative milestone and the corresponding labels, particularly the group label, so that it shows up on the issue boards for our counterparts.

Our strategy

The Secure UX team is working together to uncover customers core needs, what our users’ workflows looks like, and defining how we can make our users tasks easier. Our strategy involves the following actions:

Additionally, we value the following:

The source of truth lives with shipped features, therefore we:

Follow our work

Our Secure and Defend UX YouTube channel includes UX Scorecard walkthroughs, UX reviews, group feedback sessions, team meetings, and more.