Inserting security in GitLab merge requests!

Inserting security in Gitlab merge requests!

ShiftLeft Inspect introduces an easy way to insert static code analysis in merge requests workflow in GitLab. To know more, read on.

GitLab offers merge request workflow in their premium version that is analogous to pull requests in Github, although they differ slightly in their implementation. This blog assumes a Gitlab source repo being used with GitLab CI Pipelines using Linux based runners.

DevOps Connect:DevSecOps @ RSAC 2022

How does the merge/pull request based security workflow looks like?

Just as in the case of Github, ShiftLeft is proposing that static analysis tools will need to live as ideal citizens of developmental merge request workflow in GitLab.

Here are five steps to integrate ShiftLeft Inspect into the GitLab Merge request workflow!

These five steps include the configuration of pipelines and the activation of simple scripts.

Mandate pipeline success as merge check condition

GitLab administrators can edit your project properties and enable the “pipelines must succeed” option.

<gitlab_name>/<project>/ General Settings → Merge requests

Configure GitLab Pipelines configuration file and include Code analysis

ShiftLeft Inspect code review can be inserted into the .gitlab-ci.yml file that controls the jobs executed in GitLab pipelines. The following could be added to the YAML file to invoke code analysis during merge_requests

Analyze code through Inspect:
stage: test
- build:app
- sh
- merge_requests

and also add file with the below code to the root of the project code repository. This shell script is invoked by the code snippet that was added to file.


echo "Got merge request $CI_COMMIT_REF_NAME for branch $CI_PROJECT_NAME!!"

# Install ShiftLeft
curl > /tmp/sl.tar.gz && tar -C /usr/local/bin -xzf /tmp/sl.tar.gz

# Analyze code
sl analyze --version-id "$CI_COMMIT_SHA" --tag branch="$CI_COMMIT_REF_NAME" --app "$CI_PROJECT_NAME" --wait target/<war/jar file name>

# Run Build rule check
BUILDRULECHECK=$(sl check-analysis --app "$CI_PROJECT_NAME" --branch "$CI_COMMIT_REF_NAME")

if [ -n "$BUILDRULECHECK" ]; then
MR_COMMENT="Build rule failed, click here for vulnerability list - $URL"
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "body=$MR_COMMENT"
exit 1
MR_COMMENT="Build rule suceeded, click here for vulnerability list - $URL"
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "body=$MR_COMMENT"
exit 0

The previous steps require that you have an appropriate ShiftLeft Inspect license and have added the necessary tokens (Org ID, Access Token, and API Token) as environment variables for your GitLab pipelines. You also need to configure a personal access token in GitLab for API access and name it as PRIVATE-TOKEN in GitLab CI pipeline environment variables as stated above. The script above also assumes you have configured your build rules as explained below.

Configure Build rules

ShiftLeft Inspect has a powerful build rule feature where you can define the security approval conditions for a merge/pull request. To invoke it during the merge request approval process, check in a file named shifleft.yml in the root repository of your project code repository. A sample code snippet for shiftleft.yml file is below.

Bringing it all together

Now we are all set. Here is a quick video of the workflow in action.

You can try ShiftLeft for free by signing up here.

Inserting security in GitLab merge requests! was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Alok Shukla. Read the original post at: