GitLab SAST is a combination of GitLab— an integrated solution that covers the entire DevOps lifecycle — and, Klocwork — a static code analysis and SAST tool. When used together, these tools provide software development teams with a powerful GitLab SAST solution. Here we explain the benefits of GitLab SAST.
Read along or jump ahead to the section that interests you the most:
What Is GitLab?
GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager for wiki, issue-tracking, and CI/CD Pipeline features. It was developed by Gitlab Inc. and released in 2011.
Software development teams have used GitLab to unite their developers’ workflows and shorten DevOps cycle times — enabling them to produce higher-quality software.
GitLab is used by software development teams from a variety of industries, including aerospace and defense, automotive, medical device, and video game development.
Back to topWhy GitLab Users Should Use Klocwork
GitLab is a popular DevOps lifecycle tool because it shortens cycle time, reduces engineering risk, helps to ensure more secure applications, and bridges silos and stages. So it makes sense that many developers also use a static application security tracking (SAST) tool like Klocwork to complement GitLab.
How Klocwork Complements GitLab
Klocwork is a static code analysis and SAST tool that has been designed to optimize DevSecOps processes, like CI/CD Pipelines.
📕 Related Content: Using GitLab with Helix QAC
Differential Analysis
Using system context data from the server, Klocwork is able to analyze only the files that have changed while also providing Differential Analysis results as if the entire system had been analyzed. This provides you with the shortest possible analysis times of new and changed code.
📹 Related Resource: See a Demo of Differential Analysis
Integration Analysis
Using system context data from the server, Klocwork is able to provide a snapshot of the current health of your software project. After each Integrated Analysis, Klocwork will provide a list of detected coding issues along with other reports on your code. By regularly running Integrated Analysis, you are able to improve code quality and ensure uniformity across your codebase.
Back to topUsing GitLab with Klocwork
There are many ways to integrate Klocwork’s static analysis tools within a continuous integration system such as GitLab, as Klocwork provides a command-line interface and flexible tooling to fit most workflows. Suggested here is one example of how Klocwork can be integrated into a DevSecOps workflow, using developer feature branches.
The designed workflow shows a simplified version of developers creating their own feature branches to develop new features or resolve known defects. Once the new feature or bug has been resolved the code is merged into the main branch ready for release.
With Klocwork’s tools, you can create a baseline of the known issues within the codebase using the Integration Analysis tool. These results then become viewable to all via the web portal and can be deferred to a later date or assigned to be fixed. This integration analysis also provides the full project context and existing issue data that the differential analysis utilizes.
Here with the Differential Analysis it is now possible to check on the server-side if the developers commit includes new defects and that should the branch be merged would add technical debt to the project.
It is then configurable to provide feedback via GitLab to the developer that their commit contains new defects as they develop and fail pull requests based on quality gate criteria such as no new defects.
The defects blocking the merge request are fully viewable through the Validate web portal by selecting the link with the GitLab merge. This provides full defect diagnostic information overlayed on source, providing the ability to triage and enable the merge to be passed.
📕 Related Content: What Are Quality Gates?
Watch the following video, Using Klocwork as a Quality Gate in GitLab, to see how it works:
Set up GitLab SAST
To set up the GitLab and Klocwork integration, watch the following tutorial:
If you don't want to watch the video, here are the step-by-step instructions for how to set up GitLab SAST:
1. Install GitLab
First, you’ll need to install GitLab. If you’ve already done this, skip to the next step.
To install GitLab:
- Go to about.gitlab.com and click install GitLab.
- Select your preferred GitLab Omnibus package.
- Install and configure the necessary dependencies.
- Add the GitLab package repository and install the package.
- Browse to the hostname and login.
- Set up your communication preferences.
- Launch GitLab.
2. Install Klocwork
Next, you’ll download Klocwork.
If you’re not using Klocwork yet, get started here >>
If you’re already a Klocwork user, download the latest version here >>
3. Configure GitLab Runners
A runner needs configuring where the Klocwork analysis will take place, either by connecting to an existing machine via ssh or by configuring a docker image with Klocwork.
Klocwork provides analysis tool packages for the differential and integration analysis, which means it is simple to deploy to a machine by copying it over and extracting.
The runner should be configured with a tag to identify the runner is capable of a Klocwork analysis, this can then be utilized in the job steps. In these examples, the tag ‘klocwork’ has been used.
4. Klocwork Integration Analysis
This provides the baseline of existing issues, full project context, web portal overview of health, and trending. It is the backbone of the Klocwork analysis and for this example, we will configure it to run only on commits to the master branch, which given the workflow should be coming from pull requests.
Editing the “.gitlab-ci.yml” for the project:
Introducing variables into the file for the Klocwork server and project that this relates to will simplify the configuration.
The Integration Analysis is command-line based, here it has been filtered to only run on the master branch as part of the testing phase. Using the same procedure of capture, analyze, and load as normal.
5. Klocwork Differential Analysis
With the integration analysis performed and at least one baseline available in the project, it is now possible to analyze changes quickly without previous local analysis data.
Within the same yml file for the project, it is possible to also configure the Differential Analysis. This time running on everything except the master branch ( i.e any developer feature branches and/or merge requests). In this example, the differential analysis has been restricted to only run when the merge request has been opened. It is configured to run the Klocwork differential tool ‘kwciagent’. The steps taken are as follows:
- Capture build data using Klocwork’s tooling.
- Create a local workspace for Klocwork using 'kwciagent create'.
- Generate a text file which should contain a list of the changed files in this commit without any formatting (one file per line). Shown is an example git diff command to generate this, it requires a reference to diff against, of which we use the target branch variable from GitLab CI's predefined variables.
- Run the analysis, however, it is filtered only to run on the changed files bypassing the diff list text file as an argument.
- Run the 'kwciagent sync' command to upload the potential new defects to the Validate web portal for review, giving a unique ID reference to identify this pipeline run.
- Using a simple Python script to access both the Validate API and GitLab API, it is possible to automatically retrieve the count of uploaded defects in order to fail the pipeline and block the merge request, as well as add the defect URLlink to the comments section in the merge request.
How GitLab SAST Looks
As feature branches are created and pull requests committed it is then possible to get an overview of the analysis runs:
On the Differential Analysis above, note that the run is marked as failed due to the introduction of new issues to the code in respect to the baseline. It’s also shown by the tick and then cross that it failed on the second stage, which in this case means that the build was successful however the testing phase failed.
On the pull request, it is now possible to view if the pipeline has been successful in the development feature branch, providing warnings against merging.
Also note that during the configuration, the quality gate created a comment using the GitLab API that links to the possible new issues in the files scanned:
GitLab SAST — The Full Cycle
With the pull request showing warnings against merging it is possible to resolve the defects and re-commit, or ignore issues allowing them through the gate. GitLab will automatically run the differential analysis on the new commit and update the status on the pull request.
Once merged into the master branch a full integration is then performed again to create the new baseline, capturing the changing made by the merge and this can be shown below.
Get Started with GitLab SAST
Start optimizing your DevSecOps process with GitLab and Klocwork today.