Services
Over the past few weeks we’ve been talking a lot internally at Jemurai about how package managers and the code repositories we use (often what people think of as open source) affect our security.
Anyone that has written code has done a:
gem install
npm install
pip install
gradle install
mvn install
go get
nuget install
cargo build
etc.This post provides a brief introduction to the topic and then presents an open OWASP documentation project we started called packman that I’m organizing with invested security and developer folks to improve the state of these package management and source repositories.
The thing that got me thinking about it again (you can see related past posts in the references) was when a journalist asked me about the bootstrap_sass issue that had just been posted by Snyk on their blog. Basically, it looked like the maintainer’s password might have been guessed and a malicious version of bootstrap_sass was uploaded by a bad actor. The details are interesting, I recommend checking out the blog post for the full details. The goal here is not at all to capture or retread that specific issue.
The next thing that triggered my interest was when I was working on a Go program that looked something like this:
import (
"fmt"
"log"
uuid "github.com/satori/go.uuid"
"github.com/spf13/cobra"
"github.com/spf13/viper"
...
)How do I know anything about the integrity of the code sitting in those libraries? Is Go just pulling those straight from GitHub? What if the latest version changes in an unexpected way and I pull in crazy code?
That got me thinking, this problem isn’t isolated to any particular language. While some systems seem to be more tightly controlled than others, there are issues across the board.
NPM is often maligned because it has had issues. The NodeJS ecosystem is rapidly growing and there are huge numbers of nested dependencies in most projects. We have a project that looks like this:
npm audit
...
found 2 moderate severity vulnerabilities in 4196 scanned packages
2 vulnerabilities require manual review. See the full report for details.I mean, 4000+ packages? Are you for real? But the npm tool gives me an easy way to at least identify known issues in my supply chain. Ruby has bundler-audit, python has security-check but Java and .Net tend to be serviced by OWASP or commercial tools that are outside the main toolchain. I don’t see anything comparable in Go at all.
I’ve worked with firms that audit all of their open source and keep a private repository of that which has been audited. That helps a lot in terms of keeping the supply clean. However, most companies we work with don’t have the expertise or bandwidth to keep their own clean copies.
This is just one issue. Most tools support some sort of MFA (multifactor authentication), but none require it and in many cases things get complicated when we want to both use MFA and have automated builds. Why do we care about MFA? Well, if I can find a list of contributors by spidering a website then guess a lot of passwords for everyone on that list, I have a decent chance of finding a library that I can backdoor.
As a developer interested in security, I care about code signing, whether tools run code on my machine, whether there are any rules around passing the baton between maintainers, is there any analysis that happens by the repository owners themselves?
With packman, we’re trying to enumerate the different issues that exist and then prioritize them so that we know which ones matter the most. It may be that a stronger standard comes out of this. For now we’re still trying to make it a consistent and consenus based guideline.
Then, we want to build a page for each major package manager and engage with the security and developer constituencies in that language community to explain what we see and work with them to improve it.
Although not all of our open source work has been with OWASP, this seemed like a perfect project to undertake as part of that community to get broader inputs and work to build what is a recognized standard of excellence for security with package managers.
There are a number of commercial and open solutions in this area. They do things like:
We certainly recommend using these tools as they apply to your projects.
To our knowledge, none of these tools can reliably keep the main package repository safer and so we think the packman project is important even if you are using dependency management or software composition analysis types of tools.
Something I would really like to see is the idea that package management systems support tagging of modules in different contexts. For example, imagine if:
In this way, we could support curated sources for libraries without forcing the whole system to be tightly curated.
We invite you to check out packman, create some issues, ask some questions, and get involved. It’s not a super technical project. Most of what we need to do is work together to distill the important parts of the checklists and then communicate with the teams that are working on the package managers themselves.
That being said, I think it is an important project with the potential to make a huge impact for developers by making it easier to use libraries safely.
Past blog posts:
