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:
Fix pull request to help you fix vulnerabilities by either upgrading the direct dependencies or patching the vulnerability.
Jira integration to enable you to create issues in Jira.
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:- nodescript:- pipe: snyk/snyk-scan:0.4.3variables:SNYK_TOKEN: $SNYK_TOKENLANGUAGE: "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:
SNYK_TOKEN is being passed into our pipe as a repository variable previously defined in the [Bitbucket Configuration]() module.
PROJECT_FOLDER is the folder in which the project resides and normally defaults to
.. However, in our example, we have set this to
are passing this as an artifact to other steps in our pipeline.
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
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.
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