How do I run Security Code Scan in a GitLab pipeline?

Question

I am trying to integrate the Security Code Scan with Gitlab CI. I read the documentation but still, I can't understand how exactly must write commands for SCS in yml file (source file: warning SCS[rule id]: [warning description] [project_file]). My Gitlab is hosted on Windows 10 machine without a container. The project is .NET Framework 4.6.2 and I use Visual Studio 2019. I already get an SCS package from NuGet.Also, I have read about Fortify but I am stuck on the same problem.

Answer 1

With GitLab 13.9 (February 2021), this will work for multiple projects too:

Multi-project support for .NET SAST scanning

GitLab security scans automatically detect code language and run appropriate analyzers.

With monorepos, microservices, and multi-project repositories, more than one project can exist within a single GitLab repository. Previously our .NET SAST tool could only detect single projects in repositories.

With this release, our .NET SAST analyzer can now intelligently detect multiple solution files (.sln) in .NET projects and report vulnerabilities across them.
This will make it easier and more streamlined for users with multi-project .NET repos to leverage our SAST scanning.

See Documentation and Issue.

And it is more visible (still with GitLab 13.9, February 2021)

Security Configuration page for all users

With SAST and Secret Detection available to all GitLab customers, we wanted to improve the experience for developers enabling available security scans. We have had a guided configuration experience for Ultimate users and have now made a simplified version of this experience available to all users. This new configuration experience makes it easier for developers to understand which security scans are available to them, find relevant documentation, and provide simple enablement tools. With this initial release, we support a button to create a merge request for SAST. In a future release, we will add additional buttons to easily enable other scan types.

-- Security Configuration page for all users

See Documentation and Epic.

---

It does evolve with GitLab 13.11 (April 2021)

GitLab + Semgrep: upgrading SAST for the future

GitLab SAST historically has been powered by over a dozen open-source static analysis security analyzers. These analyzers have proactively identified millions of vulnerabilities for developers using GitLab every month.
Each of these analyzers is language-specific and has different technology approaches to scanning. These differences produce overhead for updating, managing, and maintaining additional features we build on top of these tools, and they create confusion for anyone attempting to debug.

The GitLab Static Analysis team is continuously evaluating new security analyzers. We have been impressed by a relatively new tool from the development team at r2c called Semgrep.
It’s a fast, open-source, static analysis tool for finding bugs and enforcing code standards.
Semgrep’s rules look like the code you are searching for; this means you can write your own rules without having to understand abstract syntax trees (ASTs) or wrestle with regexes.

Semgrep’s flexible rule syntax is ideal for streamlining GitLab’s Custom Rulesets feature for extending and modifying detection rules, a popular request from GitLab SAST customers. Semgrep also has a growing open-source registry of 1,000+ community rules.

We are in the process of transitioning many of our lint-based SAST analyzers to Semgrep.

This transition will help increase stability, performance, rule coverage, and allow GitLab customers access to Semgrep’s community rules and additional custom ruleset capabilities that we will be adding in the future. We have enjoyed working with the r2c team and we cannot wait to transition more of our analyzers to Semgrep. You can read more in our transition epic, or try out our first experimental Semgrep analyzers for JavaScript, TypeScript, and Python.

(So not yet for .Net, but soon)

We are excited about what this transition means for the future of GitLab SAST and the larger Semgrep community.
GitLab will be contributing to the Semgrep open-source project including additional rules to ensure coverage matches or exceeds our existing analyzers.

See Documentation and Epic.

The same GitLab 13.11 announces:

• OpenShift Support for SAST and Secret Detection
• Experimental Semgrep Analyzer for Python, JavaScript, and TypeScript
• Support for Generic Kotlin SAST Scanning

---

See GitLab 13.12 (May 2021)

Semgrep SAST Analyzer for JavaScript, TypeScript, and Python

In GitLab 13.11 we announced an experimental release of Semgrep, a new SAST analyzer for JavaScript, TypeScript, and Python. This transition has been developed in partnership with r2c, the team behind Semgrep who share our mission to help developers write more secure code. After an extensive beta with hundreds of customers trying out our experimental analyzer, we’re ready to start the transition to Semgrep.

With 13.12, we’re updating our managed SAST.gitlab-ci.yml CI template to automatically run this new analyzer alongside our existing JavaScript and TypeScript analyzer, ESlint. In a future release we will fully disable ESLint, but for now it will work in unison with Semgrep. We’ve done work to deduplicate findings, so you should not notice any difference in findings. If you include our SAST.gitlab-ci.yml, you don’t need to do anything to start benefiting from the Semgrep analyzer, however if you override or manage your own SAST CI configuration, you should update your CI configuration.

Both GitLab and r2c are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We’ll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We’ve created a feedback issue where you can share your experience with this transition or ask questions.

See Documentation and Epic.

---

See GitLab 15.0 (May 2022)

Semgrep-based SAST scanning available for early adoption

You can now switch to Semgrep-based scanning for many languages in GitLab SAST. Semgrep-based scanning brings significantly faster analysis, reduced usage of CI minutes, and more customizable scanning rules compared to existing language-specific analyzers. As of GitLab 15.0, it supports C, Go, Java, JavaScript, Python, and TypeScript.

In a future release, we’ll change GitLab SAST to use only Semgrep-based scanning by default for supported languages, and we’ll remove the language-specific analyzers that also scan them. (This change was previously scheduled for GitLab 15.0; work to complete it is tracked in this deprecation issue.)

You can now choose to disable deprecated language-specific analyzers early and use Semgrep-based scanning instead before we change the default behavior. We’ve updated documentation to explain the transition, including guidance on when to make the change in your pipelines.

See Documentation and Issue.

Answer 2

Per the GitLab docs, you really just add this include to your main .gitlab-ci.yml file.

include:
  - template: Security/SAST.gitlab-ci.yml

The template defines a job that uses a custom Docker image and Go wrapper around the Security Code Scan package. It actually dynamically adds the SCS package to discovered projects, runs a build, and captures and parses the output in order to produce the security report.

It does things this way because the Security Code Scan project runs as an analyzer at build time... it's not a normal CLI application, although there are mostly ignored issues asking for this option.

---

Update: You could just add the Security Code Scan package to your project(s)

$ dotnet add package SecurityCodeScan --version 3.5.3

And run a normal build in your GitLab pipeline, reading the warnings that are produced in the pipeline logs.

build:
  stage: build
  image: mcr.microsoft.com/dotnet/core/sdk:3.1
  script:
    - dotnet build

You could enable TreatWarningsAsErrors to break the build, too.

dotnet build /p:TreatWarningsAsErrors=true

<PropertyGroup>
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<PropertyGroup>

You won't get a nice MR attached report this way, just pipeline logs. The interactive pipeline report doesn't appear unless you have a Gold plan, anyway.