Smart Security Rules

Problem to solve

Users need more flexibility around vulnerabilities reported by GitLab. Almost all the process when findings are reported is manual, and could be somehow automated. We also want to reduce the Rate of False Positives (RFP).

Intended users

Further details

One of the biggest concerns raised by our users is the number of findings, and especially of False Positives among the results. It's common for developers or security engineers to repeat the same routine over and over again. Some findings could be automatically ignored based on rules defined by our users, so they would be empowered with their Security Policies.

This feature would land in the new Govern stage I suggested to create.

Proposal

I'd like to suggest something very ambitious: If we let users define their workflow with a simple SDL, they could automate a large part of it. This idea is coming from observing how our security team is triaging findings. To determine if a findings is a true or a false positive (or if some more investigation is needed), we need 2 things:

  • A finding (from an advisory or a CWE)
  • A context

The latter can come from different sources:

  • The project nature
  • The current module/package nature
  • The data flow

It's the conjunction of the two that will determine if the finding is a False Positive or not.

Imagine if we'd let users express the context of their projects, in the form of conditions + actions. Example (disclaimer not a real SDL):

if project.properties.DB != "mysql"
  dismiss
end

We translates in: "if a finding is only for mysql DBs, ignore it. Imagine the possibilities around this SDL:

if !project.properties.services.includes("ldap")
  dismiss
end

For vulnerabilities affecting only LDAP, we can safely ignore them.

We can go even further with these rules:

  • They could define ignored paths
if finding.path.starts_with "/auth"
  finding.severity.increase
end

if finding.path.starts_with "/tests"
  dismiss
end
  • They could exclude CVEs or rules
if finding.identifier == "CVE-12345"
  dismiss
end
  • They could be based on data flow
if !finding.code.params[0].comes_from("http")
  dismiss
end
  • They could be based on the project nature:
if project.properties.type == "cli"
  dismiss

We can imagine the following available actions:

Moonshot

If rules are defined at every level (project, group, instance), the whole company security policy can be programmatically implemented in GitLab. It could also cover ~"devops::defend" rules to define the actions to take based on the generated events.

If project properties can be also set at the group level, for example, it would allow a lot of automated workflows.

These rules could also allow defining what tests are enforced, and what checks can be disabled/altered.

If the SDL is simple enough, it could be embedded directly in the gitlab-ci configuration, so we can leverage multiple existing features (brainstorming here):

include:
  template: SAST.gitlab-ci.yml

sast:
  sec_rules:
    finding.identifiers
      - "CVE-12345" then dismiss
      - "CVE-12346" then dismiss

That way, users could keep track of decisions, and compose their rules the way they want. On the other hand, it would not work well with ~"devops::defend" rules.

Permissions and Security

TODO

Documentation

TODO

Testing

TODO

What does success look like, and how can we measure that?

  • Users control their security maturity model
  • False Positive Rate decrease

What is the type of buyer?

GitLab Ultimate

Links / references

Edited by Philippe Lafoucrière