Application Scanning

Snyk Open Source

Background

Scanning your application for vulnerabilities in your open source dependencies begins at the source. Earlier, when we enabled the Snyk integration to Bitbucket and imported our first project we saw vulnerability counts based on our packages.json as well as detailed information for each.

When you review the results in Snyk, you not only receive context such as severity and exploit maturity for your vulnerabilities. You also receive the following powerful features:

Snyk Vuln Details

  • Fix pull request to help you fix vulnerabilities by either upgrading the direct dependencies or patching the vulnerability.
  • Priority Score to help you effectively prioritize fixes. The score, ranging from 1-1000, is powered by a proprietary algorithm that processes a wide array of factors, such as CVSS score, the availability of a fix known exploits, how new the vulnerability is, and whether it is reachable or not.
  • Jira integration to enable you to create issues in Jira.

Application scanning in your pipeline

The bitbucket-pipelines.yml file defines your Pipelines builds configuration. If you’re new to Pipelines you can learn more about how to get started here.

In this workshop, we have provided you with a sample bitbucket-pipelines.yml file that contains distinct steps mapped to our workflow. We will scan the application, build the Docker image, scan the container image, then deploy the application to a Kubernetes cluster. Let’s take a closer look at the application scanning step:

scan-app: &scan-app
  - step:
      name: "Scan open source dependencies"
      caches:
        - node
      script:
        - pipe: snyk/snyk-scan:0.4.3
          variables:
            SNYK_TOKEN: $SNYK_TOKEN
            LANGUAGE: "npm"
            PROJECT_FOLDER: "app/goof"
            TARGET_FILE: "package.json"
            CODE_INSIGHTS_RESULTS: "true"
            SEVERITY_THRESHOLD: "high"
            DONT_BREAK_BUILD: "true"
            MONITOR: "false"

In this example, we are leveraging the Snyk Scan pipe in our pipeline to perform a scan of our application. Our source contains a complete, YAML definition of all supported variables, but only those included in this snippet are necessary for our purpose.

Let’s take a closer look at a few of these:

  1. SNYK_TOKEN is being passed into our pipe as a repository variable previously defined in the Bitbucket Configuration module.
  2. PROJECT_FOLDER is the folder in which the project resides and normally defaults to .. However, in our example, we have set this to app/goof and are passing this as an artifact to other steps in our pipeline.
  3. CODE_INSIGHTS_RESULTS defaults to false. However, we will want to create Code Insight report with Snyk test results so we have set this to true.
  4. SEVERITY_THRESHOLD reports on issues equal or higher of the provided level. The default is low but in our case, we are interested only in high so we have defined this variable accordingly.
  5. DONT_BREAK_BUILD the default is false and this is to be expected. Under normal circumstances we would want to break our build if issues our found. However, for the purpose of this learning exercise we are setting this to true.

You can run Snyk security scans on your pull requests and view results in Code Insights with the help of a brand new Snyk Security Connect App on the Atlassian Marketplace. It’s easy to get started and you can install the app with just a few clicks.