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.
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.
UX scorecards
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.
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:
