Add semgrep as new scanner for static analysis

🚓 New Scanner implementation request

Is your feature request related to a problem

As a secureCodeBox user I would like to use semgrep for static application security testing.

Describe the solution you'd like

Integrate semgrep as a SAST scanner. Provide how-tos and parser.

Describe alternatives you've considered

Snyk Code

Additional context

Steps to implement a new scanner

Hint: A general guide how to implement a new SCB scanner is documented here

@ammerzon

Hi @ammerzon,

thx for your proposal 😀

For anyone interested in what semgrep exactly is please find a helpful slide deck here.

We also already thought about integrating semgrep and on the first sight it shouldn't be very hard, because there is already a container image available and JSON Output is supported 👍🏻

docker run --rm -v "${PWD}:/src" returntocorp/semgrep --help
--json Output results in JSON format.

But there are some questions to takle with:

semgrep is a typical SAST scanner, most of the secureCodeBox scanners are DAST scanners so far. Do you think it would be valuable to add SAST scanners or isn't this something already handled somewhere else (CI pipeline)?
The question is also how to ensure the (git) sourcecode is available in a volume mount 🤔
Should this be combined with the already existing git-repo-scanner? Gitleaks is also a more SAST like scanner, but it comes with an git pull repo already included 😅

Would be nice to hear what you or other community members might think about this topic "SAST @ secureCodeBox?"

Hi @rseedorff,

I have asked myself these questions as well. I thought it may be useful to have SAST abilities in SEC so you have a unified dataset of different scanners and are now enable to combine or merge the results. A few use-cases came to my mind:

Match reported vulnerabilities from DAST scanners with the ones from SASTs. I do not know exactly if this is possible and this is probably a research area in itself.
Unified dashboard of the scanners results similar to Gitlab's security dashboard.

Regarding the source code. I think it would be beneficial to add a git pull <repo> functionality like the one in git-repo-scanner.

It is fine to add more scanners, but let's then define the product requirements/scope of secureCodeBox a bit better.

I think git-repo-scanner, SAST, etc. are all relevant to audit a software development process. That's a different game to pentesting something that's running already. So, while the extra functionality seems interesting, how can the user specify the scope of an engagement? We need clear metadata/organization of the scanners, etc.

@sanmai-NL

@sanmai-NL I am total with you because right now I have the feeling that SCB is more marketed as a toolchain for pen-testing tools.

What do you mean exactly by specifying the scope of an engagement?
Maybe an organization by scanner type would be beneficial (container scanning, dependency scanning, DAST, SAST, etc.) like Gitlab's approach?

Say, the engagement should focus on pentesting infrastructure, be it dev related or just IT in general. Then SAST doesn't make sense (unless you stretch it far and take information from vulns to test the actual software, deployed somewhere). So the scope should be configurable somehow, based on scanner classes (IT, dev, etc.).

Agree on a lot of the arguments here.

Personally think its preferrable to have SAST checks running locally in the idea / console and in the ci.
Its just a lot closer to the code and the developers than a Kubernetes cluster.

There are usecases where an organisation would still want to run a mass number of scans against all repos at once.
For these cases the secureCodeBox would be a great match by using them with cascading scans with the git-repo-scanner.

I'd propose that the extend the Scan CRD a bit with optional fields to better support SAST tools to solve the problem on how the code should get into the scan container.

I'd propose something like this:

apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
  name: "semgrep-juiceshop"
spec:
  scanType: "semgrep"
  parameters:
    - "--config"
    - "p/ci"
    - "/etc/repo"
  prepopulateFilesystemFrom:
    git:
      url: https://github.com/bkimminich/juice-shop.git
      to: /etc/repo
      secretRef:
        name: https-credentials
---
apiVersion: v1
kind: Secret
metadata:
  name: https-credentials
type: Opaque
data:
  username: <BASE64>
  password: <BASE64>

The operator would automatically add a init container, which would clone the repo into a empty-dir volume shared with the scanner container. That would allow to integrate most SAST tools operating on a file system relatively easily.

@J12934

I completely agree with @J12934 .

I think, however, that we should carefully look at the different data sources that scanners could use.

@J12934 gave the valid example of a git source. I can think of the following:

Code from SVN
Files from specific API endpoint
Retrieve posts from RSS feeds

I'm sure you can think of more. In any case, to make SAST scanners for secureCodeBox extremely useful, users should have complete control over the data source. Ultimately, contributes may easily add new data retrievers.

Ideally, a single update to the scan spec should work with any added data retrievers.

apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
  name: "semgrep-juiceshop"
spec:
  scanType: "semgrep"
  parameters:
    - "--config"
    - "p/ci"
    - "/etc/repo"
  prepopulateFilesystemFrom:
    dataType: git
    mountPoint: /etc/repo
    secretRef:
      name: https-credentials
    options:
      "repo_url": "https://github.com/bkimminich/juice-shop.git"

Where both the secret and the options are mounted as environment variables. In this manner, the options can stay dynamic and usable for each added data retriever. The field dataType is thus similar to scanType.

Maybe the mountPoint should even be declared in the scanners' ScanType spec?

@EndPositive

Hi @EndPositive
sorry forgot to reply. Yes the datastructure was already meant to support other usecases other then git.
I wanted it to be similar to other kubernetes configs e.g. volumes in pods which supports many different providers. https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#volume-v1-core

E.g. for downloading a single file from a url:

apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
  name: "semgrep-juiceshop"
spec:
  scanType: "semgrep"
  parameters:
    - "--config"
    - "p/ci"
    - "/etc/repo"
  prepopulateFilesystemFrom:
    http:
      url: https://example.com/foobar.cpp
      to: /etc/repo/foobar.cpp

I have pulled out the discussion about pre-populating the file system into a separate issue (#707) for further planning and implementation (I will be working on this). Once that is settled and implemented, I will start looking into implementing semgrep support.

Navigation Menu

Repository navigation

Add semgrep as new scanner for static analysis #595

🚓 New Scanner implementation request

Is your feature request related to a problem

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Steps to implement a new scanner

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add semgrep as new scanner for static analysis #595

Description

🚓 New Scanner implementation request

Is your feature request related to a problem

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Steps to implement a new scanner

Activity

rfelber commented on Aug 20, 2021

ammerzon commented on Aug 23, 2021

sanmai-NL commented on Aug 25, 2021

ammerzon commented on Aug 25, 2021

sanmai-NL commented on Aug 25, 2021

J12934 commented on Aug 27, 2021

EndPositive commented on Aug 28, 2021

J12934 commented on Oct 5, 2021

malexmave commented on Oct 6, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions