Skip to content

Commit

Permalink
feat: release of snyk cli & module to open source
Browse files Browse the repository at this point in the history
馃帀馃拑
  • Loading branch information
remy committed Oct 30, 2015
0 parents commit 1de84e8
Show file tree
Hide file tree
Showing 3,406 changed files with 433,625 additions and 0 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
3 changes: 3 additions & 0 deletions .gitignore
@@ -0,0 +1,3 @@
config.local.json
/node_modules/
/patches/
13 changes: 13 additions & 0 deletions .jscsrc
@@ -0,0 +1,13 @@
{
"preset": "node-style-guide",
"requireCapitalizedComments": null,
"requireSpacesInAnonymousFunctionExpression": {
"beforeOpeningCurlyBrace": true,
"beforeOpeningRoundBrace": true
},
"disallowSpacesInNamedFunctionExpression": {
"beforeOpeningRoundBrace": true
},
"excludeFiles": ["node_modules/**"],
"disallowSpacesInFunction": null
}
16 changes: 16 additions & 0 deletions .jshintrc
@@ -0,0 +1,16 @@
{
"browser": false,
"camelcase": true,
"curly": true,
"devel": true,
"eqeqeq": true,
"forin": true,
"indent": 2,
"noarg": true,
"node": true,
"quotmark": "single",
"undef": true,
"strict": false,
"unused": true
}

5 changes: 5 additions & 0 deletions .npmignore
@@ -0,0 +1,5 @@
/node_modules
.git*
/test
config.*.json
!config.default.json
30 changes: 30 additions & 0 deletions .travis.yml
@@ -0,0 +1,30 @@
sudo: false
language: node_js
cache:
directories:
- node_modules
notifications:
email: false
services:
- mongodb
addons:
postgresql: "9.4"
node_js:
- '4'
- '0.12'
- '0.10'
before_install:
- npm i -g npm@^2.0.0
- echo "//registry.npmjs.org/:_authToken=\${NPM_TOKEN}" > .npmrc
before_script:
- npm prune
- psql -c 'create database test;' -U postgres
- psql -U postgres -c "create extension hstore" test
- 'curl -Lo travis_after_all.py https://git.io/vLSON'
after_success:
- python travis_after_all.py
- export $(cat .to_export_back)
- npm run semantic-release
branches:
except:
- "/^v\\d+\\.\\d+\\.\\d+$/"
13 changes: 13 additions & 0 deletions LICENSE
@@ -0,0 +1,13 @@
Copyright 2015 Snyk Ltd.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
136 changes: 136 additions & 0 deletions README.md
@@ -0,0 +1,136 @@
# Snyk - So Now You Know!

Note: Snyk is currently only available for private beta testing. [Email us](mailto:contact@snyk.io) if you want to join the beta.

## Installation & Getting Started

Snyk helps you find and fix known vulnerabilities in your Node.js dependencies, both ad hoc and as part of your CI (Build) system.

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
# If you're using node 0.10, first install npm 2 to support scoped modules, like so:
# npm install -g npm@2
npm install -g snyk
snyk auth
snyk test ionic@1.6.5
```

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

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 ~/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 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, 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 ~/projects/
find . -type d -maxdepth 1 | xargs -t -I{} snyk test {}
```

Lastly, you can also use `snyk test` to scrutinize a public package before installing it, to see if it has known vulnerabilities or not. Using the package name will test the latest version of that package, and you can also provide a specific version or range using `snyk test module[@semver-range]`.
```shell
snyk test lodash
snyk test ionic@1.6.5
```

If you ran snyk locally and found vulnerabilities, you should proceed to use `snyk protect` to address them.

## protect

Snyk's `protect` helps you address the known vulnerabilities `snyk test` found.
To get started, run `protect` in interactive mode:
```shell
snyk protect -i
```

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:

- `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*.

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.

## Integrating Snyk into your dev workflow

To continuously test against and protect from known vulnerabilities, integrate Snyk into your continuous integration (a.k.a. build) system. Here are the steps required to to so:

1. Add `snyk` to your project's dependencies (`npm install -S snyk`), and commit the change in
2. Ensure the `.snyk` file you generated was added to your source control (`git add .snyk`);
3. After the `npm install` steps in your CI, run `snyk protect` to apply any necessary patches
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.

A few potential alternatives to consider:
- Add `snyk test` to your Package.json `test` scripts, to capture them in local `npm test` runs.
- Add `snyk test` as a `post-install` step in your Package.json file, to immediately spot any newly added module which has known vulnerabilities
- Add `snyk protect` as a `post-install` step in your Package.json file, to apply patches even while working locally

Note: During private beta, all snyk actions require authentication. This means modifying your Package.json will require your entire team to first run `snyk auth`. If you don't want that, hold off on modifying your Package.json file for now.

## monitor

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 disclosed vulnerabilities, and we will alert you if a new vulnerability related to those dependencies is disclosed.

```shell
# example uses
cd ~/projects/myproject/
snyk monitor
# a snyk.io monitor response URL is returned
```

## More About Authentication

During the private beta, you will need to authenticate with snyk before being able to use any of it's features. Once public, `test` and `protect` will be available without the need to `auth`.

Authentication requires you to have a GitHub account, but *does not require access to your repositories* - we simply use Github to spare you managing another set of credentials. Run `snyk auth` and follow the on screen instructions.

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).
98 changes: 98 additions & 0 deletions cli/args.js
@@ -0,0 +1,98 @@
module.exports = args;

var abbrev = require('abbrev');
var alias = abbrev('version', 'debug', 'help', 'quiet', 'interactive', 'dev');
alias.d = 'debug'; // always make `-d` debug

function args(processargv) {
// allows us to support flags with true or false only
var argv = processargv.slice(2).reduce(function reduce(acc, arg) {
if (arg.indexOf('-') === 0) {
arg = arg.slice(1);

if (alias[arg] !== undefined) {
acc[alias[arg]] = true;
} else if (arg.indexOf('-') === 0) {
acc[arg.slice(1)] = true;
} else {
acc[arg] = true;
}
} else {
acc._.push(arg);
}

return acc;
}, { _: [] });

// by passing `-d` to the cli, we enable the debugging output, but this must
// be as early as possible in the cli logic to capture all the output
if (argv.debug) {
require('debug').enable('snyk');
}

var debug = require('debug')('snyk');

// this is done after the debug activation line above because we want to see
// the debug messaging when we use the `-d` flag
var cli = require('./commands');

// the first argument is the command we'll execute, everything else will be
// an argument to our command, like `snyk help protect`
var command = argv._.shift();

// alias switcheroo - allows us to have
if (cli.aliases[command]) {
command = cli.aliases[command];
}

// alias `-v` to `snyk version`
if (argv.version) {
command = 'version';
}

if (!command || argv.help || command === 'help') {
// bit of a song and dance to support `snyk -h` and `snyk help`
if (argv.help === true || command === 'help') {
argv.help = 'help';
}
command = 'help';

if (!argv._.length) {
argv._.unshift(argv.help || 'usage');
}
}

if (command && command.indexOf('config:') === 0) {
// config looks like `config:set x=y` or `config:get x`
// so we need to mangle the commands into this format:
// snyk.config('set', 'api=x')
// snyk.config('get', 'api') // etc
var tmp = command.split(':');
command = tmp.shift();
argv._.unshift(tmp.shift());
}

var method = cli[command];

if (!method) {
// if we failed to find a command, then default to an error
if (!method) {
method = require('./error');
argv._.push(command);
}
}

if (command === 'protect' ||
command === 'test') {
// copy all the options across to argv._ as an object
argv._.push(argv);
}

debug(command, argv);

return {
method: method,
command: command,
options: argv,
};
}

0 comments on commit 1de84e8

Please sign in to comment.