From 5317fdca66ef1c7ef4589392cee8d814a304930e Mon Sep 17 00:00:00 2001 From: Kevin Dubois Date: Fri, 20 Feb 2026 18:17:55 +0100 Subject: [PATCH 1/3] Initial version of the graduation tech review of Buildpacks Signed-off-by: Kevin Dubois --- projects/buildpacks/tech-review/02-20-2026.md | 390 ++++++++++++++++++ 1 file changed, 390 insertions(+) create mode 100644 projects/buildpacks/tech-review/02-20-2026.md diff --git a/projects/buildpacks/tech-review/02-20-2026.md b/projects/buildpacks/tech-review/02-20-2026.md new file mode 100644 index 000000000..b24de0185 --- /dev/null +++ b/projects/buildpacks/tech-review/02-20-2026.md @@ -0,0 +1,390 @@ +# **General Technical Review \- Buildpacks / Graduation** + +* **Project**: Buildpacks +* **Project Version**: Platform API Spec v0.15, Buildpack API Spec v0.12 +* **Website**: [https://buildpacks.io/](https://buildpacks.io/) +* **Date Updated**: Jan 7, 2026 +* **Template Version**: v1.0 +* **Description**: Cloud Native Buildpacks (CNBs) transform your application source code into container images that can run on any cloud. With buildpacks, organizations can concentrate the knowledge of container build best practices within a specialized team, instead of having application developers across the organization individually maintain their own Dockerfiles. This makes it easier to know what is inside application images, enforce security and compliance requirements, and perform upgrades with minimal effort and intervention. The CNB project maintains a set of specifications and tooling that make it possible to write buildpacks and orchestrate them together in a build system. Additionally, community providers such as Google, Heroku, and the Paketo project maintain buildpacks for a wide variety of language families, and you can discover even more by searching the buildpack registry. + +## **Day 0 \- Planning Phase** + +### **Scope** + +* **Describe the roadmap process, how scope is determined for mid to long term features, as well as how the roadmap maps back to current contributions and maintainer ladder?** + * The Cloud Native Buildpacks (CNB) project is a community-driven project and maintains a [public roadmap on its GitHub page](https://github.com/buildpacks/community/blob/main/ROADMAP.md), which includes items such as the 2025H1 roadmap proposal. The process for changing the roadmap is documented in the [GOVERNANCE.md](http://GOVERNANCE.md) file located within the buildpacks/community repository. The Technical Oversight Committee (TOC) is explicitly responsible for the direction of the project (roadmap), along with team leadership and cross-cutting concerns. The project also clearly documents its contribution ladder, nomination, and election processes for the TOC, Maintainers, and Contributors in the buildpacks/community repository +* **Describe the target persona or user(s) for the project?** + * The documentation provides specific categories for target personas, including: + * App Developers + * Buildpack Authors + * Operators + * Generally, the project is designed for application developers and organizations looking to simplify and secure the container image creation process. +* **Explain the primary use case for the project. What additional use cases are supported by the project?** + * The primary use case for Cloud Native Buildpacks (CNBs) is to transform application source code into container images that can run on any cloud platform. + * Additional supported use cases include: + * Concentrating the knowledge of container build best practices within a specialized team. + * Making it easier to know what is inside application images. + * Enforcing security and compliance requirements,. + * Performing upgrades with minimal effort and intervention. +* **Explain which use cases have been identified as unsupported by the project.** + * Cloud Native Buildpacks (CNB) define their architectural boundaries by explicitly excluding use cases such as the creation of base operating system "Stacks," the execution of arbitrary imperative build scripts found in traditional Dockerfiles, and privileged build processes that require root access. This focused scope supports three distinct project personas: **App Developers**, who utilize the tool to convert source code into images without managing complex container configurations; **Platform Operators**, who leverage the centralized design to enforce organizational security compliance and perform fleet-wide upgrades; and **Buildpack Authors**, who employ the project's API specifications and tooling to create the modular logic responsible for transforming application code. +* **Describe the intended types of organizations who would benefit from adopting this project. (i.e. financial services, any software manufacturer, organizations providing platform engineering services)?** + * Organizations that benefit from adopting CNBs are those seeking to streamline container creation, especially by centralizing container build expertise and ensuring rigorous standards. + * Specific organizations and types of organizations noted as adopters include: + * Google (e.g., Google Cloud Run), + * VMware by Broadcom (e.g., Tanzu Buildpacks), + * Salesforce (e.g., Hyperpacks), + * Bloomberg + * Organizations that use CNBs in their CI/CD systems, such as those leveraging integrations with CircleCI and GitLab +* **Please describe any completed end user research and link to any reports.** + * [RFC-0071: CNB User Research 2021](https://github.com/buildpacks/rfcs/blob/main/text/0071-cnb-user-research-2021.md) + * [CNB User Survey: Winter 2021-2022](https://drive.google.com/file/d/1RtS9XpphiYeCFZW9LtB5x86I7AKNusBX/view?usp=sharing) + * The Winter '21-22 CNB User Survey highlights that while the community (primarily composed of software and DevOps engineers) highly recommends Cloud Native Buildpacks as a superior, declarative alternative to Dockerfiles, significant barriers to mass adoption persist. Users are primarily drawn to buildpacks for their ability to simplify container builds without Dockerfiles and to improve image security, yet they are frequently frustrated by documentation, the complexity of troubleshooting "black box" processes, and limited industry-wide use. Although many respondents are currently unsure of which specific APIs they use , there is a strong demand for future features such as a dedicated test API, better Kubernetes integration, and a migration of community support to CNCF Slack. + * The overall sentiment is reflected in the Net Promoter Score (NPS) data, where the most frequent score given was a 10 out of 10\. Many respondents indicated they already "recommend it to everyone" because it has "revolutionized" how they build containers. + +### **Usability** + +* **How should the target personas interact with your project?** + * Target personas interact with the project through specialized tooling and documentation tailored to their role. + * App Developers primarily use [pack](https://github.com/buildpacks/pack), a command line interface (CLI) tool maintained by the CNB project to support the use of buildpacks. They can follow guides such as "[An App’s Brief Journey from Source to Image](https://buildpacks.io/docs/app-journey/)," which introduces them to `pack`. + * Buildpack Authors interact with the project through tutorials, such as "How to write a basic buildpack," and rely on the CNB project's specifications and tooling. They are also supported by a dedicated Buildpack Authors' Tooling Team. + * Operators use platform tools, such as [kpack](https://github.com/buildpacks-community/kpack), which is a Kubernetes-native platform that uses Kubernetes primitives to execute buildpacks builds and maintain up-to-date application images. Operators benefit from the core value proposition of the project, which helps enforce security and compliance requirements and simplifies performing upgrades. + * Spring Boot developers interact transparently with a component of the `pack` tool. The component, called `lifecycle`, is integrated with the Spring Boot plugins for [`maven`](https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image) and [`gradle`](https://docs.spring.io/spring-boot/gradle-plugin/packaging-oci-image.html). Developers can create an OCI image for their Spring Boot project by calling a target in their preferred build tool. + * [Quarkus](https://developers.redhat.com/articles/2025/08/20/build-container-image-quarkus-project-using-buildpacks#build_a_container_image%20and%20https://quarkus.io/guides/container-image#buildpack) supports buildpacks. To support a Buildpacks build, you must install a new Quarkus extension. This exension adds support for Quarkus through the Quarkus Container Image framework. The Container Image Buildpack extension makes use of the Java Buildpack Client. This client executes the different phases of a Buildpacks build by driving the lifecycle binaries within different containers. +* **Describe the user experience (UX) and user interface (UI) of the project.** + * The project's primary interface is achieved through the command line using the `pack` CLI tool. + * The underlying user experience is centered on simplifying and securing the container image creation process by shifting the expertise required for container build best practices away from individual application developers and into a specialized team. This design makes it easier to track the contents of application images, enforce requirements, and execute upgrades with minimal effort. The project also provides specifications and tooling that enable the creation and orchestration of buildpacks within a build system. +* **Describe how this project integrates with other projects in a production environment.** + * The Cloud Native Buildpacks project integrates extensively with various CI/CD and container orchestration projects: + * CI/CD Systems (Project Maintained): + * CircleCI maintains an integration called an "orb," which enables users to execute `pack` commands within their pipelines. + * A collection of end-user [GitHub Actions](https://github.com/buildpacks/github-actions) integrate with Cloud Native Buildpacks projects. + * CI/CD Systems (Community Maintained): + * GitLab's Auto DevOps feature utilizes `pack` to build applications before deployment. + * Tekton is supported through a reference "task" created by the CNB project for performing buildpacks builds; this task calls the individual `lifecycle` binaries (`prepare`, `analyze`, `detect`, `restore`, `build` or `extender`, `export`),. + * Project Piper is a set of tools for continuous integration and continuous delivery that uses buildpacks. + * Integration with Jenkins has been the subject of several KubeCon talks. We have shown how to integrate `pack` into custom in-house Jenkins pipelines. + * Kubernetes and Orchestration: + * The project integrates with Kubernetes (k8s), as the images built using buildpacks can be run on Kubernetes. + * kpack is a platform within the Buildpacks Community organization that functions as an operator on Kubernetes to produce and maintain application images. + * Knative documents buildpacks as a viable method to build functions directly on the cluster. + * Container Runtimes: + * Buildpacks produce images that maintain compatibility with the Open Container Initiative (OCI) image specification. + * The `pack` CLI targets the Docker daemon API by default for image building. Therefore, it can use docker, podman or any other Docker daemon API compatible runtime for image building. + * Images built using buildpacks can be run by containerd. + * Podman can be used via the `pack` CLI as a Docker-compatible target for executing buildpacks. + +### **Design** + +* **Explain the design principles and best practices the project is following.** + * The core design principle of Cloud Native Buildpacks is to transform application source code into container images. This process is engineered to concentrate the knowledge of container build best practices within a specialized team, rather than distributing the responsibility among individual application developers. This approach facilitates key outcomes such as making it easier to track the contents of application images, ensuring the enforcement of security and compliance requirements, and allowing organizations to perform upgrades with minimal effort. The design centers on maintaining a set of specifications and tooling that govern how buildpacks are written and orchestrated within a build system. +* **Outline or link to the project’s architecture requirements? Describe how they differ for Proof of Concept, Development, Test and Production environments, as applicable.** + * The project's architecture is defined by its specifications, including the [Platform API Spec](https://github.com/buildpacks/spec/blob/main/platform.md) v0.15 and [Buildpack API Spec](https://github.com/buildpacks/spec/blob/main/buildpack.md) v0.12. + * Differences in environment deployment are typically achieved through different tooling: + * Development/Proof of Concept: App Developers primarily use the `pack` CLI tool. + * Production/Deployment: Operators may use integrated platforms like `kpack`, which runs as a Kubernetes-native operator to execute buildpacks builds and keep application images up-to-date using Kubernetes primitives. +* **Define any specific service dependencies the project relies on in the cluster.** + * The core Cloud Native Buildpacks components rely on container runtime environments but do not mandate external services like specific databases or message queues for their operation, unlike some other cloud-native services. The resulting container images are compatible with the Open Container Initiative (OCI) image specification, allowing them to run on systems managed by containerd or Kubernetes. The primary CLI tool, `pack`, targets the Docker daemon by default for image building. +* **Describe how the project implements Identity and Access Management.** + * N/A +* **Describe how the project has addressed sovereignty.** + * N/A +* **Describe any compliance requirements addressed by the project.** + * N/A +* **Describe the project’s High Availability requirements.** + * N/A +* **Describe the project’s resource requirements, including CPU, Network and Memory.** + * N/A +* **Describe the project’s storage requirements, including its use of ephemeral and/or persistent storage.** + * N/A +* **Please outline the project’s API Design:** + * **Describe the project’s API topology and conventions**: The project's API design is governed by two key documents: the [Platform API Spec](https://github.com/buildpacks/spec/blob/main/platform.md) and the [Buildpack API Spec](https://github.com/buildpacks/spec/blob/main/buildpack.md). These specifications define how buildpacks are written and how they are orchestrated in a build system. + * **Describe the project defaults:** The primary API client, the `pack` CLI, will, by default, target the Docker daemon for image building. + * **Outline any additional configurations from default to make reasonable use of the project:** The project maintains reference documents for Configuration that include [schema definitions for configuration files](https://github.com/buildpacks/spec). + * **Describe any new or changed API types and calls \- including to cloud providers \- that will result from this project being enabled and used:** N/A + * **Describe compatibility of any new or changed APIs with API servers, including the Kubernetes API server:** N/A + * **Describe versioning of any new or changed APIs, including how breaking changes are handled:** Comprehensive documentation regarding versioning of APIs and how breaking changes are handled is referenced within the [buildpacks/community](https://github.com/buildpacks/community/) repository. +* **Describe the project’s release processes, including major, minor and patch releases.** + * The project publicly documents its release process and guidelines in [RELEASES.md](https://github.com/buildpacks/community/blob/main/RELEASES.md). This documentation defines release expectations, how artifacts are included, and the strategies for tagging releases (stable, unstable, and security-related). The project demonstrates a history of regular, quality releases, with release announcements shared in the [\#buildpacks-announcements](https://cloud-native.slack.com/archives/C0333LFUBGU) Slack channel. Furthermore, detailed changelogs and release history are maintained in GitHub Releases for individual project components, such as the Pack CLI and the Buildpacks Specifications. + +### **Installation** + +* **Describe how the project is installed and initialized, e.g. a minimal install with a few lines of code or does it require more complex integration and configuration?** + * The installation and initialization of Cloud Native Buildpacks (CNB) depend on the chosen interface and environment: + * [Pack CLI](https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/): For most application developers and local development, the project maintains `pack`, a command-line tool. A minimal installation allows users to transform source code into container images using a single tool. + * [Kubernetes-Native (kpack)](https://github.com/buildpacks-community/kpack/blob/main/docs/install.md): In Kubernetes environments, users can adopt kpack, which is a platform within the Buildpacks Community organization that uses Kubernetes primitives to perform buildpacks builds and maintain images. + * CI/CD Integrations: The project supports [Github Actions](https://github.com/buildpacks/github-actions/), "orbs" for CircleCI and built-in "Auto DevOps" features for GitLab, allowing for streamlined integration into existing pipelines.Installion of these depends on the platform selected. + * Lifecycle Binaries: For more complex or custom build systems like Tekton, the project provides a reference "task" that calls individual lifecycle binaries—such as prepare, analyze, detect, restore, build, and export—to run each phase in separate containers. +* **How does an adopter test and validate the installation?** + * Adopters typically validate their installation through practical application and artifact verification: + * Tutorial Validation: The project directs new users to the "An App’s Brief Journey from Source to Image" tutorial, which uses the `pack` tool to verify that the system can successfully convert source code into a runnable image. + * Artifact Output: A successful installation is validated when the system produces an OCI-compliant container image. These images can then be tested by running them on a compatible container runtime such as Docker, containerd, or Kubernetes. + * Lifecycle Execution: In platform-specific integrations like Tekton, validation involves ensuring the individual lifecycle phases (e.g., detect, build, and export) complete without errors to produce the final application image. + +### **Security** + +* **Please provide a link to the project’s cloud native [security self assessment](https://tag-security.cncf.io/community/assessments/).** + * The Cloud Native Buildpacks (CNB) project has conducted a security self-assessment and an external audit, the results of which were [publicly posted on the project’s blog](https://medium.com/buildpacks/announcing-findings-from-security-audit-b4701f4e8b4b). Additionally, the project references a Due Diligence document as part of its graduation application. +* Please review the [Cloud Native Security Tenets](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/secure-defaults-cloud-native-8.md) from TAG Security. + * **How are you satisfying the tenets of cloud native security projects?** + * The project satisfies security tenets by providing a mechanism to concentrate container build best practices within specialized teams, which allows for the enforcement of security and compliance requirements across an organization. It further enhances security through its reference implementation, `kpack`, which uses unprivileged Kubernetes primitives to perform builds. + * **Make security a design requirement** \- Cloud Native Buildpacks make security a central design requirement by decoupling the build definition from application developers, allowing organizations to **concentrate container build best practices within a specialized team** that enforces consistent compliance and secure defaults across the fleet. This architectural shift is reinforced by technical safeguards such as **unprivileged execution**, which runs builds without root access to minimize the attack surface. Additionally, the project ensures supply chain integrity by creating a transparent bill of materials that makes it **easier to know what is inside application images**, while simultaneously enabling operators to **perform upgrades with minimal effort** by patching base operating system layers without needing to rebuild application source code. + * **Applying secure configuration has the best user experience** \- Cloud Native Buildpacks deliver a superior user experience for secure configuration by abstracting the complexity of container hardening away from individual developers and concentrating it within specialized platform teams. By removing the need for developers to maintain their own Dockerfiles, the project eliminates the friction and risk associated with manual security configuration, allowing teams to enforce compliance and best practices centrally. This approach enables "secure by design" outcomes where critical tasks (such as applying unprivileged execution controls and patching system vulnerabilities) are handled automatically, allowing organizations to perform security upgrades with "minimal effort and intervention" without disrupting the developer's workflow. + * **Selecting insecure configuration is a conscious decision** \- Cloud Native Buildpacks enforce a "secure by default" posture, ensuring that selecting an insecure configuration is a conscious decision made by platform operators rather than an accidental oversight by application developers. By abstracting the build process, the project concentrates best practices within specialized teams who define the base images and compliance standards. The default architecture prioritizes unprivileged execution and respects the specific user and group identifiers defined in the builder image. Consequently, any deviation from these safeguards, such as "loosening" security defaults to allow privileged operations, requires deliberate and explicit configuration. + * **Transition from insecure to secure state is possible** \- With Cloud Native Buildpacks, the transition from an insecure to a secure state is achievable through automated remediation and centralized policy enforcement. The project’s architecture allows platform operators to "perform upgrades with minimal effort and intervention" by swapping out vulnerable base images for patched ones without requiring a rebuild of the application source code, thereby instantly transitioning artifacts from a vulnerable state to a secure one,. Furthermore, the project facilitates an organizational transition to security by enabling teams to "concentrate the knowledge of container build best practices within a specialized team" rather than relying on individual developers; this centralization replaces potentially insecure, ad-hoc configurations with strictly enforced security and compliance requirements across the entire software fleet. + * **Secure defaults are inherited** \- With Cloud Native Buildpacks, secure defaults are inherited automatically because the project decouples the application source code from the container build configuration, thereby eliminating the need for developers to manage individual Dockerfiles that may contain insecure, ad-hoc settings,. This architectural separation allows organizations to **concentrate the knowledge of container build best practices within a specialized team**, ensuring that critical security configurations (such as unprivileged user execution and compliance mandates) are defined centrally and effectively "inherited" by every application that uses the provided buildpacks. Consequently, when platform operators update a buildpack or base image to address a vulnerability, the secure state is propagated across the entire fleet with **minimal effort and intervention,** ensuring consistent security posture without requiring developers to manually update or rebuild their application code. + * **Exception lists have first class support** \- With Cloud Native Buildpacks, exception lists have first-class support through mechanisms like **Extensions** and granular configuration, which allow operators to deliberately bypass standard security constraints when necessary. While the project enforces "secure by default" behaviors such as unprivileged execution and standardized layers, it accommodates valid edge cases by supporting **Extensions** (described as "Dockerfile to be applied") that enable users to inject imperative, custom build logic directly into the lifecycle. This design ensures that exceptions (such as the need for specific system privileges or non-standard dependencies) are handled as explicit, managed configurations within the build system rather than requiring users to abandon the tool for completely unmanaged alternatives. + * **Secure defaults protect against pervasive vulnerability exploits** \- With Cloud Native Buildpacks, secure defaults protect against pervasive vulnerability exploits by decoupling the application layer from the underlying system dependencies, allowing platform operators to address threats centrally without relying on individual developer intervention. By eliminating the need for scattered, manually maintained Dockerfiles, the project prevents the accidental introduction of insecure configurations and ensures that all builds execute using **unprivileged primitives**, thereby mitigating privilege escalation attacks during the build process. Furthermore, this architecture provides a robust defense against fleet-wide vulnerabilities (such as those affecting standard libraries or the OS) by enabling operators to verify exactly what is inside application images and apply patches across the entire organization with minimal effort, ensuring that critical security updates are propagated instantly across the supply chain. + * **Security limitations of a system are explainable** \- With Cloud Native Buildpacks, the security limitations of a system are explainable because the project replaces opaque, arbitrary build scripts with a structured lifecycle that provides deep visibility into the artifact composition. By generating images through a standardized process, Buildpacks make it easier to know what is inside application images, effectively providing a transparent bill of materials that allows operators to audit dependencies and identify specific risks or compliance gaps. This inherent transparency ensures that the security posture of an application is not a "black box," but rather a verifiable state where vulnerabilities can be precisely located, explained, and remediated by specialized platform teams without relying on individual developer knowledge. + * **Describe how each of the cloud native principles apply to your project.** + * *Make security a design requirement* + * CNB was architected from the ground up to solve the security pitfalls of traditional Dockerfiles (e.g., running as root, stale base images). + * **Separation of Concerns:** The CNB lifecycle is split into distinct phases (Detect, Analyze, Restore, Build, Export). This design ensures that untrusted buildpack code (run during the build phase) is isolated from sensitive credentials (used in the export phase to push to a registry). + * **Minimal Surface Area**: Buildpacks distinguish between "Build" images (containing compilers/tools) and "Run" images (containing only the minimal production runtime), significantly reducing the attack surface of the final production container. + * *Applying secure configuration has the best user experience* + * The opinionated defaults for CNB are designed to be as simple as possible while remaining secure. + * **Zero-Config Security**: For a developer, the command is simply `pack build`. By default, this uses a trusted builder that produces an image with a non-root user and a hardened OS, without the developer needing to know how to write a secure Dockerfile. + * **Automated Detection**: Security is improved when it's easy; A Cloud Native Buildpack implementation may use the *Detect* phase to automatically detect the language and applies the latest vetted patches for that runtime (e.g., the latest JVM or Go version) automatically. + * All output images contain a **Software Bill of Materials**. This supports wider software development lifecycle security practices such as scanning images for known vulnerabilities. + * *Selecting insecure configuration is a conscious decision* + * CNB makes it difficult to accidentally create an insecure image. + * **Trusted Builders:** By default, the pack CLI will only execute a "trusted" builder. If a user wants to use an unvetted or third-party builder that might have higher privileges, they must explicitly add the `--trust-builder` flag, making the risk a conscious choice. + * **Explicit Overrides:** To run as root or add dangerous capabilities, a user must go out of their way to customize the "Stack" or "Run Image," which are typically guarded by platform operators. + * *Transition from insecure to secure state is possible* + * The defining feature of CNB for this principle is Rebasing. + * **The Rebase Feature**: If a critical OS-level vulnerability (like Heartbleed or Shellshock) is found in a base image, CNB allows operators to "swap" the underlying OS layer of an app image without rebuilding the application. + * **Gradual Updates**: This enables a seamless transition from an insecure state to a secure one across thousands of applications instantly, without requiring developers to change their code or trigger a CI/CD rebuild. + * *Secure defaults are inherited* + * CNB follows a hierarchical security model where the application "inherits" the security of its foundation. + * **Upstream Security**: App developers inherit the security hardening performed by specialized "Buildpack Authors" (like Paketo, Heroku, or Google Cloud). If the builder image is updated with a security fix, every app built with it automatically inherits that protection in its next build or rebase. + * *Exception lists have first class support* + * Security policies in CNB are strict but flexible through managed overrides. + * **Buildpack Order and Groups**: Operators can define which buildpacks are allowed to run. If an application requires a specific "exception" (e.g., an older runtime version for compatibility), it can be handled via an explicit project.toml or a custom buildpack group, allowing for granular tracking of where and why exceptions exist. + * **Build-time Extensions**: Recent versions of CNB allow for "Image Extensions" (Dockerfiles) to handle edge cases, but these are modular and can be audited separately from the core build logic. + * *Secure defaults protect against pervasive vulnerability exploits* + * CNB addresses the most common container security risks by default. + * **Non-Root by Default:** Nearly all CNB builders enforce a non-zero UID/GID for the application, mitigating many container breakout and privilege escalation exploits. + * **Software Bill of Materials (SBOM)**: CNB automatically generates an SBOM (in formats like CycloneDX or SPDX) for every image. This allows organizations to scan for "pervasive vulnerabilities" across their entire fleet by knowing exactly which versions of every library (Log4j, etc.) are present in every layer. + * *Security limitations of a system are explainable* + * The CNB project maintains high transparency regarding its security boundaries. + * **The Trusted Model**: The specification clearly defines what a buildpack can and cannot do. For instance, it explains that while buildpacks can secure the runtime environment, they cannot protect against malicious logic within the application source code itself. + * **Security Audits**: As a CNCF project, CNB undergoes third-party security audits (e.g., by Quarkslab) that are published openly, detailing potential attack vectors and the trade-offs made within the specification. + * **How do you recommend users alter security defaults in order to "loosen" the security of the project? Please link to any documentation the project has written concerning these use cases.** + * In the project's Self-Assessment for CNCF TAG Security, the maintainers explicitly define the trade-offs: + * "The container build process must be usable with untrusted application code... this implies all containers running CNB tooling must run without any capabilities or privileges." When users choose to use the methods above, they are consciously moving away from this "standard security guarantee" to gain specific functional outcomes. + * Using "Trusted Builders" (Trading Isolation for Performance). By default, the `pack` CLI executes the build in multiple separate containers (phases) to ensure that untrusted buildpack code is isolated from sensitive registry credentials and metadata. To "loosen" this isolation for better performance, the project allows you to "trust" a builder. + * Mechanism: Using the `--trust-builder` flag or the `pack config trusted-builders add` command. + * Effect: This allows the entire lifecycle to run in a single container (using the `creator` phase), which means the potentially untrusted buildpack code shares an environment with sensitive data. + * Documentation: [Trusted Builders Concept](https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/concepts/trusted_builders/) + * Image Extensions (The Dockerfile "Escape Hatch"). One of CNB's core security features is the elimination of arbitrary Dockerfile commands. However, the project acknowledges that some users need system-level packages (e.g., `libpq-dev`) that buildpacks don't provide. + * Mechanism: Providing a `build.Dockerfile` or `run.Dockerfile` within the project. + * Effect: This triggers the "Extender" phase, which the project explicitly states typically runs as root to execute instructions like `apt-get install`. This is a significant departure from the standard non-privileged build model. + * Documentation: [Image Extensions Concept](https://www.google.com/search?q=https://buildpacks.io/docs/concepts/components/image-extension/) + * Bypassing the Launcher (Loosening Runtime Environment). The CNB launcher is responsible for setting up the secure execution environment, including environment variable isolation and process management. Users can "loosen" this control to get a "raw" container experience. + * Mechanism: Overriding the image entrypoint (e.g., `docker run --entrypoint bash` ...). + * Effect: This bypasses the launcher entirely. The project notes that in this mode, "profile scripts have NOT been sourced and buildpack-provided environment variables are NOT set." + * Documentation: [Running the Application (No Launcher)](https://www.google.com/search?q=https://buildpacks.io/docs/app-developer-guide/run-an-app/%23no-launcher) + * Experimental Features Flag. Many of the features that allow for "loosened" security or experimental flexibility are gated behind a global configuration flag to prevent accidental use in production. + * Mechanism: Running `pack config experimental true`. + * Effect: Unlocks capabilities like non-standard build behaviors. + * Documentation: [Pack Config Experimental CLI](https://buildpacks.io/docs/tools/pack/cli/pack_config_experimental/) +* **Security Hygiene** + * **Please describe the frameworks, practices and procedures the project uses to maintain the basic health and security of the project.** + * Access Control: The project enforces Two-Factor Authentication (2FA) for its GitHub organizations, buildpacks and buildpacks-community. + * Reporting: A clear process for reporting security issues is maintained via a [SECURITY.md](https://github.com/buildpacks/.github/blob/main/SECURITY.md) file. + * Vulnerability Management: The Cloud Native Buildpacks (CNB) project maintains a rigorous security posture by blending standard CNCF governance with automated "security-by-design" features. Procedurally, the project enforces the "Four-Eyes Principle" for code reviews, strict branch protections, and mandatory MFA for all maintainers. + * To handle the heavy lifting of vulnerability management, the project integrates CNCF Snyk and CNCF FOSSA directly into its CI/CD pipelines. Snyk serves as the primary security engine, scanning both source code and container layers for known CVEs and providing automated pull requests to fix dependencies. Complementing this, FOSSA monitors the "legal health" of the project by auditing every dependency for license compliance, ensuring that no incompatible or high-risk "copyleft" code slips into the ecosystem. Together, these tools ensure that the project remains secure, compliant, and easy to audit for end-users. + * Auditing: CNB recently completed a third-party security review with Quarkslab and the Open Source Technology Improvement Fund (OSTIF). + * **Describe how the project has evaluated which features will be a security risk to users if they are not maintained by the project?** + * As a result of the third-party security review, the project is tracking and resolving findings such as the need for PR review guides to identify memory leaks and vulnerabilities specific to the project's design or language choices. +* **Cloud Native Threat Modeling** + * **Explain the least minimal privileges required by the project and reasons for additional privileges.** + * The project emphasizes the use of unprivileged primitives for builds in Kubernetes environments via `kpack`. Furthermore, the build process utilizes the uid and gid defined in the builder image to execute the build, ensuring controlled permissions during image creation. + * **Describe how the project is handling certificate rotation and mitigates any issues with certificates.** + * N/A + * **Describe how the project is following and implementing [secure software supply chain best practices](https://project.linuxfoundation.org/hubfs/CNCF_SSCP_v1.pdf)** + * Buildpacks are designed to improve the software supply chain by making it easier to identify the contents of application images and automate upgrades with minimal effort. The project is also improving its supply chain by ensuring adequate test coverage on all Pull Requests and resolving findings from its third-party security review. + * The `kpack` kubernetes operator implements [SLSA Level 4](https://slsa.dev/spec/v0.1/levels) compliant build processes. This supports organizations reaching SLSA Level 4 across their entire software artifact production pipeline. + +## **Day 1 \- Installation and Deployment Phase** + +### **Project Installation and Configuration** + +* **Describe what project installation and configuration look like.** + * **I**nstallation is the act of adopting the project's standardized "lifecycle", which acts as the engine for turning code into OCI-compliant images regardless of the underlying infrastructure. + * [Pack CLI](https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/): For most application developers and local development, the project maintains `pack`, a command-line tool. A minimal installation allows users to transform source code into container images using a single tool. + * [Kubernetes-Native (kpack)](https://github.com/buildpacks-community/kpack/blob/main/docs/install.md): In Kubernetes environments, users can adopt `kpack`, which is a platform within the Buildpacks Community organization that uses Kubernetes primitives to perform buildpacks builds and maintain images. + * CI/CD Integrations: The project supports [Github Actions](https://github.com/buildpacks/github-actions/), "orbs" for CircleCI and built-in "Auto DevOps" features for GitLab, allowing for streamlined integration into existing pipelines. Installation of these depends on the platform selected. + * Lifecycle Binaries: For more complex or custom build systems like Tekton and Spring Boot, the project provides a reference "task" that calls individual lifecycle binaries—such as prepare, analyze, detect, restore, build, and export—to run each phase in separate containers. + +### **Project Enablement and Rollback** + +* **How can this project be enabled or disabled in a live cluster? Please describe any downtime required of the control plane or nodes.** + * Cloud Native Buildpacks are a set of specifications and tooling rather than a single monolithic service, meaning enablement depends on the platform being used. + * Kubernetes-Native (`kpack`): In a live cluster, the project is typically enabled by deploying `kpack`, which is a Kubernetes-native platform that functions as an operator. + * Downtime: Because `kpack` uses unprivileged Kubernetes primitives to perform builds and maintain images, enabling or disabling the operator generally does not require downtime for the control plane or the nodes. + * CI/CD Integration: For other environments, enablement involves integrating the `pack` CLI or reference Tekton tasks into existing pipelines, which does not impact the live cluster's running state. +* **Describe how enabling the project changes any default behavior of the cluster or running workloads.** + * Enabling the project does not fundamentally alter the default behavior of the Kubernetes cluster itself; instead, it changes the lifecycle of application images. + * Workload Creation: The primary change is the shift from manually maintained Dockerfiles to a standardized process where source code is transformed into container images using specialized buildpacks. + * Security and Compliance: Once enabled, the project allows for the centralized enforcement of security and compliance requirements across all application images. + * Automation: It enables automated upgrades of application images with minimal intervention, ensuring that workloads are running on the most current and secure base layers. +* **Describe how the project tests enablement and disablement.** + * Verification of the project's functionality is handled through its reference tools: + * Verification via `pack`: Adopters are encouraged to use the `pack` CLI to validate that the environment can successfully produce runnable images. + * Reference Tasks: The project maintains reference "tasks" for systems like Tekton, which call individual lifecycle binaries (prepare, analyze, detect, etc.) to ensure each phase of the enablement is functioning correctly. + * Security and Stability Testing: The project ensures the health of its components by maintaining high test coverage on all Pull Requests and resolving findings from third-party security reviews. +* **How does the project clean up any resources created, including CRDs?** + * The cleanup process depends on the specific implementation used within the cluster: + * kpack (CRDs): Since `kpack` is a Kubernetes-native platform within the Buildpacks Community organization, cleanup involves removing the operator and its associated Custom Resource Definitions (CRDs) using standard Kubernetes orchestration commands (such as kubectl delete). + * OCI Artifacts: Because the project produces OCI-compliant container images, the resulting application images remain as independent artifacts in a registry even after the build tools (like `kpack` or `pack`) are removed from the cluster. + * Lifecycle Binaries: In ephemeral build environments (like Tekton), resources are typically cleaned up automatically once the separate containers for each lifecycle phase complete their tasks. + +### **Rollout, Upgrade and Rollback Planning** + +* **How does the project intend to provide and maintain compatibility with infrastructure and orchestration management tools like Kubernetes and with what frequency?** + * Cloud Native Buildpacks maintain compatibility through adherence to standardized specifications and dedicated integration tools: + * Kubernetes Compatibility: The project maintains `kpack`, a Kubernetes-native platform that uses unprivileged Kubernetes primitives to perform builds and keep images up-to-date. + * Standardization: Compatibility is anchored by the OCI (Open Container Initiative) image specification, ensuring that any image produced by a buildpack can run on containerd, Docker, or Kubernetes. + * Orchestration Tools: Integration is maintained for Tekton through reference "tasks" and for Knative, which documents buildpacks as a primary method for building functions. + * Frequency: The project demonstrates a history of regular, quality releases for its core components, including the Pack CLI and Specifications. +* **Describe how the project handles rollback procedures.** + * The project handles rollback through its immutable image architecture. Because buildpacks transform source code into versioned OCI-compliant images, a rollback is typically achieved by reverting the deployment to a previously successful image version. The project design allows for upgrades with minimal effort and intervention, which simplifies the transition between image versions. + * The community maintained `kpack` implementation is distributed as a set of CRDs. These can be packaged into a helm chart, or similar, and rolled back using standard kubernetes processes. Fields added in a newer CRD are pruned in the usual manner. +* **How can a rollout or rollback fail? Describe any impact to already running workloads.** + * A "rollout" in the context of buildpacks usually refers to the image build process. + * Failure Modes: A build can fail during any of the individual lifecycle phases, such as detect, build, or export. + * Impact on Workloads: Because buildpacks are used to create images before they are deployed, a failure in the build or export phase generally has no impact on already running workloads; the existing pods or containers continue to run on their current image until a new, successful image is produced and deployed. + * The community `kpack` implementation provides CRDs that platform teams usually deploy using `helm` or [`kapp`](https://carvel.dev/kapp/). These tools report the failure to rollout or rollback the `kpack` CRDs. + * In the context of the community `kpack` implementation a rollout can fail. In practice, we have not observed failures but platform teams are advised to apply the CRDs using helm’s `--atomic` flag. A failure resulting in a partial application of the CRDs to a cluster has no impact on the images already built by the cluster. However, the cluster will not build new images until the failure is rectified. +* **Describe any specific metrics that should inform a rollback.** + * The project does not provide specific metrics that trigger an automated rollback for the buildpacks themselves. However, the project emphasizes that adopters should monitor the health of the application/service and its workloads produced by buildpacks to ensure stability. + * The community `kpack` implementation provides the standard kubernetes metrics. Platform operators can monitor the number of image build failures and correlate this with any buildpack updates. However, failures due to a buggy buildpack do not indicate an issue with `kpack` itself. The normal operation is to update the buggy buildpack and observe image builds subsequently completing successfully. +* **Explain how upgrades and rollbacks were tested and how the upgrade-\>downgrade-\>upgrade path was tested.** + * The project is primarily a specification. We version control the specification and the reference implementation, `pack`, advertises its compatibility with versions of the specification. It validates that the buildpacks meet the version of the specification that `pack` supports. Newer versions of `pack` may drop support for older versions of the specification. + * The project ensures the stability of its upgrade paths of the `pack` tool through several rigorous practices: + * Test Coverage: The project maintains high test coverage on all Pull Requests to prevent regressions. + * Reference Implementations: Continuous testing is performed on the reference implementation components maintained by the Implementation Team to ensure specification compliance across versions. + * The `kpack` CRDs are a community maintained implementation of the Buildpacks specification. The CRDs are upgraded and downgraded using the standard kubernetes processes and tools. +* **Explain how the project informs users of deprecations and removals of features and APIs.** + * The project utilizes multiple public channels to communicate changes: + * Slack: Announcements are made in the [\#buildpacks-announcements](https://cloud-native.slack.com/archives/C0333LFUBGU) channel. + * GitHub: Detailed changelogs and release histories are maintained for every project component, such as the Pack CLI and the Buildpacks Specifications, within GitHub Releases. + * Documentation: The project follows a public release process and guidelines document ([RELEASES.md](http://RELEASES.md)) that defines expectations for stable and unstable releases. +* **Explain how the project permits utilization of alpha and beta capabilities as part of a rollout.** + * The project manages the rollout of new capabilities through its tagging and release strategy: + * Release Tagging: Releases are explicitly tagged as stable or unstable, allowing users to opt into experimental features by selecting unstable artifacts. + * Governance: Changes to project goals or significant features follow a formal [RFC (Request for Comments) process](https://github.com/buildpacks/rfcs), allowing the community to test and provide feedback on new capabilities before they are finalized. + +## **Day 2 \- Day-to-Day Operations Phase** + +### **Scalability/Reliability** + +* **Describe how the project increases the size or count of existing API objects.** + * The Buildpacks project interacts with API objects primarily through its integration with platforms like `kpack`, which is a Kubernetes-native platform that uses Kubernetes primitives to perform buildpacks builds. In a Kubernetes environment, using buildpacks through `kpack` involves creating and managing Custom Resource Definitions (CRDs) and pods for each build phase. +* **Describe how the project defines Service Level Objectives (SLOs) and Service Level Indicators (SLIs).** + * The project covers parameters to ensure the health of the application/service and its workloads, but it does not explicitly provide specific numeric SLOs or SLIs for the core CNB components. In a production environment, these are typically defined by the platform implementing the buildpacks (such as Google Cloud Run, Heroku, or VMware Tanzu). +* **Describe any operations that will increase in time covered by existing SLIs/SLOs.** + * N/A +* **Describe the increase in resource usage in any components as a result of enabling this project, to include CPU, Memory, Storage, Throughput.** + * Resource usage in the CNB project is concentrated during the build lifecycle. The project utilizes separate containers for each phase of the process: prepare, analyze, detect, restore, build (or extender), and export. This modular approach implies that resource usage (CPU and Memory) is ephemeral and scales with the number of concurrent builds being performed by the system. +* **Describe which conditions enabling / using this project would result in resource exhaustion of some node resources (PIDs, sockets, inodes, etc.)** + * The project does not specify particular conditions that would lead to the exhaustion of node resources like PIDs or sockets. However, because the Buildpacks Phases Task executes multiple containers for a single build, an extremely high volume of concurrent builds without proper orchestration limits could theoretically impact node-level resources. +* **Describe the load testing that has been performed on the project and the results.** + * TODO +* **Describe the recommended limits of users, requests, system resources, etc. and how they were obtained.** + * The project does not provide specific recommended limits for users or system resources. Resource dimensioning is generally handled by the implementing platform, such as `kpack` or Tekton, based on the underlying infrastructure. +* **Describe which resilience pattern the project uses and how, including the circuit breaker pattern.** + * While the project does not explicitly address "circuit breaker" patterns, the project demonstrates reliability through modular isolation. By breaking the build process into discrete lifecycle binaries that run in separate containers, the project ensures that failures in one phase (such as a failed “detect" or "build" phase) are isolated and do not impact the stability of the broader orchestration platform. Furthermore, the use of unprivileged Kubernetes primitives in `kpack` enhances the security and resilience of the build environment. + +### **Observability Requirements** + +* **Describe the signals the project is using or producing, including logs, metrics, profiles and traces. Please include supported formats, recommended configurations and data storage.** + * The Cloud Native Buildpacks (CNB) project produces signals primarily through its lifecycle binaries (`prepare`, `analyze`, `detect`, `restore`, `build` or `extender`, and `export`). When integrated into a platform like Tekton, these binaries run in separate containers, which typically output logs to the container runtime. However, the project does not provide specific details regarding supported formats for metrics, profiles, or traces, nor do they specify recommended configurations or data storage for these signals. +* **Describe how the project captures audit logging.** + * N/A +* **Describe any dashboards the project uses or implements as well as any dashboard requirements.** + * N/A +* **Describe how the project surfaces project resource requirements for adopters to monitor cloud and infrastructure costs, e.g. FinOps** + * N/A +* **Which parameters is the project covering to ensure the health of the application/service and its workloads?** + * The project is designed to cover parameters that ensure the health of the application/service and its workloads. In practice, this often relates to the security and compliance of the generated OCI images and the ability to perform upgrades with minimal effort, which maintains the health of the running application over time. +* **How can an operator determine if the project is in use by workloads?** + * An operator can determine if Buildpacks are in use by observing the presence of its orchestration and platform tools within the environment: + * The deployment of `kpack`, which functions as a Kubernetes-native operator to produce and maintain application images. + * The use of the `pack` CLI tool for building images. + * The execution of Tekton tasks that specifically call the individual lifecycle binaries to perform builds. + * Verification of application images to see if they were built using the OCI-compliant standards defined by the Buildpack API and Platform API specifications. +* **How can someone using this project know that it is working for their instance?** + * Success is confirmed when the `pack` CLI tool (or an integrated platform like `kpack`) successfully transforms application source code into a runnable container image that adheres to the project's specifications. +* **Describe the SLOs (Service Level Objectives) for this project.** + * The project does not explicitly define numeric Service Level Objectives (SLOs). As the project focuses on providing specifications and tooling rather than a continuously running hosted service, these metrics are typically defined by the implementing platform (e.g., Google Cloud Run or VMware Tanzu) rather than the core project itself +* **What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?** + * The project does not explicitly define numeric SLIs (Service Level Indicators). As the project focuses on providing specifications and tooling rather than a continuously running hosted service, these metrics are typically defined by the implementing platform (e.g., Google Cloud Run or VMware Tanzu) rather than the core project itself + +### **Dependencies** + +* **Describe the specific running services the project depends on in the cluster.** + * Cloud Native Buildpacks (CNB) do not require a persistent database or similar stateful service within a cluster to function. Instead, the project depends on container orchestration and runtime environments to execute its build lifecycle: + * Orchestration Platforms: The project integrates with Kubernetes for image building and maintenance through `kpack`, which utilizes Kubernetes primitives. It also integrates with Tekton and Knative for CI/CD and function builds. + * Container Runtimes: The project depends on runtimes that support the Open Container Initiative (OCI) image specification, such as containerd and Docker. + * CLI Requirements: The `pack` CLI tool typically targets a Docker daemon by default to execute builds. It can also use Podman as a Docker-compatible target. +* **Describe the project’s dependency lifecycle policy.** + * The project does not explicitly outline a formal "dependency lifecycle policy" document for Buildpacks. However, the project adheres to established cloud-native health and release standards: + * Security Standards: The project has achieved an Open Source Security Foundation (OpenSSF) Best Practices passing badge, which involves maintaining secure dependency practices. + * Release Guidelines: Project components, such as the Pack CLI and lifecycle binaries, follow public release process guidelines (typically found in [RELEASES.md](http://RELEASES.md)) that define expectations for stable versus unstable artifacts. + * External Auditing: The project maintains its software health by undergoing third-party security reviews (such as those by Quarkslab and OSTIF) to identify and resolve vulnerabilities within its stack. +* **How does the project incorporate and consider source composition analysis as part of its development and security hygiene? Describe how this source composition analysis (SCA) is tracked.** + * The project incorporates source composition and security hygiene through rigorous testing and third-party assessments: + * Third-Party Security Reviews: CNB tracks security findings from external audits, such as the review conducted by Quarkslab and OSTIF. These findings are used to improve the project's design and language-specific vulnerability management. + * Automated Verification: The project ensures security hygiene by requiring adequate test coverage on all Pull Requests (PRs). + * Vulnerability Tracking: Moderate and low findings from external security reviews are planned and tracked for resolution as part of the project's internal security roadmap. + * CNCF FOSSA, CNCF Snyk, and Github Dependabot are configured for the project and actively used. +* **Describe how the project implements changes based on source composition analysis (SCA) and the timescale.** + * The project implements changes by translating findings from its security assessments into actionable development tasks: + * Implementation: Findings from SCA and third-party reviews result in updates such as PR review guides tailored to identify memory leaks or vulnerabilities specific to the project's implementation languages. + * Timescale: The project does not specify a fixed numeric timescale (e.g., "within 30 days") for these changes. Instead, they state that findings are tracked for resolution as part of the project's ongoing maintenance and security planning. + +### **Troubleshooting** + +* **How does this project recover if a key component or feature becomes unavailable? e.g Kubernetes API server, etcd, database, leader node, etc.** + * The recovery of Cloud Native Buildpacks (CNB) is inherently tied to the platform or tool used to execute the build lifecycle, as the project itself is a set of specifications and tooling rather than a single monolithic service. + * Kubernetes-Native (`kpack`): Because `kpack` is a platform that uses unprivileged Kubernetes primitives, it relies on the standard Kubernetes reconciliation and self-healing mechanisms. If the `kpack` operator or a build pod fails, Kubernetes is responsible for restarting those components based on the defined state. If the Kubernetes API server itself becomes unavailable, new builds cannot be scheduled or updated until the control plane is restored. + * CLI Tool (`pack`): The `pack` CLI is an ephemeral tool. If the process is interrupted or the tool becomes unavailable (e.g., due to a local crash), recovery is manual; the user simply re-runs the command to start a new build process. + * Lifecycle Binaries: In orchestration systems like Tekton, the build process is broken down into separate containers for each phase (`detect`, `build`, `export`, etc.). Recovery from a container failure is managed by the orchestration platform's task retry logic. + * External Dependencies: The project does not maintain its own internal database or etcd; instead, it depends on external infrastructure such as the Docker daemon or a container registry. Recovery from the unavailability of these services must be handled at the infrastructure level. +* **Describe the known failure modes.** + * Failure modes in Buildpacks typically occur during the specific phases of the image creation lifecycle or due to environment mismatches: + * Detection Failure: This occurs during the detect phase if the provided buildpacks determine they do not know how to handle the source code (e.g., trying to build a Python app with only Java buildpacks). + * Build Transformation Errors: Failures often occur during the build phase due to errors in the application source code, such as compilation failures or missing dependencies required by the buildpack. + * Permission Mismatches: A specific failure mode involves the uid and gid defined in the builder image. If the build environment does not allow the execution of processes with those specific IDs, the build will fail. + * Orchestration/Infrastructure Failure: The primary CLI tool, `pack`, may fail if it cannot communicate with its default target, the Docker daemon. Similarly, Kubernetes-based builds will fail if there are insufficient resources (CPU/Memory) to spin up the required containers for each lifecycle phase. + * Registry Connectivity: The export phase will fail if the system cannot connect to the target OCI registry to upload the final container image. + +### **Compliance** + +* **What steps does the project take to ensure that all third-party code and components have correct and complete attribution and license notices?** + * No formal tool used. Humans (maintainers and code reviewers) perform due diligence as new deps are added. +* **Describe how the project ensures alignment with CNCF [recommendations](https://github.com/cncf/foundation/blob/main/policies-guidance/recommendations-for-attribution.md) for attribution notices.** + * As a CNCF incubating project, CNB follows the foundation's governance and intellectual property guidelines. The project has demonstrated maturity through its progression from Sandbox to Incubation and its current application for Graduation, which requires strict adherence to vendor-neutral governance and standard open-source practices. + * **How are notices managed for third-party code incorporated directly into the project's source files?** + * While the specific internal procedure for file-level notices is not explicitly detailed, the Cloud Native Buildpacks project maintains high-level scrutiny and transparency through a formal Request for Comments (RFC) process. This process is the designated mechanism for proposing and ratifying significant changes to the project's foundation, ensuring that decision-making is community-driven and auditable. + * Proposal and Scope: The RFC process is explicitly required for all changes to the project's charter, governance model, leadership roles, and membership. This ensures that any third-party code incorporated directly into the project's source files has been reviewed at the leadership level. + * Review Mechanism: Committee activities and proposals are tracked publicly as GitHub Issues, Discussions, and project RFCs. This allows the Technical Oversight Committee (TOC)—which is responsible for the project's roadmap and direction—and the broader community to scrutinize proposals before they are enacted. + * Sign-off and Consensus: To ensure efficient but agreed-upon decision-making, the project adheres to a lazy consensus model for voting. This implies that proposals are adopted if no significant objections are raised within a specific timeframe, allowing the project to "sign off" on changes while maintaining a low barrier to progress for non-controversial updates. + * **How are notices retained for unmodified third-party components included within the project's repository?** + * While the project does not specify a technical tool for retention, note that the project follows a publicly available roadmap and a formal RFC (Request for Comments) process for governance changes, ensuring that the community and maintainers can audit how components are managed within the repository. + * **How are notices for all dependencies obtained at build time included in the project's distributed build artifacts (e.g. compiled binaries, container images)?** + * For the `lifecycle` we generate SBOMs using `CycloneDX/gh-gomod-generate-sbom` action. There isn’t anything that pulls notices for any components we use. We also don't distribute any binaries that would require such a notice. + +### **Security** + +* **Security Hygiene** + * **How is the project executing access control?** + * The project enforces Two-Factor Authentication (2FA) and access control for its GitHub organizations ([buildpacks](https://github.com/buildpacks/) and [buildpacks-community](https://github.com/buildpacks-community)) +* **Cloud Native Threat Modeling** + * **How does the project ensure its security reporting and response team is representative of its community diversity (organizational and individual)?** + * A clear process for reporting security issues is maintained through a [SECURITY.md](https://github.com/buildpacks/.github/blob/main/SECURITY.md) file + * **How does the project invite and rotate security reporting team members?** + * The security team attached to [security@buildpacks.io](mailto:security@buildpacks.io) is made up of the members of the TOC. + From 70b71e5e51cb272b586039c646588226ae93553f Mon Sep 17 00:00:00 2001 From: Kevin Dubois Date: Mon, 23 Feb 2026 08:51:12 +0100 Subject: [PATCH 2/3] Rename tech review file to new date format Signed-off-by: Kevin Dubois --- projects/buildpacks/tech-review/{02-20-2026.md => 2026-02-20.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename projects/buildpacks/tech-review/{02-20-2026.md => 2026-02-20.md} (100%) diff --git a/projects/buildpacks/tech-review/02-20-2026.md b/projects/buildpacks/tech-review/2026-02-20.md similarity index 100% rename from projects/buildpacks/tech-review/02-20-2026.md rename to projects/buildpacks/tech-review/2026-02-20.md From a444bec53b26f3d6a0937e817d0194418c0fe4a0 Mon Sep 17 00:00:00 2001 From: Kevin Dubois Date: Tue, 3 Mar 2026 10:00:05 +0100 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: Faseela K Signed-off-by: Kevin Dubois --- projects/buildpacks/tech-review/2026-02-20.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/projects/buildpacks/tech-review/2026-02-20.md b/projects/buildpacks/tech-review/2026-02-20.md index b24de0185..1090c8031 100644 --- a/projects/buildpacks/tech-review/2026-02-20.md +++ b/projects/buildpacks/tech-review/2026-02-20.md @@ -12,7 +12,7 @@ ### **Scope** * **Describe the roadmap process, how scope is determined for mid to long term features, as well as how the roadmap maps back to current contributions and maintainer ladder?** - * The Cloud Native Buildpacks (CNB) project is a community-driven project and maintains a [public roadmap on its GitHub page](https://github.com/buildpacks/community/blob/main/ROADMAP.md), which includes items such as the 2025H1 roadmap proposal. The process for changing the roadmap is documented in the [GOVERNANCE.md](http://GOVERNANCE.md) file located within the buildpacks/community repository. The Technical Oversight Committee (TOC) is explicitly responsible for the direction of the project (roadmap), along with team leadership and cross-cutting concerns. The project also clearly documents its contribution ladder, nomination, and election processes for the TOC, Maintainers, and Contributors in the buildpacks/community repository + * The Cloud Native Buildpacks (CNB) project is a community-driven project and maintains a [public roadmap on its GitHub page](https://github.com/buildpacks/community/blob/main/ROADMAP.md), which includes items such as the 2025H1 roadmap proposal. The process for changing the roadmap is documented in the [GOVERNANCE.md](https://github.com/buildpacks/community/blob/main/GOVERNANCE.md) file located within the buildpacks/community repository. The Technical Oversight Committee (TOC) is explicitly responsible for the direction of the project (roadmap), along with team leadership and cross-cutting concerns. The project also clearly documents its contribution ladder, nomination, and election processes for the TOC, Maintainers, and Contributors in the buildpacks/community repository * **Describe the target persona or user(s) for the project?** * The documentation provides specific categories for target personas, including: * App Developers @@ -179,11 +179,11 @@ * Image Extensions (The Dockerfile "Escape Hatch"). One of CNB's core security features is the elimination of arbitrary Dockerfile commands. However, the project acknowledges that some users need system-level packages (e.g., `libpq-dev`) that buildpacks don't provide. * Mechanism: Providing a `build.Dockerfile` or `run.Dockerfile` within the project. * Effect: This triggers the "Extender" phase, which the project explicitly states typically runs as root to execute instructions like `apt-get install`. This is a significant departure from the standard non-privileged build model. - * Documentation: [Image Extensions Concept](https://www.google.com/search?q=https://buildpacks.io/docs/concepts/components/image-extension/) + * Documentation: [Image Extensions Concept](https://buildpacks.io/docs/for-platform-operators/concepts/extension/) * Bypassing the Launcher (Loosening Runtime Environment). The CNB launcher is responsible for setting up the secure execution environment, including environment variable isolation and process management. Users can "loosen" this control to get a "raw" container experience. * Mechanism: Overriding the image entrypoint (e.g., `docker run --entrypoint bash` ...). * Effect: This bypasses the launcher entirely. The project notes that in this mode, "profile scripts have NOT been sourced and buildpack-provided environment variables are NOT set." - * Documentation: [Running the Application (No Launcher)](https://www.google.com/search?q=https://buildpacks.io/docs/app-developer-guide/run-an-app/%23no-launcher) + * Documentation: [Running the Application (No Launcher)](https://buildpacks.io/docs/for-app-developers/how-to/build-outputs/specify-launch-process/) * Experimental Features Flag. Many of the features that allow for "loosened" security or experimental flexibility are gated behind a global configuration flag to prevent accidental use in production. * Mechanism: Running `pack config experimental true`. * Effect: Unlocks capabilities like non-standard build behaviors. @@ -270,7 +270,7 @@ * The project utilizes multiple public channels to communicate changes: * Slack: Announcements are made in the [\#buildpacks-announcements](https://cloud-native.slack.com/archives/C0333LFUBGU) channel. * GitHub: Detailed changelogs and release histories are maintained for every project component, such as the Pack CLI and the Buildpacks Specifications, within GitHub Releases. - * Documentation: The project follows a public release process and guidelines document ([RELEASES.md](http://RELEASES.md)) that defines expectations for stable and unstable releases. + * Documentation: The project follows a public release process and guidelines document ([RELEASES.md](https://github.com/buildpacks/community/blob/main/RELEASES.md)) that defines expectations for stable and unstable releases. * **Explain how the project permits utilization of alpha and beta capabilities as part of a rollout.** * The project manages the rollout of new capabilities through its tagging and release strategy: * Release Tagging: Releases are explicitly tagged as stable or unstable, allowing users to opt into experimental features by selecting unstable artifacts. @@ -332,7 +332,7 @@ * **Describe the project’s dependency lifecycle policy.** * The project does not explicitly outline a formal "dependency lifecycle policy" document for Buildpacks. However, the project adheres to established cloud-native health and release standards: * Security Standards: The project has achieved an Open Source Security Foundation (OpenSSF) Best Practices passing badge, which involves maintaining secure dependency practices. - * Release Guidelines: Project components, such as the Pack CLI and lifecycle binaries, follow public release process guidelines (typically found in [RELEASES.md](http://RELEASES.md)) that define expectations for stable versus unstable artifacts. + * Release Guidelines: Project components, such as the Pack CLI and lifecycle binaries, follow public release process guidelines (typically found in [RELEASES.md](https://github.com/buildpacks/community/blob/main/RELEASES.md)) that define expectations for stable versus unstable artifacts. * External Auditing: The project maintains its software health by undergoing third-party security reviews (such as those by Quarkslab and OSTIF) to identify and resolve vulnerabilities within its stack. * **How does the project incorporate and consider source composition analysis as part of its development and security hygiene? Describe how this source composition analysis (SCA) is tracked.** * The project incorporates source composition and security hygiene through rigorous testing and third-party assessments: