Integrating Coverity Scan with GitLab CI

by Synopsys Editorial Team on November 18, 2019

David Woodhouse at AWS, who maintains the open source OpenConnect VPN client, explains how he integrated Coverity Scan with GitLab CI.

By David Woodhouse at AWS

For a while, I’d been meaning to make use of the free Coverity Scan for open source projects, for the OpenConnect VPN client. A recent CVE (CVE-2019-16239) finally provoked me into actually doing it.

The online instructions cover setting it up with GitHub and Travis CI, but I couldn’t find anything about integration with GitLab. It turns out to be relatively simple, so I thought I’d write it up.

Sponsorships Available

Getting started with Coverity Scan

Registering a project at https://scan.coverity.com/ is relatively straightforward, and the process of downloading the Coverity Scan Self-Build tools and submitting your first build is fairly well documented, so I won’t go over that in detail.

In the Project Settings page, note your project token:

Setting up GitLab CI variables

We need to make the project token available to the GitLab CI processes without just hard-coding the secret into your script files where anyone can see it. The way to do this is by using CI/CD environment variables, which can be configured in the project UI:

Set up two variables:

COVERITY_SCAN_PROJECT_NAME with the name of your project in Coverity Scan.
COVERITY_SCAN_TOKEN with your Coverity Scan project token as noted earlier.

Here I’ve set the COVERITY_SCAN_TOKEN variable to masked and protected, as shown above. Masking means it will be filtered out of the CI/CD logs if it ever gets printed, while a protected variable is only available to CI/CD jobs running on protected branches—which means that other contributors can’t just create a new branch or a PR with a CI script that ROT13-encodes the token (to foil the masking) and prints it out.

For testing, I’ve also created a coverity branch in my repository, marked as a protected branch. You can protect it before it actually exists.

Go to “Repository” in the Settings.
Under “Protected Branches” in the “Protect a branch” section, type “coverity” into the “Branch” field.
Click “Create wildcard coverity.”
Set “Maintainers” as allowed to push or merge.
Click the green “Protect” button.

Adding Coverity CI instructions

With everything else set up, it’s time to finally enable Coverity Scan during the CI/CD process. You may already have GitLab CI set up. If not, it’s fairly simple to add. You just add a .gitlab-ci.yml file to your repository with the build instructions.

Those build instructions will be based on your own project’s build instructions, of course. As with the manual first submission, you run your normal build under the cov-build tool.

Here’s a template for your .gitlab-ci.yml file. You tell it you want it only to run on your coverity and master branches (since the variables won’t be available anywhere else). Then you provide a build script that downloads the Coverity Scan tools, extracts them, uses them to run your build, then submits the result.

Coverity:
  only:
    refs:
      - master
      - coverity
  script:
  - dnf update -y
  - dnf install -y git autoconf automake libtool make curl
  - curl -o /tmp/cov-analysis-linux64.tgz https://scan.coverity.com/download/linux64
    --form project=$COVERITY_SCAN_PROJECT_NAME --form token=$COVERITY_SCAN_TOKEN
  - tar xfz /tmp/cov-analysis-linux64.tgz
  - ./autogen.sh
  - ./configure
  - cov-analysis-linux64-*/bin/cov-build --dir cov-int make -j4
  - tar cfz cov-int.tar.gz cov-int
  - curl https://scan.coverity.com/builds?project=$COVERITY_SCAN_PROJECT_NAME
    --form token=$COVERITY_SCAN_TOKEN --form email=$GITLAB_USER_EMAIL
    --form [email protected] --form version="`git describe --tags`"
    --form description="`git describe --tags` / $CI_COMMIT_TITLE / $CI_COMMIT_REF_NAME:$CI_PIPELINE_ID "

Obviously, the part where it installs the dependencies, runs the autogen.sh and configure scripts, and then runs make might vary in your project. You can also tweak precisely what you put in your version and description to your liking. They’re just cosmetic and show up in the Coverity tools as your snapshot information.

Commit this file and push to your coverity branch. You should be able to watch the CI job proceed, and hopefully end with “Build successfully submitted.”

As the coverity branch is protected, you can’t force-push to it when you have something you want to test. But you can delete the branch, and its protected status is still remembered. Then you can push to it when you want to test something.

I haven’t worked out how to get pull requests automatically scanned, but I do a test pull and then push to my coverity branch for testing, and see the results that way. By doing this, I’ve already caught my first bugs in PRs that I wouldn’t otherwise have spotted.

About the Synopsys Software Integrity Community

Have a cool and interesting story using Coverity Scan? Want to write a blog post about it? Your story could be featured in the Synopsys Software Integrity Community. Email us at [email protected] for more information.

The Synopsys Software Integrity Community is the place to go for Synopsys users and those interested in learning more about building faster, more-secure software. Take advantage of free tutorials and articles, and connect with like-minded peers.

Visit us at community.synopsys.com