Determine what is the best way to provide configurability for security controls

Starting this issue to begin a discussion. The goal is to get to a decision which can be used as a guiding principle for development of future security capabilities. Future issues can be created to detail and implement the decision.

Background & Problem

One of the key principles we will develop capabilities with is that they should be "batteries included" and not need configuration nor reading of a long manual for users to get started. However, there will be users with either advanced use cases or business compliance requirements which require they choose some non-default setting from what GitLab provides.

If each Secure/Defend capability is configured in a unique way, it will introduce complexity that users will have to learn how to navigate. My hypothesis is that this will reduce adoption of non-default, advanced use cases and introduce frustration.

Rather than provide ad-hoc, per-capability ways of configuring these, let us proactively decide on a way to group and do security configuration in a single place. That way, when we need to allow configuration, there is a default place we add it to and that users will look for it.

Some things to I was thinking through as part of this (and there's probably others, please add to this!) :

  • There will be eventually be many unique security controls, such as WAF, Container Security, Data Loss Prevention, SAST, DAST, etc
  • Users may need to specify textual configuration (e.g. set TOOL_ARG=foobar as part of running a scanner)
  • Users may need to toggle a given behavior on/off and which already has a default setting
  • Users may only be concerned with one type of tool or capability at a time
  • There could be many unique configuration options per individual tool

Proposals for discussion

A few initial proposals:

  1. A new screen under the Security & Compliance, which has configuration sections per-category (SAST/DAST/WAF,etc)
    • Configuration options are only shown here if a non-standard value has been entered by the user, rather than display all possible default choices (which would be overwhelming)
  2. A configuration file inside the repository which drives the behavior (e.g. gitlab-ci.yml/.gitlab-security.yml)
  3. An existing screen or location I may not be aware already exists
  4. What other ideas you have?

Next steps

Because we will start adding a lot of capabilities in the near future, I'd like to finish the initial discussion by 2019-09-02.

  • Decide on a method or location for grouping configuration options - We'll start with Option 1
  • Create follow-on issues for discovery & implementation - Discussion to continue in #13646 (closed)

/cc @beckalippert @andyvolpe @plafoucriere @NicoleSchwartz @kencjohnston @twoodham @sethgitlab

Edited by Sam Kerr