We’re designing an experience that enables contributors to commit their most secure work. 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 secure-oriented decisions. We are doing this by focusing the experience on automation, education, empowerment, and shifting security to the left.
Automation relates 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 vulnerabilities.
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 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 early and often.
Our customer
Organizations of all sizes benefit from our tool 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 tool, organizations are often considering the following:
What languages does the tool support?
What tests do we need to cover?
What tests does the tool cover?
Can it be automated?
How long will setup take?
What does setup involve?
How easy is it to use?
What technologies do you need to use? ex. Docker, Kubernetes
How lightweight is the tool?
How does it integrate with our tools?
What customer support is offered?
What are the upcoming features? (we are selling contracted services vs monthly)
Our user
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.
Our baseline experience
Primary Jobs to be done (JTBD)
Interacting with vulnerabilities in the MR: 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.
Interacting with vulnerabilities in the security dashboard: 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..
Managing licenses (user that is responsible): 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.
Managing licenses (user that is accountable): 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.
Vulnerability check (user that is responsible): When a merge request is disallowed, I want to know why, so I can resolve the issue and proceed with the MR.
Vulnerability check (user that is accountable): 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.
Configuring Secure features: 1. 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. 2. When I want to implement security tools, I want to be able to install them easily and know they are working properly, so that I can be reassured my company is managing and monitoring risk.
Dependency list (responsibility): 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.
Dependency list (accountability): 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.
The Secure & Defend UX teams work closely together and have shared coverage in the following areas:
Vulnerability Management
Security Dashboard
Control Center
Status, Metrics and Reporting
Security Configuration
This segmentation gives us a better opportunity to:
Grow our expertise and knowledge within our subgroup while sharing relevant information with the rest of the team.
Evolve and maintain relationships with our dedicated engineering team and PMs.
Serve as the known main point of contact.
Deeply understand our users' needs by initiating and/or leading research activities specific to our experience group.
Focus on iterating and progressing our experiences from MVC to Lovable.
How we work
Labels we use
We created 3 scoped labels to help us identify which experience group a particular issue falls into and which designer should be subsequently assigned.
Secure UX::Shared
Issues relating to Vulnerability management • Status, Reporting & Metrics • IA and Core Functionality.
Examples: Adding Secure to the left nav, Inline vulnerability management, Dashboard designs.
Who to ping: If no designer is assigned: Both designers. If a designer is assigned, ping them in the issue.
Secure UX::Security Testing & Scanning
Issues relating to security testing, scanning, and detection of vulnerabilities or weaknesses.
Examples: MR Widget security report design, Secret detection, DAST - list of scanned URLs in MR.
Who to ping: Andy Volpe
Secure UX::Compliance & Auditing
Issues relating to features that support Compliance and/or Auditing activities.
We host a recurring 30-minute open meeting every week to discuss topics relevant to Secure design, UX, and research. Some example topics could include:
Updates on in-flight and planned research
Updates on design issues
Issues that might be at risk or has blockers
Recently discovered insights while conducting researching
Updates to our Baseline initiatives
Updates on changes to UX workflows and processes
Updates on pilot initiatives we are working on
Some topics are better suited for a dedicated meeting, and should be created on an as-needed basis:
Milestone planning and grooming
Design critiques
Research report readouts
Syncing on troublesome issues
Planning and grooming
Secure UX has a separate grooming session which takes place during the planning phase of a milestone. During grooming, we add the proper label to all issues requiring UX support.
Read more about how we've created these dedicated experience groups here.
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:
