Why Building From Source Matters
When I first started working on Linux systems two decades ago, “building from source” was just what you did. You downloaded a tarball over FTP, ran ./configure && make && make install, and manually fixed whatever broke in the process. It was equal parts art, discipline, and debugging, and while it sometimes felt painful, it also gave you confidence! You knew what was running on your system because you built it, and you knew how it was built. And perhaps more importantly, you knew that you could modify it and build it again!
Over time, as software became more complex to assemble and faster to deliver, many of us quite readily traded most of that control for the speed and convenience of leveraging open source software, as it was built by others. Layers of automation abstract the details, and as long as it works and you’re getting it from a trusted source, it’s a great user experience.
And yet, as supply chain attacks and CVE storms have reminded us, the most basic principle of security still holds true: if you’re leveraging pre-built binaries from someone else, you'd better have absolute and ultimate trust in the organization that did build those binaries.
And that’s why, at Chainguard, we chose to do it the hard way, and we’ve built our business around trust.
We build every compiler, tool, package, library, and dependency from the original upstream source code — thousands of them — continuously, automatically, and verifiably.
It’s the foundation of our images, libraries, and virtual machines, all produced in a sealed environment where nothing unverified can slip in. Every artifact that leaves our factory is signed, attested, and traceable back to its origin.
The hard way is the reliable way
To be clear, building from source isn’t the easy path, but it’s the right one.
It means compiling every single package, every dependency, and every line of code from its original upstream source inside a hermetic environment with no network access, so nothing unverified can sneak in. It also means signing and attesting to every artifact we produce.
Why does that matter? Because in today’s software supply chains, most vendors start with someone else’s binaries. They harden, slim, or scan them, but they don’t control how those binaries were built. They’re inheriting someone else’s assumptions — and someone else’s vulnerabilities. When those upstream projects fall behind on patches, every downstream product built on top of them also falls behind.
At Chainguard, we flipped that model. We build from the same source repositories that the upstream maintainers publish, and we do it automatically, every time a new release is tagged. That control means when a CVE lands, we can rebuild from patched source immediately without waiting on anyone’s patch cycle.
What building from source enables
Building from source changes the nature of trust in software. It means every artifact begins life in the open, built from verified code under full visibility, so integrity isn’t something you bolt on later. Instead, it’s there from the start. These are some of the benefits provided by building from source.
Security you can verify
We cryptographically sign every artifact we ship and pair it with detailed provenance metadata, including what was built, when, where, and by whom. It’s the software equivalent of a birth certificate, and this verifiable chain of custody gives customers proof, not promises, that their software was built securely and hasn’t been tampered with.
Response in hours, not weeks
When the next high-profile vulnerability hits, our automation is already on it. The moment an upstream maintainer ships a fix, we pull it, rebuild, retest, and republish. No waiting for Debian, Alpine, Fedora, or CentOS to catch up. No manual patching. Just continuous security at the speed of automation.
Compliance by construction
Frameworks such as FedRAMP, PCI DSS, HIPAA, and NIS2 all require traceability and control. Because every Chainguard artifact is built from source, signed, and attested, our customers automatically inherit that compliance foundation. Instead of hunting down logs at audit time, they can show a cryptographically verifiable record of exactly how their software was built.
Why most vendors don’t do it
Building from source sounds simple — and it often is… the first time. But the complexity grows exponentially with every dependency, and with every subsequent release, branch, or version stream. Modern applications rely on thousands of transitive packages, and often have multiple different concurrently supported version branches. Many weren’t written with reproducibility in mind. They depend on network calls, unpinned versions, or fragile build scripts that behave differently every time.
We’ve spent years building the infrastructure to tame that complexity. Our build system, which we call the Chainguard Factory, recalculates entire dependency graphs from scratch every day. It uses event-driven automation, deterministic toolchains, and distributed caching to rebuild the open source world continuously — securely, verifiably, and reproducibly.
It’s the kind of system you only build if you believe that doing the hard work once can make life easier — and safer — for everyone else.
Doing the work so you don’t have to
Building from source isn’t nostalgia for the old days of make install. It’s about bringing that same certainty and craftsmanship into modern software delivery. It’s how we remove entire categories of risk before our customers ever see them, and it’s how we make trust measurable.
Every Chainguard image, library, or VM is a product of that process: clean, minimal, built from the ground up, and continuously verified. That’s the difference between assuming security and proving it.
Where to go next
If you’re curious what this looks like in practice, take a look at our Chainguard Images Directory. Every entry displays the date it was last rebuilt, the packages it includes, and its complete vulnerability status.
You can also read our Migration Best Practices Guide to see how organizations of every size are moving to source-first builds. If you’re ready to see how verifiable software fits into your own build process, our team can help you take the first step towards a secure-by-design workflow.
Building from source isn’t a marketing claim. It’s an engineering commitment — to transparency, to speed, and to trust. It’s what we’ve built Chainguard around, and it’s what we’ll keep building, one secure line of code at a time.
Share this article
Related articles
- Engineering
Accelerating Platform Adoption with Developer Trust
Chainguard helps Platform teams drive adoption with zero-CVE, customizable container images that make internal development platforms secure, fast, and trusted.
Sam Katzen, Staff Product Marketing Manager, and Matt Stead, Marketing
- Engineering
A Gift for the Open Source Community: Chainguard’s CVE-Free Raspberry Pi Images (Beta)
Chainguard has created the first-ever CVE-free, vulnerability-free Raspberry Pi image. Learn more about how it works and what makes this special.
Dustin Kirkland, SVP of Engineering
- Engineering
How CTOs Can Justify Technology Investments to the Board
Learn how CTOs can tie technology investments to increasing revenue, speeding innovation, and reducing risk and cost to drive positive business outcomes.
Matt Moore, CTO and Co-founder
- Engineering
Guest Post: Resiliency by Design and the Importance of Internal Developer Platforms
Gaurav Saxena, a Director of Engineering at an automotive company, talks through how internal developer platforms are an important part of resiliency by design.
Gaurav Saxena, Director of Engineering, Automotive Company
- Engineering
This Shit Is Hard: Hardening glibc
Chainguard uses compiler flags to be proactive in the security of our products. See how our compiler flag usage helped us catch a complex bug in glibc.
Sergio Durigan Junior, Senior Software Engineer
- Engineering
Announcing Kernel-Independent FIPS for Java
Kernel-Independent FIPS is now available across the full catalog of Chainguard FIPS images for Java, simplifying and accelerating compliance for FedRAMP ATO.
Dimitri John Ledkov, Principal Software Engineer, James Page, Principal Software Engineer, and John Slack, Senior Product Manager