New security stage: Govern

I'd like to challenge with you the idea of adding a new stage related to Security. We already have the Secure and Defend stages, which are complementary. They cover a great part of the security duty in the DevSecOps mindset, but I think a large part is still missing and could find its roots into this new stage.

The current overview of Secure and Defend demonstrates that we already struggle to define the location of multiple features:

Screenshot_2019-09-27_10.45.30

Our Security Dashboard for example is currently managed by the Static & Dynamic Group. It's even more unclear when realizing that this group is actually 2 teams, so we don't even know who's the real owner. The same goes for several other transversal features by the way. They just land in some random team, because they need to be somewhere.

We discussed already in the past the possibility of having a "core" team for Secure (and maybe Defend), that would be closer to the GitLab codebase. This idea was the seed of this issue: We don't need a team, but a whole stage if we start enumerating just the existing related features:

  • Security Dashboards
  • MR Security Widget
  • related APIs
  • Security Gates
  • Reports

We struggle to move forward on these topics, because they "interfear" with the base categories roadmap. As a result, they often don't have any roadmap or get never scheduled. Thus, these topics are critical for the Ultimate customers, and even more, I think they represent the main value behind Ultimate, more than the tools themselves. I'd like to remind that we're already moving SAST to Core.

What is Govern?

Govern would be a stage to manage the Enterprise Security Maturity Model, including business rules and Policies. This is the place to start, even before configuring the security checks in the pipeline or in Defend. It defines what needs to run, when, and how. It's the mask we apply on the results provided by the tools (Secure & Defend). Secure and Defend become the enablers of Govern.

Screenshot_2019-10-11_16.45.21

Moonshot

We currently don't have any static code analyzer engine, that would be able to manage a syntax tree or a data flow. But we know it will be required at some point if we want to unify our efforts on SAST and RASP for example. It's also necessary to reduce the rate of False Positives, a strong blocker currently to Ultimate adoption.

But the day this engine will be available, I have good hope we'll add a query language to it. From there, we can imagine letting the users define their own policies directly with this language. The only way to correctly handle false positives (issue to be created soon), is to instruct GitLab with context. If Govern can become the place where all contexts can be managed, then we have all the pieces necessary to enterprise-grade security. Imagine if I could say in Govern, with this query language:

  • IF [rule(s) to detect vulnerability]
  • AND affected DBs does NOT include "PostgreSQL"
  • THEN dismiss the finding.

That means also our rules will need to be constructed with better metadata (cc @julianthome), and provide a way to understand more their nature and possible contexts.

Remember that context is the key to take decisions, and this is even more true in License Compliance. Our current implementation is so basic, that large customers will struggle using it. The only to define Licence Compliance rules is to manage code context + legal context + product context.

Compliance

While very close to Compliance, Govern needs its own space, in order to target the right users (who are different from my opinion). Govern doesn't belong more to Compliance than Secure belongs to Verify, or Defend to Monitor.

I would like to hear from @ddesanto, @sfwgitlab, and @markpundsack on this.

/cc @sytses

Edited by Philippe Lafoucrière