Software Supply Chain is a complex problem
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.
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.
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.