Duplicate of &2921
Problem to solve
We are going to enable "Perform secret detection on full history". "Secret" is different from other vulnerabilities. It is important to know the file location and commit history; also how user remediates it will be different as well. What is the best way to display the result of "Secret scan" is important for users: Should it is part of the dashboard? or should it has its own page?
Target audience
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney
- Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam
JTBD: When protecting my project against secret leaks, I want to know if there are secrets in my commit history so that I can be assured my companies keys are safe from bad actors.
Research
We have done the research: ux-research#681 (closed)
- Option 1: in a separate tab from vulnerabilities
- Option 2: Part of vulnerability dashboard
Quick summary of the result:
- For those who have no experiences before triaging Secrets, but has Security background (2 people): Use the information we provide to make a decision:
- When Secrets display on the dashboard with other vulnerabilities and severity label: critical. They think Secrets are important to deal with.
- When Secrets display on standing alone page, they think they are not vulnerabilities, it is place to manage Secrets
- When Secrets display on the dashboard with other vulnerabilities and severity label: critical. They think Secrets are important to deal with.
- For those who have experiences triaging Secrets (2 people): have a different option about Secrets:
- One think Secrets is definitely vulnerabilities and should be triaged first. But prefer it to be in the dashboard so that she can manage everything together
- Another one think not all Secrets are vulnerabilities, because they have different ways to protect exposed secrets. So prefer the standing alone list to manage Secrets.
- One think Secrets is definitely vulnerabilities and should be triaged first. But prefer it to be in the dashboard so that she can manage everything together
- No one really think commit is the most important info to triage Secrets
- Whitelist feature is somehow confusing
Design decision
Because of the following reasons:
- For those who have no experience with triaging Secrets, the purpose of using a separate page is not clear
- For those who have experiences with triaging Secrets, opinions various too much
- Hypothesis: "commit/whitelist is the key feature to help triage secrets", this is not what the user expects
For MVC design, we keep secrets in the Dashboard list. Add scanner column to help the user identify this is Secrets.
For future design, we need to understand the needs of users:
- For those who have no experiences before triaging Secrets: Do user needs education about triage secrets
- For those who have experiences triaging Secrets: Do think Secrets as the same we define it? Is "Secrets Manage" is a validate option
Design for MVC
Project Dashboard | Dashboard- filter open | Pipeline Dashboard | MR |
---|---|---|---|
Add Scanner column | Make sure secrets is a separate item in the filter list | It is same with project dashboard | Separate MR widget for Secrets |
Secrets is always critical | |||
design specs:https://gitlab-org.gitlab.io/gitlab-design/hosted/camellia/%23204982-Secret-detection-deliveries/#artboard2 | design specs: https://gitlab-org.gitlab.io/gitlab-design/hosted/camellia/%23204982-Secret-detection-deliveries/#artboard3 | design specs: https://gitlab-org.gitlab.io/gitlab-design/hosted/camellia/%23204982-Secret-detection-deliveries/#artboard1 | design specs: https://gitlab-org.gitlab.io/gitlab-design/hosted/camellia/%23204982-Secret-detection-deliveries/#artboard0 |
Checklist
Design:
-
Update description to reflect decisions from product discovery -
Finalize designs and add them to the issue -
Core experience -
Edge cases -
empty states: #13398 (closed)
-
-
Post design specs -
Create follow up issues for: -
Documentation updates -
Post MVC experience iterations
-