Are your node modules secure?
Most of the time it’s not a problem to rely on an older version of a package. If your package works fine with an outdated dependency, there’s no compelling reason to upgrade. Why fix something that isn’t broken? Unfortunately, it’s not so easy to tell if it is. Your package may have been broken without your knowledge. The problem is in the definition of “broken”. You could consider it to mean your application doesn’t work in some way, but what about the non-functionals? Did you consider the fact that you may be relying on packages that introduce security vulnerabilities into your system?
> snyk test azure
âœ— Vulnerability found on firstname.lastname@example.org
From: email@example.com > firstname.lastname@example.org > email@example.com > validator@~3.1.0
No direct dependency upgrade can address this issue.
Run `snyk protect -i` to patch this vulnerability
Alternatively, manually upgrade deep dependency validator@~3.1.0 to firstname.lastname@example.org
Tested azure for known vulnerabilities, found 32 vulnerabilities.
It turns out the Node.js library for Azure isn’t quite secure. Snyk can automatically patch the vulnerability for you, but the real solution is to update the azure-common package to use the newer version of validator. As you see, most of the security issues reported by Snyk have already been fixed by the authors of the affected library. That’s the real reason to keep your dependencies up to date.
I think of Snyk as just another type of code quality check. Just like your unit tests, your build should fail if you’ve accidently added an insecure dependency. A really simple way to enforce it is to use a pre-commit hook in your package.json:
"lint": "eslint src test",
"snyk": "snyk test",
"test": "mocha test/spec",
"pre-commit": ["lint", "test", "snyk"]
The pre-commit hook will automatically be executed when you try to commit to your Git repository. It will run the specified npm scripts and if any of them fail, abort the commit. It must be noted that, by default, Snyk will only test your production dependencies. If you want it to also test your devDependencies you can run it with the `–dev` flag.