UX Theme: Create a consistent, scalable experience for security teams when configuring security tools in GitLab
Problem to solve:
- How might we provide a consistent configuration experience across multiple security tools and configuration methods?
- How might we make it easier to security teams to manage and administer security across GitLab?
Details:
Beneficiary
- Sam (Security Analyst)
- Security teams
User needs:
- Primary: Configure and manage security tools across projects.
- Validate the settings of security tools before integrating them in my team's workflow.
JTBD:
- Primary: When I am implementing security in my organization, I want to save and reuse configuration preferences for the tools I use so I can be more efficient when setting up and managing these tools across projects
- When I am configuring a security scan, I want to specify which types of vulnerabilities the scan should detect, so that we don't waste time sorting through irrelevant findings
- When I am either enabling or configuring a security scan, I want to run a demo scan, so that I can validate my configuration before it is implemented
Expected outcome
- Security tools will be easier to maintain and update
- Security scanning configuration will be more uniform across all configuration methods (CI/CD, on-demand, scan execution policies)
- Security tool configuration will follow a structured system that can be applied across projects and groups (in a future iteration, most likely)
Business objective:
- Increase adoption of GitLab’s security tools by making the configuration experience more consistent and efficient for users.
Proposal
Summary
Expand the concept of reusable configuration profiles from DAST to all of GitLab’s security scanners.
Security profiles would make it easy to save and reuse customized scanner and target configuration details for GitLab’s security tools.
Profile types & sub-types:
Building on DAST profiles, we could leverage two existing profile types: scanner profiles and target (site) profiles. To accommodate the various security tools GitLab offers, each profile type could have distinct subtypes. Here is more detail on the proposed profile types and subtypes:
-
Scanner profiles:
Scanner profiles contain configuration details that define how a scanner should test its target. There is a scanner profile subtype for each security scanning tool GitLab offers, including, but not limited to:
- DAST
- DAST API
- SAST
- API Fuzzing
- etc.
-
Target profiles:
Target profiles contain information about a scan target. Available subtypes would align with the object types (websites, source code, containers, etc.) each security scanning tool can analyze. There would be some overlap between tools. Theoretically, target profiles could be targeted by any scanner (scanner profile) that uses the target type. Subtypes could include:
- Websites
- APIs
- Code repositories (source code)
- etc.
Security configuration architecture changes:
To accommodate the expansion of security profiles, the following changes should be made to the security configuration page structure. This will create a distinct area to view and manage security profiles across a project and lay the groundwork for expanding profiles to a higher level (e.g., group or workspace) in the future.
Key workflows:
This proposal will focus on 2 primary workflows for security profiles. The diagram below breaks down these workflows.