Build1 publisher3 min readPublished
Buildpacks move the base image choice out of every application repository
In an account from The New Stack, a patched runtime image still misses production a week later because every service builds its own way, and buildpacks are offered as the shared path that closes the gap.
The Engineer · Build desk
What happened
- Missing standards and scanners are not where a New Stack article puts the failure of container security controls; it puts it on every service using its own Dockerfile and building images in slightly different ways.
- Its worked example has a critical vulnerability fixed in the organization's approved runtime image, and a week later some production workloads still running on the vulnerable base.
- The four causes it lists are base tag and version drift between repositories, manual package installs, uneven rebuild cadence, and no central inventory, SBOMs, image metadata or deployment tracking.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Adopting the shared path makes base image selection a platform deliverable: one team's defaults set the runtime for every service that builds through it.
- constraint Governing build inputs settles what the next build produces and leaves open when a service with no feature work builds again, so the exposure window is set by release cadence.
- exposure Because manual installs put vulnerable dependencies back on top of a patched runtime, an estate can be fully on the approved base and still carry the defect in the application layer.
- cost The container expertise the article says was expected of hundreds of developers now has to exist in the team running the path, and every service inherits that team's mistakes as well as its patches.
Getting a patched base image into production, in the article's account, still needs the application team to notice the update, modify its Dockerfile, rebuild, test and redeploy [5]. That is five actions, and every one of them sits with the application team; the patch came from somewhere else [6].
A shared build path removes the first two. The article's claim is that buildpacks take common containerization decisions out of individual repositories and put them into a governed path where platform teams control build inputs, runtime images, SBOM production, artifact metadata and update workflows [3][4]. A service's next build then picks up the approved runtime whether or not anyone on that team read the advisory.
Two of the four causes the article lists are properties of the build definition itself. The first is drift between repositories in base image tags, Linux versions and runtime versions; the second is the missing central inventory, SBOMs, image metadata and deployment tracking that leaves the affected set unknowable [2][7]. A shared path defines both in one place.
The other two are about timing and about what the application installs. Uneven rebuild cadence means a service with no recent feature work may run an old vulnerable image for months [8]. Governing build inputs changes what the next build produces. The schedule is a separate question. The article turns at that point to a section headed "The shift from repository-specific builds to a governed build platform" [9].
The dependency case is the awkward one. The article's own list has images that start from a patched base and then reinstall vulnerable dependencies because developers install packages by hand [2]. That defect sits above the runtime image. Replacing the base leaves it there.
On where drift starts, the piece is careful with the tool it is displacing. A well-written Dockerfile can produce a minimal, hardened image; the flexibility is what pushes choices about base images, packages, runtime user, minimality and CI policy onto developers [11]. "The problem is expecting every developer to have enough container expertise to do this consistently across hundreds of repositories," the author wrote [12]. A shared path moves that requirement to whoever runs the platform.
The clearest requirement in the piece is about the control itself: "A container security control isn't useful on its own. It must be applied consistently, observable in the running estate, and maintainable when images, dependencies, and vulnerabilities change," the author wrote [13]. Observability is the part a governed path makes cheap, because SBOMs and artifact metadata come out of the build platform instead of each repository [4]. The account is drawn from what the author has seen in more than one enterprise [14]. It puts no number on how much faster patches reach production.
What to watch
- Whether the rest of the article names what re-emits an application image when the governed base changes, and whether the application team sits in that loop.
- Whether any platform team running a shared build path publishes a propagation figure, such as the share of its estate on the current approved base.
- Whether buildpack-governed builds also constrain application dependency resolution, the failure mode the article places above the runtime image.