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.

Measuring performance in Node.js applications can sometimes be a challenge. Do to the nature of the event loop and asynchronous code, determining the actual time a piece of code takes to execute requires tools built into the platform. First added in Node.js v8.5, as stableas of v12, the Performance Measurement APIs are stable and allow much more accurate monitoring than earlier implementations.

The concept of instrumentation often refers to tracing where events happen in an application. Many application performance monitoring (APM) tools use it to provide metrics on the inner workings of your application. But sometimes, all you really need are details about API calls.

The ecosystem around making requests in Node.js applications is huge. With countless libraries available, it can be helpful to understand why they exist. This helps to improve your understanding of Node.js as a whole, and makes choosing an HTTP client easier. In the first post in this series, we looked at creating servers using Node's http module. In this post, we will explore making a request using the http.request method and handling the response.