We’re designing an experience that enables contributors to commit their most secure work and to protect what they have in production. This is done by merging security into the DevOps process, giving development teams more ownership, commonly referred to as DevSecOps. The experience brings cross-functional stakeholders together to make better, faster, and more security-oriented decisions. We are doing this by focusing the experience on automation, education, empowerment, and shifting security to the left.
Automation referrs to convention over configuration that helps draw a clear path for the user to produce meaningful results. When it comes to web security, no application will ever be 100% secure. That’s why we are focused on integrating automation into every step of the user’s journey, taking the guesswork out of configuration to open up more time on what’s important: resolving known vulnerabilities and identifying attacks or threats.
Education for our users so they understand security basics and are aware of security needs in their applications. We want our users to know where vulnerabilities or threats have been detected, visualize the implications, present resources to understand the problem, and provide the tools to facilitate informed decisions about next steps.
Empowerment for all users to resolve security issues is essential as cross-functional departments share ownership of security. Our tools strive for an experience where the developer is responsible and the security team is accountable for the organization's security.
Shifting left is taking things like QA and other processes typically found later in the ops cycle and moving them to development. Resulting in security problems being addressed earlier and more often.
Organizations of all sizes benefit from our tools and the experience of bringing teams together. We provide customers value with workflow efficiency, informed team decision-making, lower risk of security breaches, and attaining compliance requirements. We focus on all aspects of the product — starting with the customer experience. When deciding to use our tools, organizations are often considering the following:
We use the Jobs to be Done (JTBDs) framework to keep us focused on user goals and to make sure we're supporting users on what they value. See a breakdown of the Secure and Govern Jobs to be Done here.
We also carry out UX Scorecard evaluations for our JTBDs. See UX Scorecards for Secure and Govern, as well as for other stages, here.
We've divided our stage into dedicated experience groups to align with a similar split undertaken by our engineering and PM counterparts. This is an excellent way to manage our resources but our mindset is still focused on a wholistic approach for our Groups overall user experience.
Secure
| Group | Category | DRI Designer(s) |
|---|---|---|
| Composition Analysis | Software Composition Analysis, Container Scanning | Secure & Govern UX Team (shared) |
| Dynamic Analysis | DAST, Fuzz Testing | Michael Fangman |
| Static Analysis | SAST, Secret Detection, Code Quality | Michael Fangman |
Govern
| Group | Category | DRI Designer(s) |
|---|---|---|
| Security Policies | Security Policy Management | Camellia Yang |
| Threat Insights | Vulnerability Management and Dependency Management | Becka Lippert, Andy Volpe |
| Compliance | Compliance Management and Audit Events | Alex Fracazo |
The Secure & Govern UX teams work closely together on all things Secure & Govern 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.
Short-term (6m - 12m) (as of 2021-09-22)
Long-term (1y - 3y) (as of 2021-09-22)
We follow the GitLab workflow with additional dates and actions that directly tie to our work.
For UX-related issues or MRs that involve all groups across Secure and Govern (if you're unsure who the DRI is), we encourage transparency and collaboration by using @gitlab-com/gitlab-ux/secure-govern-ux.
For any feature development on, or affecting the performance of, the Security Dashboard and the Vulnerability Report pages, the Threat Insight backend engineering team should be notified early on by using the @gitlab-org/govern/threat-insights-backend-team handle to evaluate the performance impact of the feature.
These include 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, and have a tentative milestone.
We use a team planning board as tool to help us monitor our velocity allowing us to more efficiently communicate our time to our counterparts.
At the start of each Milestone, we create a Team Milestone Planning Issue (using the template below) to initiate a team discussion around which Issues will need to be worked on in the next, upcoming, milestone (not the milestone that has just begun). We do this to ensure that each Group has:
M-1, 17th (1 month before start of milestone)
M-1, 24th (~3 weeks before start of milestone)
M-1, 1st (~2 weeks before start of milestone)
M-1, 8th (~1 weeks before start of milestone)
M, 17th (Start of milestone)
To create a new Milestone Planning Issue using the Secure & Govern's issue planning template:
Part of our milestone planning activities include factoring in the amount of effort required for each assigned issue. We use the following scale:
| Size | Weight | Description |
|---|---|---|
| Trivial | 1 | Mostly small to medium UI changes, smaller UX improvements, without unanswered questions. UX may need to stay involved with the issue but might not have to do work. |
| Small | 2 | Simple UI or UX change where we understand all of the requirements, but may need to find solutions to known questions/problems. |
| Medium | 3 | A medium change (lots of UI or UX changes/improvements required). Multiple pages are involved, we're starting to design/redesign small flows. Some unknown questions may arise during the work. |
| Large | 5 | A complicated change where other team members will need to be involved. Spans across multiple pages, we're working on medium-sized flows. There are significant open questions that need to be answered. |
| Huge | 8 | A complex change that spans across large flows and may require input from other designers. This is the largest flow design/redesign that we would take on in a single milestone. |
| Gigantic | 13 | A significant change that spans across multiple flows and that would require significant input from others (teams, team members, user feedback) and there are many unknown unknowns. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller issues. |
The Secure and Govern UX teams are 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:
Below is a list of resoruces that provide a foundational understanding of the industry we are designing for as it relates to GitLab.
Our Secure and Govern UX YouTube channel includes UX Scorecard walkthroughs, UX reviews, group feedback sessions, team meetings, and more.