Chainguard’s pushed so far “left” in software security that plenty of platform engineers and security professionals still don’t understand the category yet*; there’s no Magic Quadrant to help them, either, although rumour abounds that one (for software supply chain security) is on its way.

That hasn’t stopped the company – all ~600 staff, ~480 customers, and lots of purpose-built-for-security software packages– having outsized ambitions. The hefty £892 million it has raised from a who’s who of software investors suggests they certainly see the gameplan and market opportunity. 

Those ambitions were on show at its second “Assemble” conference in New York this week, where the company touted multiple major new features, explained its new approach to providing a pipeline of secure software at scale (via its open-source DriftlessAF event-driven reconciliation infrastructure) and brought customers from OpenAI and KKR onstage. 

The announcements show Chainguard bullishly moving from not just hardening open-source container images and OSS libraries, but also to CI/CD workflows and even proprietary software, as it looks to cement a position as a trusted, managed supply chain partner for open-source consumers (which, let’s be honest, is pretty much everyone who is building…) 

What’s Chainguard again? A recap

Chainguard provides hardened, minimal container and VM images, secure open-source software libraries and a stripped back Linux distro built from source for security too. The idea, at its heart, is simple: Help customers create software and products with very secure, “zero CVE” building blocks.

(Dang, that sounds like lock-in to dependency on a proprietary if useful ecosystem, you say? CEO Dan Lorenc summed his response to this often-heard criticism in a January 2026 blog: “I don’t believe it’s possible to provide hardened containers with real software choice without from-source builds and your own distro. People call that ‘lock-in,’ but there’s no other honest way to do it. And besides, you’re already locked in if you’re using hardened images built from opaque binaries, abandoned images, and ad-hoc pipelines no one can reproduce…” (Disagree? Postcards welcome.)

Chainguard currently provides 400,000+ architecture-specific image versions, ranging from the likes of Pytorch, to an Apache Airflow Helm chart, its own distribution of the AWS Load Balancer Controller Helm chart, “pre-configured with hardened Chainguard Images…” and a lot more.

Anyhow, we’re burying the lede…

“AI is changing everything except the importance of CI/CD”

Despite all the changes that agentic coding tools have delivered, some things haven’t changed: the risk of ingesting insecure upstream OSS software packages into your software; the challenge of actually migrating from legacy codebases to more secure ones; the risk of third-party vendors’ janky, insecure code adding to your attack surface; and, increasingly, the risk that comes with using CI/CD workflows from a community marketplace…

Chainguard’s looking to tackle these risks with a swathe of new features.

Some of these push it a little right, Among those announced at the Assemble Summit, for example, were “Chainguard Actions” – a “securely rebuilt catalog of GitHub Actions and similar CI/CD workflows”; “Chainguard Commercial Builds” – a way for “commercial vendors to package and maintain their software” to an SLSA Level 3 standard “with zero CVEs... SBOMs, signatures, FIPS validation, and behavioral consistency”; and its “Guardener” agent – to help organisations migrate “legacy” container images to Chainguard-validated, secure ones. 

Its “Actions” release stood out to The Stack. Chainguard describes it as a “securely rebuilt catalog of GitHub Actions and similar CI/CD workflows.” 

(GitHub Actions is a platform built directly into GitHub that lets you execute custom, automated software development workflows in your repo. And like so much of the upstream software development landscape, it’s a bit of a Wild West; its marketplace, for example – a massive central hub where developers and companies share pre-built Actions – is easy to spam with potentially malicious actions that developers may be tempted to use.)

Chainguard says it has run security analysis on 20,000 GitHub Actions published in the community marketplace, has applied hardening to avoid the likes of “script injection vulnerabilities, insecure environment variable handling, or unsafe command interpolation” and published an auditable record of the changes it has made to each action; ultimately publishing the “Action” as a “verified artifact” that can be securely used…) 

Per its product team: “Modern development workflows rely heavily on reusable CI/CD automation. Actions handle dependency installation, artifact publishing, container builds, and deployment orchestration. They are pulled directly from public repositories and executed with elevated privileges in CI environments… CI/CD workflows have historically lacked meaningful security and compliance controls. Workflows can contain unsafe shell expressions, token exposure risks, or insecure input handling that create pathways to repository compromise or infrastructure access.”

Pushing its secure “software factory” approach into CI/CD as well as container images is statement of intent. It's arguably notable, too, that GitHub hasn't natively done more here.

How much more might Chainguard push into GitHub's space, we ask?

"Are you asking, we're going to compete with GitHub?" queries Lorenc.

"I don't know. We use GitHub. GitHub is kind of where all source code lives. There's a lot of tools around GitHub, though, right? It's not just a source code manager. And if you were to look at their suite of features, they have hundreds of things,and I think parts of those we will have to do: the way code gets reviewed, the way code gets tested, the way it gets built... but hundreds of other vendors offer those too."

Also notable in its new product releases was a “Commercial Builds” proposition where Chainguard works with partners to harden their proprietary software too: Elastic, Grafana, and GitLab are among the early adopters.

The proposition allows commercial vendors to meet the same SLSA Level 3 standards as OSS consumed via Chainguard and hands some of the heavy lifting like upstream patching, SBOM generation, and FIPS compliance to Chainguard - customers meanwhile get the confidence that they don’t have to make security exceptions for software from ISVs because they now (also) come with a zero-CVE guarantee and a verifiable audit trail…

It’s a statement of real ambition. As Chainguard CEO Dan Lorenc puts it to The Stack though, it's not different from what the company already does in many ways.

“Customers are saying, ‘why can't you fix this one?’ [container image etc.] And well, ‘the license says we can't! So let's go talk to that person and figure out how the two of us can work together to satisfy a mutual customer.’ It's a couple more hops, but at the end of the day, makes our catalogue better and more valuable for everyone…”

There’s a lot of trust involved there, The Stack ventures…

“We show them how we do it. We show them how they can check what we're doing,” Lorenc says.

There have been a few things to iron out, he admits, e.g. “sometimes when they know about a vulnerability before we do” (e.g. that was disclosed to the ISV privately but which Chainguard needs to help fix to get a secure container image into its catalogue) “but at the end of the day,” he says, “they're confident in the infrastructure we built and using that as a way to get their product to their customers…”

*How can we say this? We asked a bunch of (OK, three) fairly switched on principal engineers at big Real World CompaniesTM if they had heard of Chainguard and b) knew what it did. “No” and “no” was the answer, although one drew a vague but convincingly authoritative comparison with Snyk - which really doesn’t play in same place, ultimately.  

The link has been copied!