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.
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)
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 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 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.
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
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.
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: