Container security controls frequently fail not because organizations lack standards or scanners, but because every service uses its own Dockerfile, building images in different ways, according to a new technical report from The New Stack. The analysis examines how Cloud Native Buildpacks—a CNCF graduated project that turns source code into container images without Dockerfiles—can improve security posture by centralizing how platform teams govern build inputs, runtime images, and patching workflows. The report argues that buildpacks make container controls easier to enforce and maintain across large, multi-team environments.
The report describes a common enterprise vulnerability response pattern where a critical security flaw is fixed in an approved runtime image, yet a week later some production workloads still run on the vulnerable base. Key obstacles include inconsistent Dockerfiles using different base image tags and Linux versions, making it harder to identify which service is affected; application images that start from a patched base but reinstall vulnerable dependencies because developers manually add packages; and uneven rebuild schedules where some teams rebuild frequently while others only rebuild when application code changes, leaving services without recent feature work running old vulnerable images for months. The absence of centralized inventory, SBOMs, image metadata, or deployment tracking means organizations can't reliably determine which applications remain vulnerable or measure patch propagation.
The report identifies four container security controls that buildpacks simplify at scale. First, buildpacks standardize build inputs through a controlled unit called a builder, which packages the buildpacks, lifecycle, build-time base image, and runtime base image used to create the final application image. "By controlling the builder, the organization also controls the buildpacks, runtime image family, lifecycle version, and build paths allowed in CI/CD," the report states. Second, buildpacks apply best practices by default: Cloud Native Buildpacks require buildpack code to run as a non-root user, separate build and runtime environments so compilers and build tools stay outside production, restrict modifications of the base image because buildpacks run without root privileges, and isolate sensitive build privileges to prevent untrusted buildpacks from receiving registry credentials. Third, buildpacks generate Software Bills of Materials for all dependencies they provide, in formats such as CycloneDX, SPDX, or Syft JSON, giving platform and security teams consistent image inventory data without requiring every application team to build its own SBOM process. Fourth, buildpacks enable patching at scale through a feature called rebasing, which replaces runtime base layers with layers from a newer run image without rebuilding the application from source; Kubernetes tools such as kpack can automate this process by tracking image resources and triggering rebuilds when the source, builder, buildpacks, or stack changes.
The report explains that container security controls drift largely because established containerization practices lack a single governed build path—each repository produces its own image, usually through a Dockerfile maintained by the application team. Dockerfiles push many security decisions onto developers: which base images to use, which packages to install, how to configure the runtime user, how minimal the image should be, how to track patches, and which CI policies to apply. Over time, as services multiply and teams change, these choices drift, and it's not unusual to see different repositories using different base images, update cycles, and even different interpretations of what "secure" means in practice. The report notes that a well-written Dockerfile can produce a minimal, hardened image, but the problem is expecting every developer to have enough container expertise to do this consistently across hundreds of repositories. Platform teams may publish a patched base image, but each application team must still notice the update, modify its Dockerfile, rebuild, test, and redeploy—some do it quickly, others late or not at all, leaving the control in place but adoption uneven.
After buildpacks adoption, the vulnerability response process changes: remediation starts with shared build inputs as the platform team updates the approved run image, builder, or buildpacks, then images are rebased when the fix affects the run-image OS layers or rebuilt when the affected component is a runtime like a JRE or Node.js runtime, or application dependencies. The report emphasizes that buildpacks don't remove the need for testing or deployment controls—application teams still own their code, dependencies, and compatibility testing, while SRE teams still promote, deploy, monitor, and when necessary roll back patched images. The most important change is the patch path itself: platform teams maintain the shared build inputs and automation, security defines scan policies and exception rules, and compliance defines the evidence that must be retained. "Buildpacks give organizations one controlled way to build container images instead of leaving every repository to define its own process," the report concludes, making security controls such as approved images, safe defaults, SBOMs, and patching easier to scale, with reduced drift, clearer ownership, and faster updates. Organizations don't face a rigid choice between buildpacks and Dockerfiles—when required, teams can create a custom buildpack and extend the build-time base image with a Dockerfile, resulting in a governed image strategy with controlled customizations rather than an all-or-nothing model. For teams struggling with container sprawl and inconsistent patching, shifting responsibility from individual developers to a platform layer may prove more sustainable than chasing compliance repo by repo.