Blog Insights 4 Ways developers can write secure code with GitLab
Published on: September 3, 2019
5 min read

4 Ways developers can write secure code with GitLab

GitLab Secure is not just for your security team – it’s for developers too. Learn four ways to write secure code with GitLab.


Writing secure code is a standard part of day-to-day development work, but security often appears to be a roadblock instead of a critical piece of the puzzle. To make security efforts easier, GitLab Secure offers a number of different tools that help developers identify and remediate vulnerabilities within their code, as they’re writing it. Our goal is to seamlessly integrate security into your code writing practices so you’re better able to protect your business from growing cybersecurity threats.


There are a variety of testing tools available to developers within GitLab. Generally, they alert developers to vulnerabilities within their code and report them within the merge request so developers can adjust their code as they go. In addition to the testing methods outlined below, developers can also use other tools outside of GitLab by integrating the results of your scanners with our merge request security reports.

Static application security testing

Our static application security testing (SAST) tool scans the application source code and binaries to spot potential vulnerabilities before deployment. It uses open source tools that are installed as part of GitLab. Vulnerabilities are shown in-line with every merge request and results are collected and presented as a single report.

Secret detection

Secret detection within GitLab is able to detect secrets and credentials that have been unintentionally pushed to the repository. This check is performed by a specific analyzer during the SAST job, runs regardless of the programming language of your app, and displays results within the SAST report.

Dynamic application security testing

Our DAST tool analyzes your web application for known runtime vulnerabilities. It conducts live attacks against a review app and can be created for every merge request as part of GitLab’s CI/CD capabilities. Users can provide HTTP credentials to test private areas. Vulnerabilities are shown in-line with every merge request.

Dependency scanning

Dependency scanning analyzes external dependencies (e.g. libraries like Ruby gems) for known vulnerabilities on each code commit with GitLab CI/CD. This scan relies on open source tools and on the integration with Gemnasium technology (now part of GitLab) to show, in-line with every merge request, vulnerable dependencies in need of updating. Results are collected and available as a single report. Dependency scanning also provides a list of your project’s dependencies with different versions for languages and package managers supported by Gemnasium.

Container scanning

If you’re using GitLab CI/CD, container scanning will let you check Docker images (and containers) for known vulnerabilities in the application environment. Analyze image contents against public vulnerability databases using the open source tool, Clair, that is able to scan any kind of Docker (or app) image. Vulnerabilities are shown in-line with every merge request.

License management

Upon code commit, project dependencies are reviewed for approved and blacklisted licenses defined by custom policies per project. Software licenses are identified if they are not within policy, and new licenses are also listed if they require a status designation. This scan relies on an open source tool, LicenseFinder, and license analysis results are shown in-line for every merge request for immediate resolution.

Code quality analysis

With the help of GitLab CI/CD, you can analyze your source code quality using GitLab Code Quality. Code Quality uses Code Climate Engines and runs in pipelines using a Docker image built into the Code Quality project. Once the Code Quality job has completed, GitLab checks the generated report, compares the metrics between the source and target branches, and shows the information within the merge request. With pipelines that enable concurrent testing and parallel execution, teams quickly receive insight about every commit, allowing them to deliver higher quality code faster.

The Security Dashboard

Security dashboards in GitLab exist at both the project and group level. The group dashboard provides an overview of all the security vulnerabilities in your groups and projects. In the dashboard, developers are able to drill down into a vulnerability for further details, see which project it comes from and the file it’s in, and view various metadata to help analyze the risk.

The dashboard also allows viewers to interact with vulnerabilities by creating an issue for them or dismissing them. For ease of use, vulnerabilities within the group Security Dashboard can be filtered by severity, confidence, report type, and project.

In addition to the vulnerability overview, the group Security Dashboard also provides a timeline that displays how many open vulnerabilities your projects had at various points in time. While security scans are automatically run for each code update, you’ll have some default branches that are infrequently updated. To keep your Security Dashboard up to date on those branches, you can use GitLab to configure a scheduled pipeline to run a daily security scan.

What’s next for GitLab Secure?

While we already have a number of ways to help you write secure code and build secure products and services, we’re always looking for ways to give you more. Here are a few of the things we’re working on:

Interactive application security testing

Interactive application security testing (IAST) checks the runtime behavior of applications by instrumenting the code and checking for error conditions. It is composed by an agent that lives inside the application environment, and an external component, like DAST, that can interact and trigger unintended results.


Fuzzing is a testing technique focused on finding flaws and vulnerabilities in applications by sending arbitrary payloads instead of valid input. The idea is to trigger exceptions and unintended code paths that may lead to crashes and unauthorized operations. Once a possible problem – like a crash – is found, attackers can attempt to find the exact conditions needed to trigger the bug and see if they can be fine-tuned to obtain a useful result. (It is worth noting that fuzzing is primarily intended for security teams because it requires more time to execute. While fuzzing is a useful testing method, it should not be a development blocker).

Vulnerability database

GitLab integrates access to proprietary and open source application security scanning tools. In order to maintain the efficacy of those scans, we strive to keep their underlying vulnerability databases up to date.

Auto remediation

Vulnerabilities that require manual intervention to create a fix and push it to production have a time window where attackers have the ability to leverage the vulnerability. Auto remediation aims to automate the vulnerability solution flow and automatically create a fix. The fix is then tested, and if it passes all the tests already defined for the application, it is deployed to production.

Photo by Daniel McCullough on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert