In November of last year, — a security company that finds, fixes and monitors known vulnerabilities in Node.js and Ruby on Rails applications — joined the Node.js Foundation. Snyk We recently sat down with co-founder and CEO of Snyk, Guy Podjarny, to talk to him a bit more about Snyk, creating better security for the larger Node.js package ecosystem, and why Snyk joined the Node.js Foundation. Q: Snyk is a fairly new company, tell us a little bit more about the company’s background? A: Snyk adds a layer of security to open source code, notably npm. We let you easily find and fix known vulnerabilities in your dependencies, and integrate seamlessly into your continuous workflow to prevent adding new vulnerable packages. Lastly, we track your dependencies and alert you when new vulnerabilities are found in them, helping you respond faster than attackers would. Snyk was built on the belief that security must be built into your development process. Security must become a natural part of the dev process, and that with the right tools this aspiration can become reality. Our team combines dev tooling and UX expertise with deep cyber security knowledge, and we’re committed to building friendly and powerful tools, used by developers daily to stay secure without slowing down. Last but not least, we believe in inclusive security. We do our best to be builders and offer constructive advice instead of fear mongering, bringing much of the DevOps culture into security. Q: Why is security in the package ecosystem so important? A: The transformation npm and other package managers are bringing to the world of development is both amazing and complicated. On one hand, the power of crowd-sourced open source packages is a game changer. We believe it will disrupt the development world just like Wikipedia, eBay and Airbnb disrupted their respective industry. Even the richest SDK and broadest built-in library pales in comparison to a tiny package management ecosystem, and nothing compares to the productivity boost you get from building on the power of the entire web. On the other hand, would you bet your company on every Wikipedia article being entirely accurate and every single author a good Samaritan? Unfortunately, the current use of npm (and other open source package platforms) is doing just that. Organizations, big and small, blindly consume hundreds of packages, pulling them into their code and running them with little or no scrutiny. Doing so implicitly trusts these packages, along with all of their contributors, with the application’s secrets and the customer data it has access to. While most open source contributors are capable and good willed, mistakes do happen and bad actors do exist. Without a way to scrutinize our use of open source packages at scale, accidents can happen. Q: What is your philosophy around approaching security, especially for something as vast at the Node.js package ecosystem? We believe automated & developer-friendly security tools, operated by the dev and ops teams, are the only way to keep Node.js applications secure. This perspective combines two core beliefs: First and foremost, we believe security is everyone’s responsibility. Within a company, expecting a small and outnumbered team to keep up with a fast changing Node.js application simply doesn’t work. As a result, either the dev team needs to be slowed down, or the security team doesn’t keep up; both bad outcomes. We need the application team itself, including dev and ops, to take responsibility for shipping secure applications. Within the Node.js ecosystem, those who need to step up are open source consumers. Unlike commercial software, when using OSS you’re not entitled to anything. You’re getting great value for free, and you need to accept your responsibility in knowing what you’re using and keeping it secure. Since consumers (often businesses) typically have more security expertise in the first place, it’s also their responsibility to contribute security insights and findings back to the open source authors and the broader community. Good security requires good developer tools. Security is a vast and complex topic. While we must all do our share, we can’t expect every developer to become a security expert. When we don’t have expertise, we revert to tools that can help give us the knowledge we need at the right time. To get security spread throughout the developer and Node.js ecosystem, we need easy-to-use tools that can surface security concerns and guide non-experts to remediate them. These tools should be built for and primarily used by developers, not security professionals, requiring them to be attuned to how developers work. Q: Do you have any best practices or suggestions for how module developer can create safer packages? It may sound obvious, but the first step is to care about security. Many package developers focus on the functionality they make available, and don’t stop to consider the security implications of different decisions they make. Caring about security is hard, because you don’t have anything to show for it once done, but it’s important nonetheless. When you care, the second step is to document your security considerations and decisions. Create a Security.md in your repo, listing the security questions you considered and how you have (or haven’t) addressed them. These lists are a great way to organize your thoughts and next steps, and they help contributors participate in adding or answering questions. They also help educate consumers as to the security aspects of your package. Last but not least, use the security tools that apply to you. Q: How do you think we create more security in the Node.js package module community? I believe there are three things we can do: . Security is naturally invisible, and it’s easy to simply not think about it, until something blows up in a big way. We need to make sure security concerns and best practices are a natural and recurring part of every Node.js event, blog and other educational events. Discuss security more . If security isn’t easy to do, it won’t get done. I’m a huge believer in ensuring security tools are easy to find and use, and we put a lot of emphasis on user experience and ease of use at Snyk. Better tooling . You typically hear about security failures, like breaches and hacks, but good security rarely gets a mention. Whenever possible, we should try to applaud and point out those who do security well. At Snyk we have a GitHub badge showing how many vulnerable dependencies you have. This is a great way to tell the world you care about security and are addressing it, and that they should do so too. Celebrate successes Q: Why did you join the Node.js Foundation? How does that align with Snyk’s objectives/common goal? We joined the Foundation to ensure security stays top of mind, and to help contribute our expertise to keeping Node.js and its community secure. Snyk’s mission is to help developers use open source and stay secure, and this mission cannot succeed without keeping the open source core secure. In addition, we believe the best path to security is to make it the default — make it easier to be secure than to be insecure. We hope to drive and influence decisions that make Node.js secure out of the box, which will have big security implications for the entire ecosystem. Q: What are you most excited about in the coming year? There is a lot to be excited about this year, but at the top of the list is probably serverless (Function-as-a-Service). This novel approach to managing your infrastructure is exciting by itself, and is naturally attuned to how Node.js and npm work, so it’s no surprise Node.js is thriving in this space. Serverless raises very interesting questions and challenges regarding npm package security, and whether they should be monitored in the CI/CD process or by monitoring the platform itself. We’ve recently launched an exciting new product that lets you monitor for vulnerable packages directly on Lambda & Heroku, which I believe has great promise to how we perceive open source packages and we can keep them secure.

Q&A with Snyk on security, npm and the Node.js Foundation

Too Long; Didn't Read

Companies Mentioned

@nodejs

RELATED STORIES