Over the past couple of years, our users have come to know and regularly use our many security features that are part of the Secure and Protect stages. We have seen success stories from customers who have improved their security postures by reducing vulnerabilities in application code. One thing that surprises me when I speak to our users is that many aren’t aware of some of our most useful features. Here are three things you really should know about GitLab’s capabilities that will help take your security game to the next level.
We have a GraphQL API!
GitLab has long offered a REST API. It is quite capable but when it comes to vulnerability management, it is limited in what you can do. Our GraphQL API is newer and is the area of focus for new API development. Vulnerability management in particular has quite an extensive feature set in the GraphQL API. Whether you are looking to build task automation, create custom reports, or pull in vulnerability data from external sources, GraphQL is your go to resource.
Bringing in vulnerability data from outside GitLab is a new capability worth calling extra attention to. You can use GraphQL to directly create vulnerability records on projects. This is great for migrating vulnerability data from other systems, creating integrations with a bug bounty program, or even bringing in results from security tools that don’t run in GitLab pipeline jobs. I’m sure our users will come up with many more creative use cases. Even better, these vulnerability records show up in Vulnerability Reports and Security Dashboards just like results from any of our many included security scanners.
Security approvals help stop new vulnerabilities
A primary goal of any application security program is to reduce risk by keeping vulnerabilities out of deployed code. One of the best ways to do this is by preventing new vulnerabilities from getting into your main branch in the first place. Scanning feature branches on every commit is a recommended practice many of our customers employ. But it’s how to keep vulnerability findings from being merged where I see a lot missing out on a power feature that can help.
I commonly see pipelines configured to block or fail if any security scan jobs detect a potential vulnerability in new code. While this approach is effective in keeping new vulnerabilities from being merged, it can be more disruptive and less efficient for developers and AppSec teams. Instead, we recommend using security approvals in merge requests. Like normal MR approval rules, you first specify one or more individuals that will be part of the security approval group. Members of security approval groups don’t even need to have merge rights to the project so you can have segregation of duties. You then configure the detection rule to set the number of approvals required, severity levels that trigger the approval and even which scanners the rule applies to. And while you are setting up your approval rules, consider enabling the setting that prevents merge approvals by the MR author for further segregation of duties.
Security approval rules are great for a few reasons. First, you can more quickly enable and configure them on a project than custom pipeline behaviors. Also, only project owners and maintainers are able to access and modify these approvals. Contrast this with pipelines where anyone with the developer role can change pipeline configurations by default. Security approvals are also more visible and collaborative. When a pipeline is blocked or fails, the developer must navigate into the pipeline and try to figure out what failed by reading the job output. When a security approval is triggered, it will clearly show on the MR that merging is blocked until the flagged vulnerabilities are removed or approval is provided from the required number of security approvers. And because you can see any scanner findings on the MR, developers can not only quickly investigate these potential vulnerabilities, they can also add comments and communicate with the security team. Best of all, developers can simply fix any findings that would require approval. Once the security scans no longer detect the violations, merging is immediately possible again.
Compliance pipelines enforce security hygiene
Last but certainly not least is the newest of these three features: compliance pipelines. Have you ever wanted to make sure your code branches are properly scanned for vulnerabilities but you were having trouble auditing and enforcing it? Compliance pipelines to the rescue! Compliance pipelines allow group owners to add an additional pipeline configuration to projects. These configurations are combined with any existing configurations for the project pipeline. Compliance pipeline configurations are evaluated before any project configurations meaning they can override any values in the project pipeline. This is a powerful tool for automatically enforcing compliance with various regulatory and private industry standards as well as any internal company policies.
Compliance pipelines work best when combined with compliance frameworks. Compliance frameworks allow group owners to specify the location of a compliance pipeline configuration. The configuration can be stored and managed in a dedicated project with restricted access. Special compliance framework labels are created which can then be applied by the group owner to any projects within the group. This label is what tells a project’s pipeline to pull in the associated compliance pipeline configuration. For example, you might create a PCI compliance label. You then simply apply the label to any projects within the scope of PCI such as any that process or store customer information and payment details.
Continuing with our PCI example, you can enforce code scanning with these two features in place. Simply create a compliance pipeline configuration with the desired scanners included such as SAST and Secret Detection. Be sure the configuration file is in a project with access granted only to those users who should have permissions to modify it. Then, edit your PCI compliance label in your group settings and point it to the compliance pipeline configuration. You can even allow compliance job values to be settable at the project level. This means you can, for example, ensure a SAST job runs but leave room to select the right language-specific analyzers for a particular project’s codebase. Even better, use GraphQL to quickly apply compliance labels to multiple projects.
Wrapping it up
With so many features in a single platform, it is easy to overlook some. The ones I’ve shared are only a few of the many security-related features GitLab includes. They are also important to know about because of the additional flexibility and control they offer in addition to our comprehensive security scanning capabilities. I hope you’ve found at least one new idea to add to your security toolbelt.
