snyk - npm Package Compare versions
Comparing version 0.1.0 to 0.1.1
@@ -20,6 +20,6 @@ var snyk = require('../../'); | ||
| var msg = 'Tested '; | ||
| if (res.hasOwnProperty('dependency_count')) { | ||
| msg += res['dependency_count'] + ' dependencies'; | ||
| if (res.hasOwnProperty('dependencyCount')) { | ||
| msg += res['dependencyCount'] + ' dependencies'; | ||
| } else { | ||
| msg += 'the latest version of ' + path; | ||
| msg += path; | ||
| } | ||
@@ -33,3 +33,8 @@ msg += ' for known vulnerabilities'; | ||
| msg = msg + ', found ' + res.vulnerabilities.length + ' vulnerabilities.\n' | ||
| msg = msg + ', found ' + res.vulnerabilities.length; | ||
| if (res.vulnerabilities.length == 1) { | ||
| msg += ' vulnerability.\n' | ||
| } else { | ||
| msg += ' vulnerabilities.\n' | ||
| } | ||
@@ -36,0 +41,0 @@ throw new Error(msg + res.vulnerabilities.map(function (vuln) { |
@@ -58,3 +58,3 @@ { | ||
| }, | ||
| "version": "0.1.0" | ||
| "version": "0.1.1" | ||
| } |
| # Snyk - So Now You Know! | ||
| Note: Snyk is currently only available for private beta testing. | ||
| If you're not a part of the private beta and want to be, please [email us](mailto:contact@snyk.io). | ||
| Note: Snyk is currently only available for private beta testing. [Email us](mailto:contact@snyk.io) if you want to join the beta. | ||
| Snyk will help you reduce the security risk introduced by the use of third party dependencies. | ||
| It informs you of known vulnerabilities in the packages used in your projects, helps you fix those issues, and alerts you when new vulnerabilities are disclosed. | ||
| ## Installation & Getting Started | ||
| Snyk is easy to integrate into your Continuous Integration system, where you can patch individually chosen vulnerabilities and warn or err on new ones. If you own an open source project and have a vulnerable downstream dependency, snyk can ensure the vulnerability is patched as part of your app/package installation process. | ||
| Snyk helps you find and fix known vulnerabilities in your Node.js dependencies, both ad hoc and as part of your CI (Build) system. | ||
| Snyk is currently only available for Node.js projects. More language will be supported in the future. | ||
| ## Getting Started | ||
| To get up and running quickly, run these commands (requires having [npm installed](http://blog.npmjs.org/post/85484771375/how-to-install-npm)): | ||
| To get up and running quickly, run these commands to install, authenticate and perform a quick test. Note that while we authenticate using GitHub, we *do not* require access to your repositories (only your email): | ||
| ```shell | ||
@@ -21,17 +16,17 @@ npm install -g snyk | ||
| You now have a working installation of Snyk, and can see the results of testing an older version of a public package and seeing the known vulnerabilities it contained. In your dev process you'll likely be running this test on your own code instead, which is what we'll explain in the next steps. | ||
| You can now see an example of several known vulnerabilities found on an older version of `ionic`, as well as guidance on how to understand and address them. In the next sections we'll explain how to run the same test on your own projects. | ||
| ## test | ||
| Use `snyk test` to find known vulnerabilities in your projects. To get started, browse to a project you'd like to test, and run `snyk test` | ||
| To test your own project for known vulnerabilities, browse to your project's folder and run `snyk test`, like so (swapping the folder with your project's folder): | ||
| ```shell | ||
| cd ~/node/project/to/test/ | ||
| cd ~/projects/myproj/ | ||
| snyk test | ||
| ``` | ||
| `snyk test` will take stock of all the local dependencies and their installed versions, and report them to Snyk. The Snyk servers will check will check if there are known vulnerabilities on these dependencies, and if so report about them and and suggest any remediation you can take. Since `snyk test` looks at the locally installed modules, it needs to run after `npm install`, and will seamlessly work with `shrinkwrap`, npm enterprise or any other custom installation logic you have. | ||
| `snyk test` will take stock of all the local dependencies and their installed versions, and report them to Snyk. The Snyk servers will check if there are known vulnerabilities on these dependencies, and if so report about them and and suggest any remediation you can take. Since `snyk test` looks at the locally installed modules, it needs to run after `npm install`, and will seamlessly work with `shrinkwrap`, npm enterprise or any other custom installation logic you have. | ||
| `snyk test` can also get a folder name as an argument. If you're using Snyk for the first time, you may want to go to a parent project folder and run `snyk test` on all its subdirectories. Here's a handy command to do so: | ||
| `snyk test` can also get a folder name as an argument, which is especially handy if you want to test multiple projects. For instance, the following command tests all the projects under a certain folder for known vulnerabilities: | ||
| ```shell | ||
| cd ~/my/parent/projects/folder/ | ||
| cd ~/projects/ | ||
| find . -type d -maxdepth 1 | xargs -t -I{} snyk test {} | ||
@@ -42,3 +37,2 @@ ``` | ||
| ```shell | ||
| # example uses | ||
| snyk test lodash | ||
@@ -48,9 +42,8 @@ snyk test ionic@1.6.5 | ||
| If `snyk test` found vulnerabilities, the process with exit with a non-zero exit code, making it easy to integrate it into your CI, more on that below. Note that `snyk test` can ignore vulnerabilities specified in the .snyk file, as explained in the `protect` section. | ||
| If you ran snyk locally and found vulnerabilities, you should proceed to use `snyk protect` to address them. | ||
| ## protect | ||
| Snyk's `protect` functionality allows you to patch vulnerabilities that can't be remediated through an upgrade (*note that patch is not yet available in this stage of the private beta, but coming soon*). | ||
| To get started, run protect in interactive mode: | ||
| Snyk's `protect` helps you address the known vulnerabilities `snyk test` found. | ||
| To get started, run `protect` in interactive mode: | ||
| ```shell | ||
@@ -60,9 +53,9 @@ snyk protect -i | ||
| This interactive mode will run a test again, and then guide you through how to address every issue found. Once completed, `snyk protect -i` will create a local `.snyk` file that guides non-interactive executions of `snyk protect`. Note that `snyk protect` will never unilaterally decide to ignore or patch a vulnerability - it will simply follow the guidance captured in the `.snyk` file. | ||
| Protect's interactive mode will run `test` again, and ask you what to do for each found issue. Here are the possible remediation steps for each vulnerability: | ||
| Here are the possible remediation steps for each vulnerability: | ||
| - `Upgrade` - if upgrading a direct dependency can fix the current vulnerability, `snyk protect` can automatically modify your Package.json file to use the newer version. Note that you'll still need to run `npm update` afterwards to get the new packages. | ||
| - `Ignore` - If you believe this vulnerability does not apply to you, or if the dependent module in question never runs on a production system, you can choose to ignore the vulnerability. By default, we will ignore the vulnerability for 30 days, to avoid easily hiding a true issue. If you want to ignore it permanently, you can manually edit the generated `.snyk` file. | ||
| - `Patch` - Sometimes there is no direct upgrade that can address the vulnerability, or there is one but you cannot upgrade due to functional reasons (e.g. it's a major breaking change). For such cases, `snyk protect` lets you patch the issue with a patch applied locally to the relevant dependency files. We manually create and maintain these patches, and may not have one for every issue. If you cannot upgrade, patch is often a better option than doing nothing *Note: patch is not yet enabled in the private beta, it will be soon. In the meantime, patch will be replaced with a short ignore*. | ||
| - `Upgrade` - if upgrading a direct dependency can fix the current vulnerability, `snyk protect` can automatically modify your Package.json file to use the newer version. | ||
| - `Ignore` - If you believe this vulnerability does not apply to you, or if the dependent module in question never runs on a production system, you can choose to ignore the vulnerability. By default, we will ignore the vulnerability for 30 days, to avoid easily hiding a true issue. If you want to ignore it permanently, you can edit the generated `.snyk` file. | ||
| - `Patch` - We maintain a growing database of patches that can fix a vulnerability by locally modifying the releant dependency files. If there's no available upgrade, or if you cannot upgrade due to functional reasons (e.g. it's a major breaking change), you should patch. If you patched at least one known vulnerability, `snyk protect --interactive` will also add `snyk protect` (no parameters) to your Package.json post-install step. *Note: patch is not yet enabled in the private beta, it will be soon. In the meantime, patch will be replaced with a short ignore*. | ||
| Once completed, `snyk protect -i` will create a local `.snyk` file that guides non-interactive executions of `snyk protect`. Note that `snyk protect` will never unilaterally decide to ignore or patch a vulnerability - it will simply follow the guidance captured in the `.snyk` file. | ||
@@ -76,3 +69,3 @@ ## Integrating Snyk into your dev workflow | ||
| 3. After the `npm install` steps in your CI, run `snyk protect` to apply any necessary patches | ||
| 4. Run `snyk test` to identify (and err) on any known vulnerabilities not already ignored or patched. | ||
| 4. Run `snyk test` to identify on any known vulnerabilities not already ignored or patched. If such vulnerabilities were found, `snyk test` will return a non-zero value to fail the test. | ||
@@ -88,9 +81,9 @@ A few potential alternatives to consider: | ||
| With `test` and `protect`, you should be well setup to address currently known vulnerabilities. However, new vulnerabilities are constantly disclosed, which is where `monitor` comes in. | ||
| With `test` and `protect`, you're well setup to address currently known vulnerabilities. However, new vulnerabilities are constantly disclosed - which is where `monitor` comes in. | ||
| Just before you deploy, run `snyk monitor` in your project directory. This will post a snapshot of your full dependency tree to Snyk's servers, where they will be stored. Those dependencies will be tracked for newly discolsed vulnerabilities, and we will alert you if a new vulnerability related to those dependencies is disclosed. | ||
| Just before you deploy, run `snyk monitor` in your project directory. This will post a snapshot of your full dependency tree to Snyk's servers, where they will be stored. Those dependencies will be tracked for newly disclosed vulnerabilities, and we will alert you if a new vulnerability related to those dependencies is disclosed. | ||
| ```shell | ||
| # example uses | ||
| cd ~/node/project/to/test/ | ||
| cd ~/projects/myproject/ | ||
| snyk monitor | ||
@@ -106,6 +99,43 @@ # a snyk.io monitor response URL is returned | ||
| If you are authenticating on a remote machine (that doesn't have access to open a browser to GitHub) you can use your API key from https://snyk.io and authenticate directly on the command line using `snyk auth <key>`. | ||
| If you are authenticating on a remote machine, for instance on a build server, you can use your API key from https://snyk.io and authenticate directly on the command line using `snyk auth <key>`. Browse to the [Snyk app](https://app.snyk.io/) to find out your own API key. | ||
| ## Sample Commands | ||
| For easy reference, here is a list of the examples previously mentioned. | ||
| Get Started | ||
| ```shell | ||
| npm install -g snyk | ||
| snyk auth | ||
| snyk test ionic@1.6.5 | ||
| ``` | ||
| Test a single local project | ||
| ```shell | ||
| cd ~/projects/myproj/ | ||
| snyk test | ||
| ``` | ||
| Test all projects under a parent folder | ||
| ```shell | ||
| cd ~/projects/ | ||
| find . -type d -maxdepth 1 | xargs -t -I{} snyk test {} | ||
| ``` | ||
| Test a public package | ||
| ```shell | ||
| snyk test lodash | ||
| snyk test ionic@1.6.5 | ||
| ``` | ||
| Interactive `snyk protect` to address found issues | ||
| ```shell | ||
| snyk protect -i | ||
| ``` | ||
| Store a snapshot of current dependencies to monitor for new ones | ||
| ```shell | ||
| # example uses | ||
| cd ~/projects/myproject/ | ||
| snyk monitor | ||
| # a snyk.io monitor response URL is returned | ||
| ``` | ||
| ## Credits | ||
| While we use multiple sources to determine vulnerabilities, the primary (current) source is the [Node Security project](http://nodesecurity.io). |
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by0.23%
67878
- Lines of code
- increased by0.31%
1643
- Number of lines in readme file
- increased by28.57%
135
No dependency changes