Identify information architecture of Secure and Defend settings
Problem to solve
There is not currently a dedicated section for Secure and Defend settings. There are limited existing settings, but as features evolve new settings requirements will be needed. Additionally, there is not a centralized place where all project participants can see what (and how) Secure/Defend configurations and settings are affecting their project. Upcoming possible settings: auto-remediation #36500 (closed), WAF rules #36531 (closed), dependency-check/conditional rules, and license compliance.
Recently, we conducted a usability test with a task to see where user would navigate to adjust a setting (Auto-fix MRs):
Saving you a click, our key insight from that study was that for most participants (4 / 5), Security & Compliance is where they expect to find the option to enable the auto-fix feature. This is consistent with past studies, where we saw that users default to the ‘Security & Compliance’ area for security-specific settings
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
Further details
Current UX issue: secure/defend setting examples are approval rules, such as License-Check
and Vulnerability-Check
. These are located in Project > Settings > General > Merge request approvals. For these features to be activated, the prerequisite is the configuration of security scans, then applying the rule count and designated approvers. These two areas are separated, therefore UX doesn't correlate the two and the UI does not explicitly state their relationship.
Further consideration: As settings evolve a centralized area may be helpful to show users how the project is configured to meet their Secure and Defend needs. This needs to be clear to users that are configuring the settings, but also communicating this to all participants could be helpful for awareness/education aspect.
Proposal ideation
Centralize Secure and Defend settings in one view, so users can easily configure the projects and/or see how their projects are configured.
direction i. located in Secure/Defend | direction ii. located in Settings |
---|---|
Project > Security & Compliance > Configuration The upside to having relevant settings in the “Configuration” section is this solution may help to 1) centralize settings for configuration and 2) simplify configuration efforts (since proper configuration is a pre-req for settings). The downside is breaking away from existing settings pattern. Note: The configuration page MVC was built in the FE to mirror the settings structure. | Project > Settings > General > Secure and Defend The upside here is that it is more consistent with our current information architecture pattern. The downside is that while settings are in one centralized place, the configuration status display is in another (important since config is the prerequisite). In this scenario, we could move the configuration section, but the downside to this is we saw 5/5 users go to this section to “turn on” scans and 3 of 5 go to this section for related settings. |
Note: new settings info-arch will need to be considered as a case by case basis. For example, current approval rules may need to be located in 2 locations: 1) approvals settings section (in this case), and 2) centralized Secure and Defend section (where all relevant settings live).
Permissions
For consideration: maintainer and above has the ability to edit configuration settings and developers can view the settings. This aims to bring awareness of security/defense in a project to all project participants.
What does success look like, and how can we measure that?
- Users navigate to the designated section when tasked with adding/editing settings
- Non-maintainers benefit from the visibility of viewing the section, in that they understand how security affects the project (better informed/educated)
What is the type of buyer?
~GitLabUltimate
Conclusion
Based on team discussion and proposal, we closed the issue with the following actions:
- Direction: will go with the direction i as a first step. The initial settings to be seen will likely be security gates rules and/or WAF rules.
- Strategy: we will re-test the information architecture in upcoming/future studies, will consider using tree testing. This research will help guide future steps of whether to continue in this direction or re-evaluate.