This article shows you how to integrate ShiftLeft CORE's NG SAST into your GitLab Merge Request Workflow for automated code analysis whenever you create a new PR.
Set the environment variable
However, when running in a production environment, we recommend using a CI token as the access token. You can create your CI token in the ShiftLeft Dashboard.
Please note that the presence of any set environment variables will override those in a configuration file.
GitLab API access
Configure a personal access token to authenticate ShiftLeft with the GitLab API. Name it
MR_TOKEN for use in the bash script used to run NG SAST, and make sure to assign it the
Step 1: Mandate successful merge checks
As a GitLab administrator, you can edit your project properties to enforce branch protection rules. Go to Settings > General and expand the Merge Requests section. Scroll down to Merge checks and make sure that both are checked:
- Pipelines must succeed
- All discussions must be resolved
Step 2: Configure the GitLab Pipelines configuration file and include code analysis
The .gitlab-ci.yml file controls the jobs executed in GitLab pipelines, and this is where you can insert instructions to run the NG SAST code review process.
If you don't already have a .gitlab-ci.yml file in your project repository, you must create one.
Once you've created the configuration file, you can add the following snippet to the rest of your YAML file to invoke code analysis for merge_request events:
Here is what a complete .gitlab-ci.yml file could look like for a Maven project:
Note that the configuration file calls a script called sl-analysis.sh. You will need to add the file, which includes the code shown below, to the root of your repository (be sure to modify the placeholder variables as indicated in the file's comments):
Please note that the script above includes a section that runs build rules; we will cover build rules in the following sections.
Step 3: Configure your build rules
NG SAST allows you to create build rules, which define the security approval conditions that must be met before merging a merge request.
You can define build rules in a configuration file. By default, the name and location of your configuration file in your repository should be shiftleft.yml. The file should be formatted as follows:
Step 4: Push your files to GitLab
Once you've created the following files, commit them to your project and push them to GitLab:
Please note that GitLab will automatically create a pipeline for you once you push .gitlab-ci.yml.
Step 5: Testing the workflow
At this point, you can test your workflow. When you begin merging your changes into your master branch, ShiftLeft will run, analyze your code, and indicate whether the merger should fail or not based on the build rules you define.
For example, if one of your build rules is violated, you will see the following result in your build logs:
GitLab will also report that a build rule failed: