Generic Security and Compliance gates for Merge Requests with OPA
Problem to solve
We have different ways to gate Merge Requests (when there are certain kinds of vulnerabilities, licenses, etc.). These gates are not flexible at all, not scalable, and hard to maintain. As a Security Analyst, I want a way to manage these as code, so I can put in place complex policies and don't repeat configurations (DRY).
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
Further details
We have a gate for vulnerabilities, where the approval of a specific group of users is required to allow the merge: https://docs.gitlab.com/ee/user/application_security/index.html#security-approvals-in-merge-requests
Every time we want to cover a new need, we have to update our product, the UI, the documentation, and at the end of day, we just cover a small portion of what the user wants to put in place. As an example, our Security team would like a way to gate dependencies in Merge Requests, we can't do that in GitLab without a lot of work in the UI. An alternative would be to gate this with code, and that's the topic to be discussed in this issue.
Proposal
Instead of multiplying the widgets and configurations screen, Policies as code could be used to let users decide exactly what they want to enforce. OPA (Open Policy Agent) is becoming an industry standard for this purpose, and we could leverage it to make the workflow a lot cleaner:
Dependency Scanning and License Compliance would report only Dependencies (components), their license(s), and their potential vulnerabilities. An job based on OPA would be then triggered if a rego file is present in the repo, with a specific (GitLab) name. In this case, this job is used as a gate, and could replace the existing widgets (they're not displayed anymore). So that users who want to use policies as code can start doing it without interesting with existing widgets. The other users would still benefit from point-and-click configurations.
If the rules (rego) file is detected, and therefore the opa job run, we can generate a report to be used in a generic widget, presenting the violations to the policies. They could be invalid licenses, critical vulnerabilities, not whitelisted dependencies, etc.
We need to think about the possible interactions with this widget, but setting a vulnerability as a false positive for example should lead to an update of the policies, and therefore the rules file in the end.
These rules files could be included from a high level, for a whole Group for example. This is a great way to scale the process.
Permissions and Security
Documentation
TBD
Availability & Testing
TBD
What does success look like, and how can we measure that?
- number of rules files used
What is the type of buyer?
Is this a cross-stage feature?
Yes, closely linked to groupcompliance (cc @mattgonzales)
Links / references
/cc @kmann following today's discussion