I’ve participated in open source most of my professional life – first, as a consumer (and internal maintainer) at Google where I consumed a variety of open source packages and imported several new packages into the Google mono-repo, then as a producer of open source as one of the founders of the Knative project starting in 2018. In 2019, I left Google to work at VMware, but thanks to the power of open source, many of my colleagues remained the same, even if they didn’t work for the same company. Needless to say, I’m a big believer in the power and benefits of open source, and it’s been a privilege and a pleasure to participate in the Knative community and the CNCF.
Open source has come a long way since I first engaged with it in 2005; today you can find libraries for almost any problem, in almost any language, and available through package managers which make it as easy as pip install or go get or the like. This makes adding dependencies on open source incredibly easy for both commercial developers and other open source developers. It’s easy for a project to pull in 200 or more library dependencies without even trying, as each library builds on the capabilities of dozens of other open source libraries. It’s not an exaggeration to say that none of the software that we interact with on a day to day basis would be possible without this rich ecosystem of sharing.
If you haven’t gotten here completely by accident, you’ll know that this is where things start to take a darker turn. Our software ecosystems depend overwhelmingly on open source, but there’s no contract or agreement between the consumer of an open source library and the authors. In fact, there’s no real guarantee that the authors of a library are still there – for example, gorilla/mux was a popular HTTP framework for Go, but was archived in 2022 due to a lack of active maintainers. Other projects don’t get as clear a sunset – the authors just wander off to newer, more interesting grounds, and don’t respond to issues / bugs / emails about the project. Worse, we’ve seen hostile actors volunteer to take over maintainership of these projects with a medium-term goal of using their position in the software supply chain to compromise downstream projects with cryptominers or other malware. For the average developer, it’s an enormous chore to assess whether a given open source library is being well-maintained, and it’s almost certain that they won’t go back later to check that this is still true.
One common solution to discovering vulnerable open source libraries that need attention are the Common Vulnerability Exchange (CVE) databases – https://cve.mitre.org/ and https://nvd.nist.gov/. While the existence of a CVE may be a good sign that you do have a vulnerable dependency, the absence of CVEs is not a good indication that you’re safe from vulnerabilities. In fact, many open source projects don’t have any process for handling security reports or publishing CVEs; this particularly affects the projects which may be neglected or abandoned by the maintainers. If you don’t have time to keep your open source up to date, you probably also don’t have time to hunt for security vulnerabilities and report them. While many eyes may make security problems shallow, there are a lot of libraries without many eyes on them.
The situation gets even worse when you consider transitive dependencies – if it’s hard to assess if an open-source library is being maintained, it’s even harder to look at that library’s dependencies and do those same checks. It might not even be an exaggeration to say that checking maintenance and security guarantees transitively might be nearly as expensive as forgoing open source altogether. Obviously, this would be a disaster, given our modern dependence on the rich commons of shared libraries across all areas of computing, from convenience to utility to safety-critical software. At the same time, this commons is being threatened by increasingly sophisticated hostile actors (including nation-states and criminal syndicates) with deep funding and experience subverting systems.
I’m excited to join Stacklok to work on solving these problems and defending our vast software commons in a way which both respects the efforts of maintainers and empowers software consumers to continuously assess their security posture. Securing our software supply chains is an enormous undertaking, and I’m excited by the opportunities to do good for projects at all scales – from individuals working in their spare time to foundations with paid maintainers to closed-source commercial offerings which provide customers with a trusted entity that they can contract with.
On a more personal note, I’m also excited to join the Stacklok team. This will be my third time working with Craig McLuckie (CEO); his ambition and vision are matched by a keen understanding of what’s possible with current technology and where the market is headed. I’m also eagerly looking forward to working with Luke Hinds (CTO) who founded the Sigstore project and shared compelling ideas of combining Sigstore with existing workflows to produce durable and non-falsifiable audit logs. I’m also excited to be working with VMware and Heptio veteran Eryn Muetzel on the product side, and working with all of the above to grow a diverse and distributed (fully remote) organization with strong open source understanding. If this sounds interesting, check out the Stacklock careers page to learn more.
