Align core concepts and design patterns used throughout the secure configuration area (tool configuration)

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Recommendation from Secure - Audit of scanner configuration UI

Problem to Solve

While many of GitLab's security tools can be enabled via the UI, only 3 currently provide users with in-app configuration options (SAST, DAST, & API Fuzzing. The configuration experience for those scanners all differ slightly. As GitLab continues to mature its security offerings, it's important to align on the design patterns and core concepts used throughout the security configuration process so tool configuration isn't a hurdle to stage adoption.

Insights

1. The SAST & API Fuzzing configuration forms are very similar in layout and feel but require a different workflow to actually enable the scanner
2. DAST and API Fuzzing follow the same workflow to be enabled but have very different configuration forms.
3. The DAST and SAST configuration processes are very different from one another.
4. There is a future-state design for API fuzzing. If/when the related issues are implemented, the 3 configuration UI's will all be notably different.
5. The dynamic analysis tools share a couple key concepts:
   1. Both API fuzzing and DAST have the concept of scan profiles
      1. Scan profiles contain configuration details that define how a scanner should test its target. Profiles do not contain information about the scan target itself.
      2. The content of a scan profile is dependent on the type of scanner it is for.
      3. Currently only DAST allows for user-defined scan profiles. API fuzzing offers pre-defined profiles right now but is slated to expand to user-defined profiles in the future
   2. DAST site profiles that are defined as a Rest API don't allow for authentication; API fuzzing does. Is there a reason why one allows for authentication and the other does not?
6. DAST offers additional functionality beyond basic CI/CD configuration. It is the only scanner that does this currently

Hypothesis

Improving UI consistency and aligning on core concepts will make it easier to configure multiple scanners, both individually and potentially at the same time

Security configuration concepts (draft)

Scan targets

• Some scanners target branches, others target deployed instances. Either way, there's always a "target"
• Relates to the following JTBD: When I am configuring a CI/CD security scan, I want to specify which assets need to be scanned and under which circumstances, So that I can ensure my assets are secure prior to or at their release.

Tool configuration

• Independent of the scan target, each tool has a set of configuration options that determine the type of security checks it performs.
• Relates to the following JTBD: 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.

"Profiles"

• DAST uses site profiles and scanner profiles to save and reuse information about the scan target and tool configuration.
  • DAST profiles allow users to make changes to their configuration without having to update their code, since changes made to in-use profiles can be applied without updating code
• API fuzzing offers pre-defined profiles right now but is slated to expand to user-defined profiles in the future

Proposal

To be determined...