On January 8, 2022, the open source maintainer of the wildly popular npm package colors, published colors@1.4.1 and colors@1.4.44-liberty-2 in which they intentionally introduced an offending commit that adds an infinite loop to the source code. The infinite loop is triggered and executed immediately upon initialization of the package’s source code, and would result in a Denial of Service (DoS) to any Node.js server using it.
As developers, we spend a lot of time in our IDEs writing new code, refactoring code, adding tests, fixing bugs and more. And in recent years, IDEs have become powerful tools, helping us developers with anything from interacting with HTTP requests to generally boosting our productivity. So you have to ask — what if we could also prevent security issues in our code before we ship it?
If you’re doing open source development today, chances are high that you’re active within the GitHub community — participating in open source projects and their repositories. A recent addition to the GitHub ecosystem is GitHub Packages, which was announced back in 2019 and is now receiving even more updates with the general availability of the GitHub Packages container registry.
As announced last week by our good friends at the Node.js Foundation, Snyk has agreed to take over from the amazing Node.js ecosystem vulnerability disclosure program. As a company that’s been part of this program from a very early stage — and has been inspired by it to create our own multi-ecosystem disclosure program — it is a great honor to have been entrusted with this responsibility, and we thank the Node.js Foundation sincerely for their trust in this matter.
Open source helps developers build faster. But who’s making sure these open source dependencies (sometimes years out of development) stay secure? In a recent npm security research activity, Snyk uncovered a total of 8 npm packages which matched a specific malicious code vector of attack. This specific attack vector of the malicious packages included packages which had pre/post install scripts, which allowed them to run arbitrary commands when installed.
Writing secure code in a way that prevents code injection might seem like an ordinary task, but there are many pitfalls along the way. For example, the fact that you (a developer) follow best security practices doesn’t mean that others are doing the same. You’re likely using open source packages in your application. How do you know if those were developed securely? What if insecure code like eval() exists there? Let’s dive into it.
Docker is totalling up to over 50 billion downloads of container images. With millions of applications available on Docker Hub, container-based applications are popular and make an easy way to consume and publish applications. That being said, the naive way of building your own Docker Node.js web applications may come with many security risks. So, how do we make security an essential part of Docker for Node.js developers?
Async hooks are one of those Node.js features that seem interesting when you first see them, but in practice they end up failing to provide overtly obvious use cases. At their core, async hooks are a way to step into the lifecycle of any asynchronous resource. This may be a promise, a timeout, streams, DNS lookups, and even HTTP requests—like API calls. Most examples are focused on tracking the execution context or enhancing asynchronous stack traces.
