npm is a great tool for building and distributing Node.js packages. It’s also a handy way to make sure that people who use your app are getting all the Node.js dependencies that the app requires to run.
But getting software to your users is only half the battle. You also need to make sure your software is secure. You don’t want to lose users because they discover security vulnerabilities in the Node.js pipeline that you use to deliver your app.
npm and security challenges
If you’ve followed Node.js news recently, you’ll know that npm dependencies and security is a touchy subject. That’s due especially to the fiasco earlier in the spring involving the removal of a certain dependency from npm, which broke a large number of very popular packages that depended on it.
That episode didn’t involve malicious hackers, just a frustrated developer who decided to remove his code from npm. But the impact on users was similar to what you’d expect following a major DDoS attack. Lots of apps that people used every day stopped working.
The episode highlighted how vulnerable npm makes developers who rely on third-party dependencies and hope that the people maintaining those dependencies are, well, dependable. This isn’t a security flaw in npm per se, but it’s a fundamental security challenge associated with the design of npm.
I’m not trying to knock npm, by the way. The issue described above is an inevitable result of the flexible, community-oriented nature of npm itself. When you empower developers to collaborate on a massive scale in the way the Node.js community does, you also raise the risk that a few bad kinks within the community fabric could have negative repercussions for lots of people.
I should also note that npm fixed the issue involving the missing dependency remarkably quickly, and has taken steps to prevent the recurrence of an event like this.
Using Snyk to secure your pipeline
Yet, the problem remains that the npm dependency architecture can expose your users to security problems, even if your app itself is secure.
Snyk is pretty simple and flexible to use. It can scan for vulnerabilities by parsing either GitHub repositories or individual packages, and it provides its own CLI environment for finding vulnerabilities.
But that’s not all. You can also use Snyk to fix vulnerabilities right from the CLI. When it finds a problem in any dependency within your pipeline, it will either give you an option to fix it automatically with a patch, or tell you that there is no known fix yet.
No, Snyk doesn’t work magic. It only finds and fixes known vulnerabilities. It doesn’t try to discover previously undocumented flaws within your code itself. But no real repository security scanner goes that far.
Perhaps the only real shortcoming in Snyk is that its name is hard to remember how to spell correctly. (But I’m nitpicking here.)
Fitting Snyk into your Codefresh pipeline
If you’re developing a Node.js app, now you can use Codefresh to embed Snyk as part of your automated pipeline.
Codefresh enables you to easily customize your build, test deploy pipeline with a YAML file. You could configure your pipeline to execute a series of steps (clone git repo, build a Docker Image, perform unit & integration test, and deploy image to production) on every commit, and run each step as a stand alone image or as part of a composition. To check your code for vulnerabilities, you can add a custom step in the Codefresh YAML file.
Using Codefresh YAML and Snyk CLI you can create the freestyle step in codefresh.yml to see which vulnerabilities in your dependencies should be fixed in your Nodejs pipeline.
Here’s an example Snyk freestyle step:
- npm install
- npm install -g snyk
- snyk auth $SNYK_TOKEN
- snyk test
Simply login to your Snyk account, under My account you’ll find Your API token in the General tab. Copy that token into your codefersh.yml and you’re done.
Here’s a working Nodejs Example with Snyk test.
The image below shows how the Snyk test results would appear in Codefresh