This week we are continuing the deep dive into containers and how critical they are to the modern development cycle.

Chainguard is one of the most interesting cybersecurity startups right now in the industry, and their core business is all about reducing the risks associated with companies picking up images of software they want to deploy and then running into trouble because of undetected CVEs (Common Vulnerabilities and Exposures).

The key takeaway

For tech sales: The ideal time to join a startup is when they are starting to build momentum due to exceptional product-market fit but are not yet obvious to every single tech sales rep in the industry. Chainguard offers this opportunity right now, if you can handle the technical aspect of it.

For investors: There is an intersection of startups that get funded by both RedPoint (strong cloud infrastructure software expertise) and Sequoia (deep understanding of successful founders). It doesn't look like there are private secondary share transfers, but at $255M raised, there should be some liquidity in that direction if they do a Series D.

Who is Chainguard and why does it matter?

Chainguard has a lot of similarities to Wiz - technical founders who have worked on this problem for a long time, significant pain that the product solves, funding from Sequoia and RedPoint, and a passionate customer community. More on the origin story:

In December 2020, SolarWinds reported that its network monitoring platform had been hacked by operatives suspected of working for Russian intelligence. The attackers had planted malware in SolarWinds’ code, which allowed them to access the data of thousands of SolarWinds’ clients, from Microsoft to the U.S. government. The hack exposed a critical flaw in the security of software supply chains. Just as in real-world manufacturing, software is assembled from components created by developers all over the world. At some point during SolarWinds’ development process, malicious actors inserted malware into two software updates, which were then installed by customers all around the world. SolarWinds’ data breach was a wake-up call. Without verifying the integrity of software at every stage of its lifespan this type of hack could and would happen again.
Moore had left Google earlier in the year, and Lorenc had called him every month since, hoping to convince him to return. Moore was one of the finest software engineers Lorenc knew, and if anyone could find a solution to supply chain security, it was him. That night, Moore’s text to Lorenc said he was ready to get back to work—but not at Google. “Let’s start a new company,” Moore texted. Lorenc didn’t need to think twice. He was in.
The next day, Lorenc put in notice at Google, bought a new laptop and began work on Chainguard, a company focused on software supply chain security. Although technically the company was born that night in Austin, Lorenc had been preparing for this moment for years.

Now, in order to understand why Chainguard matters, we need to go back to our discussion around Docker and the importance of containers for deploying enterprise-grade software into production. The majority of software being used today (and we build B2B products on top) is open-source. More importantly, in a DevOps workflow, you would have multiple open-source products used by developers to perform a certain function or a closed-source product that is itself incorporating some of that open-source software.

We benefit tremendously from this setup because it allows for composability - somebody else solves a specific problem, and we get to then modify and use their product to solve a new pain on top of it.

In recent years, the idea of DevSecOps as a key part of the development cycle has been introduced, with a strong focus on extensive testing of the code prior to deployment for vulnerabilities (AppSec) and continuous monitoring post-production (Security Analytics). What Chainguard is trying to achieve is solving the supply chain attack risk - building on top of open-source images that are already exposed to vulnerabilities. To put it in a practical example, if you want to build a successful burger joint, you can ask the customers to smell the prepared product and decide if it's edible/get food poisoning, or you can start with fresh meat before you cook.

Chainguard is trying to deliver the fresh meat of secure images that developers can build on top of or utilize in their workflow.

