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.
Testing
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
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
