Govern UX
Overview
The Govern stage includes all features that help you protect your applications and cloud infrastructure by giving you the ability to identify, catalogue, manage, and remediate threats, vulnerabilities, and risks. For more information about our principles and upcoming features, see our Product Vision page.
While the Secure UX team’s goal is to provide the best experience in taking pre-emptive security measures before deploying your code, the Protect UX team’s goal is to provide the best experience in keeping your application safe after your code is in production. See the Sec UX page for more about our team and how our two teams work together.
User
The Govern user is responsible for maintaining the security of their company’s environments and/or applications, through both proactive and reactive measures. They prefer to be proactive by abstracting away from manual, repetitive tasks and moving towards automation.
The Govern user is responsible for risk mitigation, remediation, documenting their processes in timelines and runbooks, collaborating with other teams, meeting compliance standards, and performing root cause analyses.
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:
- Software Developer
- Development Tech Lead
- DevOps Engineer
- Application Security Engineer
- Infrastructure Security Engineer
- Security Operations Engineer
- Compliance Manager
- Chief Information Security Officer
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):
- When I make sure my company’s applications aren’t vulnerable to bad actors, I want to monitor the traffic coming to my application and detect the possibility of an attack (SQL injection attempts, XSS attempts, vulnerability scanners, etc) so I can know what parts of the application I need to protect better.
- When a bad actor successfully attacks my system, I want to look at the WAF logs to determine the attack vector (how they got in) so I can secure the weak points in my application.
- When I want to make sure I’m being successful in my role, I want to be able to confirm if a data breach happened, if any systems went down as a result of an attack, to what extent our security controls negatively impact uptime or throughput, and how much maintenance did the security controls require this quarter, so I can track and meet my OKRs.
- When I want to avoid putting out constant fires, I want to be proactive by creating tooling to understand events occurring in my application so I can catch security risks before they can be compromised.
- When our proactive security measures fail, I want to prioritize incident response so I can keep our environments (and our customer data) safe.
- When I’m optimizing my company’s processes, I want to make sure everyone is updating the runbooks so I can make sure the team is being efficient and following the same validated procedures.
- When I want to demonstrate that a procedure is in place, I want to invest time in compliance so I can help our Security Compliance team provide information and assurance about our information security program to customers and remove security as a barrier to adoption by them.
- When I’m conducting incident management, I need to communicate well with other teams and know when to involve them so I can put fixes in place quickly and efficiently. |
Secure & Govern UX
For more information about the Protect team and how we overlap and collaborate with the Secure team, see the Sec UX page.
47d8fda4)
