Buildpacks: An Open-Source Alternative to Chainguard

The industry's increasing focus on secure container images is undeniable. Companies like Chainguard — specializing in delivering container images free of CVEs — have demonstrated the demand by recently raising an impressive $140 million at a $1.1 billion valuation. In the open-source ecosystem, Cloud Native Buildpacks, an incubating CNCF project, and their vibrant communities deliver a comparable value proposition by automating the creation of optimized and secure container images.

In this article, I'll explore Buildpack's core concepts, comparing them with Docker to illustrate their functionality and highlight how they provide a community-driven alternative to the value Chainguard brings to container security.

What Are Buildpacks?

Buildpacks automate the process of preparing your application for deployment, detecting dependencies, building runtime artifacts, and packaging everything into a container image. They abstract the manual effort to build images efficiently.

In other words, if Docker allows you to define how a container is built through a Dockerfile explicitly, Buildpacks operate at a higher level of abstraction. They offer opinionated defaults that help developers ship production-ready images quickly.

Comparing a Few Concepts

Buildpacks do containerization differently and more efficiently. For those unfamiliar with the technology, let's review a few key Docker concepts and see how they translate to the Buildpacks world.

Entrypoint and Start Commands

In a Dockerfile, the ENTRYPOINT or CMD specifies the command that runs when the container starts. For example:

Dockerfile
  
CMD ["java", "-jar", "app.jar"]  


Buildpacks abstract this step; you have nothing to do. They automatically detect the appropriate start command for your application based on the runtime and build process. For example, when using a Java Buildpack, the resulting image includes logic to start your application with java -jar app.jar or a similar command. You don't need to configure it explicitly; Buildpacks "just know" how to start applications based on best practices.

Writing a Dockerfile

The concept of not doing anything goes even further; you don't even need to write the equivalent of a Dockerfile. Buildpacks will take care of everything that is needed to containerize your application into an OSI image.

Multi-Stage Builds

That abstraction is not coming at the cost of optimization. For example, multi-stage builds are a common technique in Docker to create lean images by separating the built environment from the runtime environment. For instance, you might compile a Java binary in one stage and copy it to a minimal base image in the final stage:

Dockerfile
  
# Build stage  
FROM maven:3.8-openjdk-11 as builder  
WORKDIR /app  
COPY . .  
RUN mvn package  

# Runtime stage  
FROM openjdk:11  
COPY --from=builder /app/target/app.jar /app.jar  
CMD ["java", "-jar", "/app.jar"]  


Buildpacks handle the equivalent of multi-stage builds behind the scenes. During the build process, they:

  1. Detect your application's dependencies
  2. Build artifacts (e.g., compiled binaries for Java)
  3. Create a final image with only the necessary runtime components

This is again done automatically, requiring no explicit configuration.

About Security

Let's jump into the security part and explore a few ways that the Buildpacks ecosystem can be seen as an OSS alternative to Chainguard.

Non-Root Containers

Running containers as non-root users is a best practice to improve security. In Dockerfiles, this typically involves creating a new user and configuring permissions.

Buildpacks enforce non-root execution by default. The resulting container image is configured to run as an unprivileged user, with no extra effort required from the developer.

CVEs

Security is a significant focus for open-source Buildpack communities like Paketo Buildpacks, and Google Cloud. What these communities offer could be seen as the open-source alternative to Chainguard.

By default, Buildpacks use pre-configured, community-maintained base images that are regularly updated to eliminate known vulnerabilities (CVEs). 

For example, Paketo Buildpacks stacks (build image and run image) are rebuilt whenever a package is patched to fix a CVE, and every stack is rebuilt weekly to ensure packages without CVEs are also up to date. The community releases stack updates that fix high and critical CVEs within 48 hours of the patch release and two weeks for low and medium CVEs.

SBOM

Buildpacks can provide an SBOM to describe the dependencies that they provide. It supports three ways to report SBOM data: CycloneDX, SPDX, or Syft. Paketo Buildpacks also uses SBOM generation to provide a detailed record of all dependencies in the images they provide, making it easier to track and audit components for vulnerabilities.

A Solid OSS Chainguard Alternative

Buildpacks offer a simple, secure, and standardized way to create production-ready container images, making them a potential cornerstone of platform engineering strategy. By automating tasks like dependency management, non-root execution, and security updates, Buildpacks provide a community-driven alternative to commercial security solutions like Chainguard.

For teams looking to streamline workflows and enhance container security without the complexity of Dockerfiles and the cost and limitations of Chainguard, Buildpacks can be a solid starting point.

 

 

 

 

Top