FAQs

About known vulnerabilities

What are known vulnerabilities?

Known vulnerabilities are publicly disclosed security bugs, typically found and logged by users, or reported by security researchers. Being public makes these issues the easiest ones for attackers to find and exploit [1], and therefore very important to address.

What are direct and deep dependencies?

Known vulnerabilities can be introduced either via a direct or via a deep dependency.

  • A direct dependency is a package that you’ve included in your own project via package.json or Gemfile.
  • A deep dependency, also referred to as an indirect, chained, or transitive dependency, is a package that you are not using directly, but one that is used by one of your direct dependencies.

In other words, if your application is using package A, and package A is using package B, then your application is indirectly depending on package B. And if package B is vulnerable, you are vulnerable.

How do you determine the severity of a vulnerability?

The severity of a vulnerability is manually assigned by our security research team. It’s based primarily on the impact of the vulnerability, and by how easy it is to exploit it.

For instance, the bassmaster vulnerability allows an attacker to execute code on your server (a “remote command execution” vulnerability), and can easily be exploited with a well crafted request, making it a high severity issue. The dns-sync vulnerability also allows remote command execution, but to exploit it an attacker needs to control the name of the host you resolve - a less likely scenario. Therefore, it was deemed medium severity.

Why should I monitor my projects for known vulnerabilities?

New vulnerabilities aren’t actually new security holes - they’re newly disclosed, but impact old, existing code. This means you could have new known vulnerabilities without making any code changes. Watching your GitHub repos or local projects means you’ll be the first to know if you are affect by a newly disclosed vulnerability, and you can assess and act upon the vulnerability risk quickly.

Fixing vulnerabilities

What can I do if I’m vulnerable?

If possible, the cleanest and best way to address a vulnerability is to upgrade to a vulnerability-free version of the package you’re using. In most cases, disclosed vulnerabilities are fixed shortly after they’re discovered, and all you need to do is upgrade to the relevant version.

If you can’t upgrade, because there is no sufficient direct upgrade available, or because the upgrade includes breaking changes you can’t take on right now, your next best option is to apply a patch. A patch changes the locally installed package file to fix the vulnerability.

  • For Node.js projects, you can apply patches either via a GitHub pull request with fixes, or by running Snyk wizard.
  • Patching is currently not supported for Ruby. You can open a pull request to ignore vulnerabilities that can’t be fixed.

What does patching mean?

A patch will make the minimum changes required to your locally installed package files, to fix the vulnerability. Patching is a good option to fix vulnerabilities when you can’t upgrade. If you’re monitoring your project, we will notify you once an upgrade becomes available. Note that patching isn’t supported yet for Ruby projects.

Can patching break my code?

We test all patches we release rigorously, and keep the changes a patch makes to your code to a minimum. We haven’t seen a single case where our patches broke intended functionality. However, we can’t guarantee that a patch won’t break something. If you are unsure, it’s best to take a look at the patch before applying it.

When I can choose, how should I decide whether to upgrade or patch?

An upgrade is usually the best way to fix a vulnerability. If both an upgrade and a patch are available, Snyk will usually recommend the upgrade.

  • Our GitHub integration will suggest the best fix available. If there is both an upgrade and a patch, the fix pull request will recommend to upgrade.
  • If you’re using Snyk’s CLI for Node.js, Snyk wizard lets you choose to patch, even if an upgrade is available. You might want to patch if an upgrade would be a potentially breaking change (we highlight if this is the case), or if you have other reasons to not upgrade for now.

If you’re unsure and would like to assess the impact before applying a fix, check Snyk’s advisory for the vulnerability.

What if there is no upgrade or patch available?

Assess the issue, and weigh up risk against effort. If the risk is high, you could remove the dependency. Both Snyk CLI and the GitHub integration allow you to ignore the vulnerability for 30 days.

How can I ignore a vulnerability?

We normally recommend that you don’t ignore vulnerabilities unless there are no fixes available. However if you don’t want to fix a vulnerability, and would like to ignore it, there are a few ways you can do this.

For npm projects you can use snyk wizard to ignore the vulnerability for 30 days, adding a reason why. Note that for npm projects, Snyk does not test devDependencies by default.

For all projects (including Ruby projects), you can ignore the vulnerability by creating a .snyk YAML file in the root of your project with the following format:

version: v1.5.0
ignore:
  '{SNYK ID}':
    - '* > {AFFECTED MODULE}':
        reason: '{Optional, the reason why you are ignoring the vulnerability}'
        expires: '{valid ISO 8601 date}'

For example, if you wanted to ignore the vulnerability with SNYK ID SNYK-RUBY-FASTREADER-20085 in fastreader, with the reason “No remediation available” until 01 Jan 2017, you would write:

version: v1.5.0
ignore:
  'SNYK-RUBY-FASTREADER-20085':
    - '* > fastreader':
        reason: 'No remediation available'
        expires: '2017-01-01T00:00:00.000Z'

Using Snyk

Why should I add Snyk Test to my Continuous Integration (CI)?

Integrating Snyk will prevent code changes from introducing new vulnerable packages. Find out how to integrate Snyk into your workflow.

How can I use Snyk behind a proxy?

To run Snyk from behind a proxy you will need to use an enviroment value to point to your proxy. The following environment variables are respected by Snyk:

  • HTTP_PROXY / http_proxy
  • HTTPS_PROXY / https_proxy
  • NO_PROXY / no_proxy

For example, to configure this as a one time value, you can run:

$ https_proxy=https://my.corporate.proxy:8080/ snyk test

Why does Snyk install itself into my production dependencies?

After running snyk wizard with Snyk’s CLI, if you choose to protect upon installation of your package, Snyk will need to be bundled as a production dependency.

However, if you select to only test your page (and not protect), Snyk will install itself as a development dependency.

How can I test a Github repository from the command-line interface tool (CLI)?

Currently, our CLI supports testing public Node.js Github repositories only. To test a public Github repository, run snyk test and include the Github URL to the repo.

snyk test https://github.com/snyk/snyk

The following git URL formats are supported:

  • git://github.com/user/project.git#commit-ish
  • https://github.com/user/project#commit-ish
  • user/project#commit-ish

This also works for Bitbucket and GitLab. You can also test a public npm package, or public Node.js or Ruby Github project via the Test page on snyk.io.

How can I delete my data?

You can delete a project on the project page on the Snyk website. This will delete the project, and all snapshots that are related to it, and you won’t be able to access it. Please note that the data remains in our database, so if you would like to restore it, let us know. If you would like us to delete your project data permanently from the database, email us and we’ll sort it out.

How can I delete my account?

Until we support deleting your account via the Snyk website, this is a manual process. Email us, and we will remove your account and all your data from our database.

What analytics do you track? How can I opt out?

We are using a range of web analytics tools to understand and analyse user behaviour on snyk.io. If you’d like to block tracking, use one of the many browser tools available.

Our CLI tool reports an event for each command to our analytics, including the version of the CLI tool, the User ID, and the package name. This allows us to better understand how the CLI client is used, and informs our product development decisions.

If you would like to opt out, you can do so by running the following command:

snyk config set disable-analytics=1

To remove the flag, run:

snyk config unset disable-analytics

If you have any questions or problems, please email us.