Security Features of GitLab

In 2020, GitLab made a number of significant improvements to the safety of its platform and its products. The major objective of implementing multiple security measures was to increase GitLab’s enterprise-grade security, and this was achieved, which further lead to the successful completion of their first SOC 2 Type 2 attestation. 

 

During their field security research, they collected and analyzed information from the actual and potential clientele, as well as the larger community, the industry, and several internal stakeholders (sales, support, and product). Furthermore, Gitlab has adopted different strategies meant to further improve security and bolster the faith and trust of our customers.

 

To aid in the delivery of safe applications and licensing compliance, GitLab offers Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Container Scanning, and Dependency Scanning.

 

Distinct Security Features of GitLab 

 

SAST 

GitLab CI/CD has a feature called Static Application Security Testing (SAST) that may be used to scan your code for common flaws. There is no GitLab plan that cannot host SAST analyzers. Analysis jobs produce reports in JSON format.

 

The SAST analysis findings are processed in GitLab Ultimate so that you can:

• View them in pull requests.

• Put them to use in your approval processes.

• The security dashboard is where you can check these out.

 

The default operating mode for SAST is the test phase. Redefining the stages in the.gitlab-ci.yml file requires the test stage to be present.

 

Secret Detection

Secret information being unwittingly added to remote Git repositories is a common issue for developers working on applications. Keys, passwords, API tokens, and other forms of cryptographically protected data fall under the category of secrets. A bad actor could gain access to the secrets stored there and utilize them for their own nefarious ends. The cost of replacing secrets that have been compromised in this way is high. Avoiding the accidental submission of sensitive information to a Git repository is crucial.

 

Secret Detection makes use of a predefined set of rules that includes over 90 unique secret detection patterns. Secret detection patterns can be further personalized with user-defined rule sets. In order to contribute rulesets for “well-identifiable” secrets, please refer to the community contributions standards and follow the instructions given there.

 

Code Quality 

GitLab CI/CD can inspect your source code and help you keep your project’s code clean, understandable, and amenable to collaboration.

 

You can use Code Quality reports, for instance, to see how alterations to your code are influencing its quality while you work on a feature’s implementation. This data might help you check whether or not your modifications are having a negative effect on performance.

 

DAST

Deploying web software into a new environment can leave it vulnerable to assaults not seen before. Source code may not reveal problems such as application server misconfigurations or wrong assumptions about security protections.

 

Applications in production can be tested for vulnerabilities like this via Dynamic Application Security Testing (DAST). To do its analysis, DAST makes use of the free and open-source OWASP Zed Attack Proxy.

 

When GitLab receives the report that DAST has generated, it examines it to see if any security flaws have been detected between the two branches. The merge request includes a summary of relevant findings.

 

Only the most recent pipeline run for the base commit of the target branch is used by the comparison logic. The status of the merge request is unaffected by the pipeline’s execution on other contributions.

 

API Security 

GitLab CI/CD pipelines now support dynamic application security testing (DAST) for web APIs. In doing so, you can find flaws and potential security holes that might be missed by other QA procedures.

 

In addition to the additional security scanners provided by GitLab Secure and your own testing processes, DAST API testing is highly recommended. You may integrate DAST API testing into your GitLab CI/CD pipeline.

 

Fuzz Testing 

An instrumented version of your application receives random inputs during coverage-guided fuzz testing, with the goal of triggering unexpected behaviour. If the system acts in this way, you know there’s a bug you need to fix. This aids in finding flaws and potential security holes that may be missed by other QA procedures.

 

Dependency Scanning 

While building and testing your apps, the Dependency Scanning function can help you locate any potential security flaws in your software dependencies. A good example is dependency scanning, which can reveal if a vulnerable external (open source) library is being used by your programme. Then, you can take precautions to keep your application secure.

 

When discussing Software Composition Analysis, dependency scanning is commonly included (SCA). Inspecting the components your code relies on is one type of testing that can be included in SCA. Application and system dependencies are examples of such elements, and they are nearly always imported from external sources rather than originating in anything you authored yourself.

 

Container scanning 

It’s possible that your application’s Docker image is built off of other Docker images that are vulnerable themselves. You may use GitLab to do an audit of your Docker-based apps by adding an additional Container Scanning job to your pipeline, which will search for such vulnerabilities and display them in a merge request.

 

Software composition analysis typically includes container scanning (SCA). Inspecting the components your code relies on is one type of testing that can be included in SCA. Application and system dependencies are examples of such elements, and they are nearly always imported from external sources rather than originating in anything you authored yourself.

 

License Compliance 

License Compliance is a feature of GitLab CI/CD that allows you to investigate the legality of each dependency in your project. You’ll have the option of approving or rejecting each license as needed. If your app depends on a third-party (open source) library and that library’s license conflicts with your own, you can choose not to utilize it.

 

License Compliance uses the License Finder scan tool as part of the CI/CD pipeline to identify the licenses in use. There is no job in the queue upon which the License Compliance task depends.