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.
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 apply policies 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 my dependencies have reported vulnerabilities, I want to learn more about the vulnerability cause and implications, so I can make an informed decision on taking action 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 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 I need to audit 3rd party licenses and dependencies, I want to be able to provide inventory of licenses and dependencies for the auditor, so I can have them on record for auditing purposes and be able to share them with auditors and customers. | view issue | |||
| Dependency Scanning | When I want to see how dependencies are related, I want to view them grouped by file, so I can access the information faster. | … |
Shared
| Product Category | JTBD | Walkthrough | Recommendations | Score | Rescore |
|---|---|---|---|---|---|
| Shared | When I use the GitLab security feature for the first time, I want to configure all necessary features, so that the security team can start using them for GitLab projects. | 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 |
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 | Becka Lippert |
| Dynamic Analysis | DAST | Camellia Yang |
| Fuzz Testing | Fuzz Testing | Camellia Yang |
Compliance & Auditing
| Group | Features | Designer(s) |
|---|---|---|
| Composition Analysis | Dependency Scanning, Container Scanning, License Compliance | Kyle Mann |
Threat Insights
| Group | Features | Designer(s) |
|---|---|---|
| Vulnerability Management | Vulnerability Management | Andy Volpe |
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.
We follow the GitLab workflow with additional dates and actions that directly tie to our work.
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:
We use devops::stage_name and UX labels to indicate issues that need UX effort. We work on user flows that often span multiple categories so we review each of these issues prior to the start of a milestone to determine the design assignee or assignees.
UX + devops::stage_name: It is a shared UX effort and the engineering effort has not been determined.UX + devops::stage_name+Category::name: There is a DRI for UX (can be shared) and clear engineering collaboration.UX + devops::stage_name+ UX debt: Used for follow-up issues when a proposed design was de-scoped or not implemented as planned.See our UX Workflow page for more on how we use labels.
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.
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:
Our Secure and Defend UX YouTube channel includes UX Scorecard walkthroughs, UX reviews, group feedback sessions, team meetings, and more.