In the months since Moore’s initial text to Lorenc at the restaurant in Austin, Chainguard had officially launched, and its founders had begun building its product and seeking out investors. Lorenc says starting a company at the beginning of 2022 wasn’t easy. Inflation was rising and a wave of layoffs at tech companies meant Lorenc would pitch Chainguard to software engineers—potential customers—one day, only to learn the following week that they had been laid off. After months of meetings, they finally gained traction. The need for supply chain security tools was too great, and companies realized they couldn’t handle the job alone.
Lorenc and the Chainguard team first met with Sequoia in the spring of 2022. Balkansky was impressed by Chainguard’s initial product in development, Chainguard Enforce, a program that scans containers and produces an itemized list of the code inside. Engineers can then review the list for malware and loopholes that might make the containers vulnerable to hackers. And so Balkansky was surprised to learn, just days after Sequoia’s partnership with Chainguard was finalized, that, according to Lorenc, Chainguard was in the midst of building out a far more ambitious product: Chainguard Images.
In computing, a “container image” refers to a static collection of executable code. Chainguard Images would be a library of these files, made from open-source code that Chainguard engineers would verify, sign, patch and secure. With Chainguard Images, customers would no longer have to opt for open-source code they’d found on the internet and hope for the best. Instead, they could select an image from Chainguard’s library and feel confident that their code was as advertised and could not be edited by bad actors.
This was a massive undertaking, which explained Balkansky’s incredulity when he first learned of it. To execute Chainguard Images, Lorenc and his team would first have to build a Linux distribution, an operating system on which Chainguard Images could run. Balkansky had worked with other companies who had endeavored to do this but hadn’t succeeded; he knew it was an incredibly complex task that could take years to complete, and even then there was no guarantee it would work.
Balkansky wasn’t the only one who was skeptical. Other software companies with thousands of engineers struggled to believe that Chainguard, with only 25 engineers, could not only build a Linux distribution, but also comb through and verify numerous libraries of code. “Yes, it seemed impossible,” Lorenc says. “Yes, just based on the sheer numbers, the lines of code we would need to pore over and adjust to make secure, it was daunting. Everyone else looked at it and saw it as too hard of a problem, too massive to actually solve. But it seemed obvious it was something we needed to do.” Lorenc shrugs, “To me, it didn’t seem impossible, it just seemed hard. And I’m okay with hard.”

This is a very hard and time-consuming problem to solve - everybody in the industry is aware of it, but it's just too much work. This is where the market opportunity for Chainguard comes into play.

So what does that mean from a day-to-day perspective for the team? This is an excerpt from a recent interview with Lorenc:

They get found every day in versions of software. But we have tons of automation and tooling and a lot of just manual work to go through and patch them when they're found.
So we have tight SLAs across the board, for the most part, most images have zero CVEs almost every day. We have graphs that you can show, and the graphs look like they're broken most of the time because it's always at zero.
But just one example. So there was a CVE in the Go standard library that got reported yesterday. When that happens, the Go compiler compiles a standard library into your Go program. So every time you build something with Go, that CVE is in there, and the scanners will flag it. That got disclosed. They send out a warning, like, four or five days in advance, when this is going to happen. Automation for us pick the new Go version up in minutes. It takes, you know, 10 to 12 minutes to build Go, something like that. But then we have, like, thousands of Go programs in our distro that we then have to go and rebuild. We get through all of those. Yesterday was our fastest one yet. We, we keep adding the packages, but we got through all of the Go rebuilds in something like six hours.
So in that six-hour window, technically there was a CVE in there, but the scanners and the vulnerability days and all of those other things, they take days or weeks to actually have these things show up from the disclose. So we don't even trust those. We're using the results ourselves. We're querying all of these sources directly.
Because our value proposition is zero as reported by all of your scanners, but that's not enough, because the scanners miss things, and we go as far as we can to make sure that we're building it even before the scanners pick these things up.

Now if we dig deeper into the first principles of why preventing supply chain attacks is critical:

