The point of no return for software dependencies

Image from “Open Source Supply, Demand, and Security”, by sonatype

Introduction

Software supply chain security is a hot topic in the open source ecosystem, as more and more projects depend on external libraries, packages, and microservices that may pose security risks or contain malicious code. In a recent blog post by our CTO Paolo Mainardi, he explores some of the software supply chain security issues in JavaScript, Python, and microservices-based projects and provides some best practices and solutions to improve the security and trustworthiness of the software products. In this post, I will summarize the main findings and takeaways of the original post, and provide some additional insights and comments.

Software Supply Chain is a complex problem

One of the most striking findings of the original post is the large number of dependencies and packages that JavaScript projects have, compared to other languages.

Here’s an extract from the post:

To print a Hello World with NextJS, we need to bring 298 dependencies with 5 known vulnerabilities in our application.

…

The large package sizes in NodeJS are primarily due to the relatively small JavaScript standard library and the Unix-inspired philosophy behind NodeJS.

This shows how complex and fragile the JavaScript ecosystem is, and how easy it is to introduce security issues or malicious code in our projects. While JavaScript has many advantages and benefits, such as its popularity, versatility, and performance, it also requires a lot of caution and responsibility from developers and organizations. We need to be more aware of what we are using, why we are using it, and how we can verify its integrity and quality. We also need to adopt tools and practices to help us manage our dependencies, such as package managers, lock files, audits, and updates.

Another interesting finding of the original post is the contrast between the number of dependencies and packages Python projects have and the number of vulnerabilities they expose.

Here’s another extract from the post:

Even with PyTorch and its dependencies, the number of Python packages is relatively small, just 35; what is way bigger now is the number of packages carried back from the Debian base image (required to use PyTorch instead of Alpine), to be more precise 429 packages with an insane number of known vulnerabilities.

This shows how important it is to choose the right OCI container base image for our projects, and how we can reduce our attack surface by using smaller and more secure images, such as Distroless or Chainguard, as Paolo states in his closing thoughts. Python is a powerful and versatile language, especially for AI and data science applications, but it also requires careful attention to the security and quality of the libraries and frameworks that we use.

The final finding of the original post is the complexity and diversity of the software supply chain in microservices-based projects, which involve multiple languages, frameworks, and technologies.

So, have we reached the point of no return?

The answer, according to the original author, is YES.

I will once again quote the original post:

Today creating a new software product should raise some fundamental questions, such as:

• How can we trust that someone different from us can always play as a good actor?
• How can we be sure that all the code we depend on is made exclusively to do what it claims?
• How can we be sure that the software has not been tampered in one of the point of the supply chain?

The original post’s final thoughts and takeaways are that we live in a golden era of this industry, with many opportunities and possibilities but also many challenges and risks. We need to be more conscious and responsible about the software that we create and use, and how it affects our security and trustworthiness. We need to be more selective and vigilant about our dependencies and packages, and how we can verify their integrity and quality. We need to be more consistent and transparent about our software development lifecycle, and how we can automate and standardize our processes. We need to be more aware and proactive about the latest technologies and frameworks that can help us create more secure and reliable software, and Paolo suggests tools such as SLSA, Sigstore, SBOM, Grype, and the already cited Distroless and Chainguard.

Conclusion

To conclude, I thank Paolo Mainardi for his excellent and insightful blog post on the software supply chain security issues in the open source ecosystem. I highly recommend reading his original post, as it is much more complete and full of tests and data that illustrate his points and findings. He also provides a lot of precious information and recommendations on improving our software supply chain security practices and tools.

You can find his original post here: https://www.paolomainardi.com/posts/point-of-no-return-on-managing-software-dependencies/.

I hope you found this blog post helpful and interesting, and that it inspired you to think more about the software supply chain security issues in the open source ecosystem.

Note: we included our CTO Paolo Mainardi as a co-author of this post, as he wrote the original post on his personal blog and provided a review of this post.