Skip to content

Commit ebdfee5

Browse files
lsm5flouthocTomSweeneyRedHat
committed
cncf: self-assessment doc
This is being added here only for review. This doc will live in https://github.com/cncf/tag-security and *probably* be removed from here. Co-authored-by: flouthoc <[email protected]> Co-authored-by: Tom Sweeney <[email protected]> Signed-off-by: Lokesh Mandvekar <[email protected]>
1 parent e0e108c commit ebdfee5

File tree

1 file changed

+280
-0
lines changed

1 file changed

+280
-0
lines changed

docs/cncf/self-assessment.md

Lines changed: 280 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,280 @@
1+
# Buildah Self-assessment
2+
3+
## Table of contents
4+
5+
* [Metadata](#metadata)
6+
* [Security links](#security-links)
7+
* [Overview](#overview)
8+
* [Actors](#actors)
9+
* [Actions](#actions)
10+
* [Background](#background)
11+
* [Goals](#goals)
12+
* [Non-goals](#non-goals)
13+
* [Self-assessment use](#self-assessment-use)
14+
* [Security functions and features](#security-functions-and-features)
15+
* [Project compliance](#project-compliance)
16+
* [Secure development practices](#secure-development-practices)
17+
* [Security issue resolution](#security-issue-resolution)
18+
* [Appendix](#appendix)
19+
20+
## Metadata
21+
22+
|||| | \-- | \-- | | Assessment Stage | Incomplete | | Software | [https://github.com/containers/buildah](https://github.com/containers/buildah) | | Security Provider | No | | Languages | Go | | SBOM | [https://github.com/containers/buildah/blob/main/go.mod](https://github.com/containers/buildah/blob/main/go.mod) |
23+
24+
### Security links
25+
26+
| Doc | url |
27+
| :---- | :---- |
28+
| Security file | [https://github.com/containers/buildah/blob/main/SECURITY.md](https://github.com/containers/buildah/blob/main/SECURITY.md) |
29+
30+
## Overview
31+
32+
Buildah is a tool that facilitates building Open Container Initiative (OCI) images. It provides a flexible and efficient way to create container images without requiring a running container daemon, emphasizing security through rootless builds and fine-grained control over the image creation process.
33+
34+
### Background
35+
36+
Buildah is a command-line tool designed for building OCI-compliant container images. Unlike traditional container build tools that require a daemon, Buildah operates directly as a command-line application, providing better security and flexibility.
37+
38+
Key characteristics:
39+
40+
- **Daemonless**: No background daemon process required for building images
41+
- **Rootless builds**: Supports building images without root privileges
42+
- **OCI-compliant**: Fully compliant with OCI image specifications
43+
- **Dockerfile compatibility**: Can build images from Dockerfiles/Containerfiles
44+
- **Fine-grained control**: Provides detailed control over the build process
45+
46+
Buildah is part of the containers ecosystem and integrates with other tools like Podman, Skopeo, and CRI-O.
47+
48+
### Actors
49+
50+
* **Buildah CLI**: The main command-line interface that users interact with for building container images.
51+
52+
* **Build context**: The filesystem context containing source code and build instructions.
53+
54+
* **OCI runtime**: Interfaces with OCI-compliant runtimes (runc, crun) to execute build commands when needed.
55+
56+
* **Image store**: Manages container images and their layers during the build process.
57+
58+
* **Registry client**: Handles interactions with container registries for pulling base images and pushing built images.
59+
60+
* **Storage backend**: Manages container storage layers and filesystems during the build process.
61+
62+
### Actions
63+
64+
* **Image building**:
65+
66+
- Parses Dockerfile/Containerfile or receives direct build commands
67+
- Pulls base images from container registries
68+
- Executes build steps in isolated environments
69+
- Creates image layers and metadata
70+
- Applies security policies during build
71+
72+
73+
* **Container creation**:
74+
75+
- Creates working containers for build operations
76+
- Sets up namespaces and cgroups for isolation
77+
- Configures security policies for build containers
78+
79+
80+
* **Layer management**:
81+
82+
- Creates and manages image layers
83+
- Optimizes layer size and composition
84+
- Handles layer caching for efficiency
85+
86+
87+
* **Image inspection**:
88+
89+
- Provides detailed information about images
90+
- Verifies image metadata and configuration
91+
- Checks security attributes
92+
93+
94+
* **Image publishing**:
95+
96+
- Allows users to push built images to registries
97+
- Handles authentication with registries
98+
- Supports image signing
99+
100+
### Goals
101+
102+
* **Rootless image building**: Enable users to build container images without root privileges, reducing security risks.
103+
104+
* **Daemonless operation**: Eliminate the need for a daemon process, reducing attack surface and improving security.
105+
106+
* **OCI compliance**: Maintain full compatibility with OCI specifications for container images.
107+
108+
* **Dockerfile compatibility**: Support standard Dockerfiles/Containerfiles while providing enhanced security features.
109+
110+
* **Flexible build process**: Provide fine-grained control over the image building process.
111+
112+
* **Integration**: Work seamlessly with other container tools in the ecosystem.
113+
114+
### Non-goals
115+
116+
* **Container orchestration**: Buildah does not provide cluster orchestration capabilities.
117+
118+
* **Image registry**: Buildah does not operate as a container registry, though it interacts with them.
119+
120+
* **Continuous integration platform**: While used in CI/CD, Buildah itself is not a CI/CD platform.
121+
122+
## Self-assessment use
123+
124+
This self-assessment is created by the Buildah team to perform an internal analysis of the project's security. It is not intended to provide a security audit of Buildah, or function as an independent assessment or attestation of Buildah's security health.
125+
126+
This document serves to provide Buildah users with an initial understanding of Buildah's security, where to find existing security documentation, Buildah plans for security, and general overview of Buildah security practices, both for development of Buildah as well as security of Buildah.
127+
128+
This document provides the CNCF TAG-Security with an initial understanding of Buildah to assist in a joint-assessment, necessary for projects under incubation. Taken together, this document and the joint-assessment serve as a cornerstone for if and when Buildah seeks graduation and is preparing for a security audit.
129+
130+
## Security functions and features
131+
132+
### Critical Security Components
133+
134+
* **Rootless builds**: Buildah's core security feature that allows building images without root privileges, significantly reducing the attack surface.
135+
136+
* **User namespaces**: Provides process isolation during builds by mapping container user IDs to host user IDs.
137+
138+
* **Build isolation**: Each build operation is isolated from the host system and other builds.
139+
140+
* **Daemonless architecture**: Eliminates the daemon process, reducing potential attack vectors.
141+
142+
* **Security policy enforcement**: Applies seccomp, SELinux, and capabilities restrictions during builds.
143+
144+
### Security Relevant Components
145+
146+
* **Image verification**: Support for verifying container image signatures before using them as base images.
147+
148+
* **Secure defaults**: Provides secure defaults for build operations.
149+
150+
* **Credential management**: Secure handling of registry credentials during image operations.
151+
152+
* **Layer security**: Proper handling and isolation of image layers during builds.
153+
154+
* **Mount security**: Secure mounting of volumes and filesystems during build operations.
155+
156+
## Project compliance
157+
158+
* **OCI Compliance**: Buildah is fully compliant with the Open Container Initiative (OCI) specifications for container images.
159+
160+
* **OpenSSF Best Practices**: Buildah has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10579), demonstrating adherence to security best practices.
161+
162+
* **SELinux**: Full integration with SELinux for mandatory access control during builds.
163+
164+
* **AppArmor**: Support for AppArmor profiles for additional access control.
165+
166+
## Secure development practices
167+
168+
### Development Pipeline
169+
170+
* **Code Review Process**: All code changes require review by at least one maintainer before merging. The project uses GitHub pull requests for all contributions.
171+
172+
* **Automated Testing**: Comprehensive integration test suite is run in CI on every PR and also on a nightly basis. These tests exercise the buildah binary compiled using the PR's source code and the latest HEAD commit respectively.
173+
174+
* **Security Scanning**: Automated vulnerability scanning of dependencies using tools like Dependabot and GitHub Security Advisories. All medium and higher severity exploitable vulnerabilities are fixed in a timely way after they are confirmed.
175+
176+
* **Static Analysis**: Code quality and security analysis using golangci-lint which is run on every PR, ensuring testing is done prior to merge. The tool includes rules to look for common vulnerabilities in Go code.
177+
178+
* **Dynamic Analysis**: Comprehensive integration test suite is run in CI on every PR and also on a nightly basis. If the integration tests point out any issues in the development phase itself, those get fixed before any code is merged.
179+
180+
* **Container Image Security**: Built images follow security best practices and are regularly updated for security patches.
181+
182+
* **OpenSSF Best Practices Compliance**: Buildah has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10579), demonstrating adherence to security best practices including proper licensing, contribution guidelines, and security processes.
183+
184+
### Communication Channels
185+
186+
* Podman user room: [\#podman:fedoraproject.org](https://matrix.to/#/#podman:fedoraproject.org)
187+
188+
* Podman dev room: [\#podman-dev:matrix.org](https://matrix.to/#/#podman-dev:matrix.org)
189+
190+
* **Inbound**:
191+
192+
- GitHub Issues for bug reports and feature requests
193+
- GitHub Discussions for community questions
194+
- Security issues via the security mailing list
195+
- Mailing lists for formal discussions
196+
- Clear contribution guidelines documented in [CONTRIBUTING.md](https://github.com/containers/buildah/blob/main/CONTRIBUTING.md)
197+
198+
199+
* **Outbound**:
200+
201+
- Release announcements via GitHub releases (and [buildah.io](http://buildah.io) for major and minor version bumps)
202+
- Security advisories through [https://access.redhat.com](https://access.redhat.com) and Bugzilla trackers for Fedora and RHEL on [bugzilla.redhat.com](http://bugzilla.redhat.com) .
203+
- Documentation updates and blog posts
204+
- Conference presentations and talks
205+
- Project website at [buildah.io](https://buildah.io) with comprehensive documentation
206+
207+
### Ecosystem
208+
209+
Buildah is a critical component of the cloud-native ecosystem:
210+
211+
* **OpenShift**: Buildah is integrated into Red Hat OpenShift for secure image building workflows.
212+
213+
* **Container Ecosystem**: Integrates with Podman for running containers, Skopeo for image operations, and CRI-O for Kubernetes runtime.
214+
215+
* **Development Tools**: Widely used in development environments for building container images securely.
216+
217+
* **CI/CD Pipelines**: Used in many CI/CD systems for building containerized applications with enhanced security.
218+
219+
## Security issue resolution
220+
221+
### Responsible Disclosures Process
222+
223+
* **Reporting**: Security vulnerabilities should be reported by email as documented in the [SECURITY.md](https://github.com/containers/buildah/blob/main/SECURITY.md) file.
224+
225+
* **Response Time**: The team commits to responding to vulnerability reports within 48 hours. All medium and higher severity exploitable vulnerabilities are prioritized as a matter of general practice.
226+
227+
* **Credit**: Security researchers who responsibly disclose vulnerabilities are credited in security advisories and release notes.
228+
229+
* **Public Disclosure**: Vulnerabilities are disclosed by the project maintainers with appropriate embargo periods for critical issues, following industry best practices for responsible disclosure.
230+
231+
### Vulnerability Response Process
232+
233+
* **Triage**: Security reports are triaged by the security team and assigned severity levels (Critical, High, Medium, Low) using CVSS scoring where applicable.
234+
235+
* **Investigation**: The team investigates the vulnerability, determines impact, and develops fixes. All medium and higher severity exploitable vulnerabilities discovered through static or dynamic analysis are fixed in a timely way after they are confirmed.
236+
237+
* **Fix Development**: Security fixes are developed in private repositories to prevent premature disclosure. The project maintains a clear process for developing and testing security patches.
238+
239+
* **Disclosure**: Vulnerabilities are disclosed by the team with appropriate embargo periods for critical issues. The project follows industry best practices for coordinated vulnerability disclosure.
240+
241+
242+
### Incident Response
243+
244+
* **Detection**: Security incidents are detected through automated monitoring, user reports, security research, and the comprehensive testing suite that runs on every PR and nightly.
245+
246+
* **Assessment**: The team assesses the severity and impact of security incidents using CVSS scoring and industry-standard severity classification.
247+
248+
* **Containment**: Immediate steps are taken to contain and mitigate the impact of security incidents. If the integration tests point out any issues in the development phase, those get fixed before any code is merged.
249+
250+
* **Communication**: Affected users are notified through security advisories and release notes. The project maintains clear communication channels for security updates.
251+
252+
* **Recovery**: Patches and updates are released as quickly as possible to address security issues. All medium and high severity vulnerabilities are prioritized as a matter of general practice.
253+
254+
* **Post-Incident Review**: The team conducts post-incident reviews to identify improvements to the security process and prevent similar issues in the future.
255+
256+
## Appendix
257+
258+
### Known Issues Over Time
259+
260+
* **Security Advisories**: See [this NVD list](https://nvd.nist.gov/vuln/search#/nvd/home?vulnRevisionStatusList=published&keyword=buildah&resultType=records) for CVEs to date.
261+
262+
* **Code Review**: The project's code review process has caught numerous potential security issues before they reach production.
263+
264+
### OpenSSF Best Practices
265+
266+
* **Current Status**: Buildah has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10579) (100% compliance), demonstrating adherence to security best practices.
267+
268+
* **Key Achievements**:
269+
270+
- Comprehensive project documentation and contribution guidelines
271+
- Robust security testing and analysis processes
272+
- Clear vulnerability disclosure and response procedures
273+
- Strong development practices with code review and automated testing
274+
- Proper licensing and project governance
275+
276+
### Related Projects / Vendors
277+
278+
* **Skopeo**: A command line utility to perform various operations on container images and image repositories like copying an image, inspecting a remote image, deleting an image from an image repository.
279+
280+
* **Podman:** A command line utility for managing OCI containers and pods.

0 commit comments

Comments
 (0)