Yeah, the first thing, like most of the scanners operate at the registry level because that's all you know about. If it's in the registry, that's the stuff you have to scan and they'll report those vulnerabilities for you. But that doesn't really matter in most cases. What matters is what's running in production. The registries don't know what's running in production. It's not their fault.
You might have Kubernetes. You could be using Docker Swarm, you could be running on ECS. Stuff could be running in bare metal clusters that are air gapped. You don't really know from the registry's perspective. So the first one to cut down the noise, just scan what's running in production or stuff that's about to be running in production. If you're scanning everything in the registry, it's so much noise and you don't even know from looking at the tags and the timestamps what's running in production.
But all the tech companies sort of got hit at the same time in 2012 or 2013, when a bunch of the nation states realized that instead of trying to break in from the outside, they could just have people go get jobs at the companies and then do whatever they wanted. And this is back in the time when like developers just had root access and SSH and prod because that's how you deployed stuff and CCP'd stuff over and FTP servers, and if you had to debug, you just jumped in and attached a tracer or something like that.
When you have 10,000 engineers at the company, there's probably 10 or 12 of them that are spies for some other country doing bad things, and there's no real way to, to prevent that. So the real protection that Google kind of put into place, to summarize quickly, is multiparty review for everything. No one can do anything without someone else signing off on that. P
Pretty simple when you put it that way, but when you start applying that transitively to anything that could have an effect on anything-It gets all the way back to the supply chain. It's not just the source code. If you review the source code but somebody's maintaining the Jenkins server under their desk, they can do whatever they want to that source code and they can put in whatever they want. So when you apply that to all of the infrastructure, all of the tools, all of the build stripses and everything, that's the only protection I know of really, to protect against this style of attack. And it doesn't even prevent it, it really just raises the bar because now you need two people cooperating or three people, however you want to set that threshold, instead of just one bad actor.
When you apply that to open source, you can start with that same principle of how do we do multiparty review for everything? And to do that, it requires securing all of the infrastructure so people can't log in and make changes without those going through audits, making sure that the code is reviewed, making sure that the build system itself is secure and is running repeatable scripts and they're not just curl piping to Bash from a URL that somebody might just want to go and change.
And it's a crazy daunting task when you look at the entire open source supply chain. So you can start out with that as, like, the high level goal, what you want to get to, but that's impossible to just jump straight to that step and it's overwhelming and y- you just kind of get turned off because you don't make progress along the way at all and you don't know where to start. So all of the hard work in SLSA really went into figuring out the, what steps can you take that actually get you incremental progress along that way and then explaining those in simple ways. And so that's where the levels come from. That applies to the source management system, that applies to the build servers, that applies to the way you install packages.
At the very end, it's incredibly ambitious, it's very hard to do. You shouldn't expect to be able to get there easily, but you don't have to. You're making gains, you're preventing things at each step of the way. We really wanted this to be something that you could do at scale and make progress.

So who is buying? Right now, its a lot of cloud infrastructure software companies:

They just had their sales kick-off and a lot of the reps seem very enthusiastic about where the company is going:

Hiring is also booming, with 42 new hires onboarded and multiple roles being open.

The enthusiasm is carried over at RepVue as well:

While I tend to be bearish on cybersecurity startups (99% of them will either make no money or end up as a feature in a platform), Chainguard is providing a service that matters and building a sustainable long-term community of both open-source users and paid customers.

My only concern is how their go-to-market play will evolve since their current sales leader is a marketing guy (if a prominent one, from Okta and Wiz), and it's difficult to understand what their actual sales process is or how it evolves as competition tries to catch up.

The monetization strategy is focused around 'production-ready' images, which is basically their full backlog of different vetted versions of the software they support. From a 'need' perspective this makes sense - enterprises will run many different versions of open-source software and if they buy into the vision, then a subscription is a logical step.

Deal size would be difficult to predict from here, but I wouldn't be surprised if they do get a lot of business above $250k ACV for companies with 5+ different open-source products that they want to get access to clean images. The lack of a consumption-style model is likely going to limit the benefit they get from signing those large customers, and they are likely still offering a lot of discounting to get those deals in (contact us for volume discounting!).

On the other side, this business model is friendlier to smaller companies that the founders would find very important to serve. Arguably, the success of Chainguard would be in mass adoption, not monetizing a top percentage of large accounts.

At the end of the day, what truly matters is whether the product helps customers win. And so far, it looks like Chainguard is achieving the right outcomes.

The Tech Sales Newsletter #83: Let’s harden some images

The key takeaway

Who is Chainguard and why does it matter?

The Tech Sales Newsletter #82: Letters from Stripe