Skip to main content

Use Snyk Vulnerability Scanning

  • Status: accepted
  • Deciders: @dynamike, @pjdufour-truss
  • Date: 2018-08-13

Context and Problem Statement​

An area of security risk to MyMove is supply-chain risk. In the context of software development, supply-chain risk is the risk that a malicious actor could insert malicious code somewhere into a source code dependency. The actor could attack a dependency directly by modifying a git repo, upload bad code to a package manager, man in the middle during the build process, or a wide variety of other scenarios.

Scanning software for known vulnerabilities (e.g., CVEs) is a critical step for mitigating supply-chain risk. However, it does not completely mitigate against zero-days, custom attacks, or other supply-chain attacks.

Decision Drivers​

  • Seamlessly integrates into our CI/CD workflow
  • Scans JavaScript for known CVEs
  • Scans Golang dependencies for known CVEs
  • Maintenance cost

Considered Options​

  • GitHub
  • Sonatype
  • Snyk
  • SonarQube
  • Twistlock

Decision Outcome​

Chosen option: "Use Snyk for Vulnerability Scanning". We'll use snyk test and snyk monitor for one-time tests and monitoring of our dependency tree.

Pros and Cons of the Options​

GitHub​

  • Good, scans JavaScript
  • Bad, does not scan Go
  • Bad, run as a cron job scheduled by GitHub
  • Bad, cannot run as part of our CI/CD workflow
  • Good, no maintenance cost

Sonatype​

  • Good, scans JavaScript
  • Bad, does not scan Go at this time.
  • Bad, it would require rearchitecting our entire CI/CD pipeline

Snyk​

  • Good, scans JavaScript
  • Good, scans Go
  • Good, could fit into our CI/CD workflow with some shell scripting.
  • Bad, GitHub integration requires write access to repos.
  • Bad, vulnerability database for Go seems limited.

SonarQube​

SonarQube is a leading open source product for continuous code quality, including a "quality gate" that integrates seamlessly into CI/CD workflow.

  • Good, scans JavaScript
  • Unsure, scans Go (not sure it scans for CVEs)
  • Good, seamlessly integrates into CI/CD workflow
  • Bad, requires running our own instance on EC2.

Twistlock​

Twistlock looks like it is working on amazing things, but doesn't satisfy our requirements for scanning for known vulnerabilities before deploy.

  • Good, container-first approach and we use containers.
  • Bad, no deep scans for known vulnerabilities (CVEs)
  • Bad, doesn't seamlessly integrate into our CI/CD workflow for this requirement.