|
| 1 | +# Skopeo 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/skopeo](https://github.com/containers/skopeo) | | Security Provider | No | | Languages | Go | | SBOM | [https://github.com/containers/skopeo/blob/main/go.mod](https://github.com/containers/skopeo/blob/main/go.mod) | |
| 23 | + |
| 24 | +### Security links |
| 25 | + |
| 26 | +| Doc | url | |
| 27 | +| :---- | :---- | |
| 28 | +| Security file | [https://github.com/containers/skopeo/blob/main/SECURITY.md](https://github.com/containers/skopeo/blob/main/SECURITY.md) | |
| 29 | + |
| 30 | +## Overview |
| 31 | + |
| 32 | +Skopeo is a command-line utility that performs various operations on container images and image repositories. It provides tools for inspecting, copying, signing, and managing container images across different registries without requiring a container runtime or daemon. |
| 33 | + |
| 34 | +### Background |
| 35 | + |
| 36 | +Skopeo is a tool designed for working with remote container images and registries. Unlike traditional container tools, Skopeo operates without requiring a local container runtime, making it ideal for CI/CD pipelines and automated image management tasks. |
| 37 | + |
| 38 | +Key characteristics: |
| 39 | + |
| 40 | +- **Daemonless**: Operates without a container runtime or daemon |
| 41 | +- **Registry operations**: Direct interaction with container registries |
| 42 | +- **Image inspection**: Inspect images without downloading them |
| 43 | +- **Image copying**: Copy images between registries efficiently |
| 44 | +- **Image signing**: Support for signing and verifying image signatures |
| 45 | +- **OCI-compliant**: Fully compatible with OCI standards |
| 46 | +- **Multi-architecture**: Support for multi-architecture images |
| 47 | + |
| 48 | +Skopeo is part of the containers ecosystem and integrates with other tools like Podman, Buildah, and CRI-O.``` |
| 49 | + |
| 50 | +### Actors |
| 51 | + |
| 52 | +* **Skopeo CLI**: The main command-line interface that users interact with for image operations. |
| 53 | + |
| 54 | +* **Registry client**: Handles communication with container registries (Docker Hub, Quay.io, etc.). |
| 55 | + |
| 56 | +* **Image store**: Manages local image storage when needed for operations. |
| 57 | + |
| 58 | +* **Signature store**: Handles image signature storage and verification. |
| 59 | + |
| 60 | +* **Credential manager**: Securely manages registry authentication credentials. |
| 61 | + |
| 62 | +### Actions |
| 63 | + |
| 64 | +* **Image inspection**: |
| 65 | + |
| 66 | + - Retrieves image metadata from registries |
| 67 | + - Inspects image configuration and layers |
| 68 | + - Examines image manifests without downloading |
| 69 | + - Verifies image integrity |
| 70 | + |
| 71 | + |
| 72 | +* **Image copying**: |
| 73 | + |
| 74 | + - Copies images between registries |
| 75 | + - Handles multi-architecture images |
| 76 | + - Preserves image signatures during copy |
| 77 | + - Supports efficient layer transfer |
| 78 | + |
| 79 | + |
| 80 | +* **Image signing and verification**: |
| 81 | + |
| 82 | + - Signs container images with GPG keys |
| 83 | + - Verifies image signatures |
| 84 | + - Manages signature policies |
| 85 | + - Ensures image authenticity |
| 86 | + |
| 87 | + |
| 88 | +* **Image deletion**: |
| 89 | + |
| 90 | + - Removes images from registries |
| 91 | + - Handles cleanup operations |
| 92 | + - Respects registry policies |
| 93 | + |
| 94 | + |
| 95 | +* **Credential management**: |
| 96 | + |
| 97 | + - Securely stores and retrieves registry credentials |
| 98 | + - Supports multiple authentication methods |
| 99 | + - Integrates with credential helpers |
| 100 | + |
| 101 | +### Goals |
| 102 | + |
| 103 | +* **Registry operations without runtime**: Enable users to work with container images without requiring a container runtime or daemon. |
| 104 | + |
| 105 | +* **Secure image management**: Provide secure tools for inspecting, copying, and signing container images. |
| 106 | + |
| 107 | +* **Efficient operations**: Optimize image operations for speed and efficiency, especially in CI/CD environments. |
| 108 | + |
| 109 | +* **OCI compliance**: Maintain full compatibility with OCI specifications for container images. |
| 110 | + |
| 111 | +* **Multi-registry support**: Work seamlessly with various container registries. |
| 112 | + |
| 113 | +* **Image verification**: Provide robust tools for verifying image authenticity and integrity. |
| 114 | + |
| 115 | +### Non-goals |
| 116 | + |
| 117 | +* **Container runtime**: Skopeo does not run containers (that's handled by Podman, Docker, etc.). |
| 118 | + |
| 119 | +* **Image building**: Skopeo does not build container images (that's handled by container engines such as Podman, Docker, Buildah, etc.). |
| 120 | + |
| 121 | +* **Container orchestration**: Skopeo does not provide cluster orchestration capabilities. |
| 122 | + |
| 123 | +* **Registry hosting**: Skopeo does not operate as a container registry, though it interacts with them. |
| 124 | + |
| 125 | +## Self-assessment use |
| 126 | + |
| 127 | +This self-assessment is created by the Skopeo team to perform an internal analysis of the project's security. It is not intended to provide a security audit of Skopeo, or function as an independent assessment or attestation of Skopeo's security health. |
| 128 | + |
| 129 | +This document serves to provide Skopeo users with an initial understanding of Skopeo's security, where to find existing security documentation, Skopeo plans for security, and general overview of Skopeo security practices, both for development of Skopeo as well as security of Skopeo. |
| 130 | + |
| 131 | +This document provides the CNCF TAG-Security with an initial understanding of Skopeo 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 Skopeo seeks graduation and is preparing for a security audit. |
| 132 | + |
| 133 | +## Security functions and features |
| 134 | + |
| 135 | +### Critical Security Components |
| 136 | + |
| 137 | +* **Signature verification**: Skopeo's core security feature that verifies container image signatures to ensure authenticity and integrity. |
| 138 | + |
| 139 | +* **Secure registry communication**: All communication with registries uses secure protocols (HTTPS, TLS). |
| 140 | + |
| 141 | +* **Credential protection**: Secure handling and storage of registry credentials. |
| 142 | + |
| 143 | +* **Image inspection without download**: Ability to inspect images without downloading them, reducing exposure to potentially malicious content. |
| 144 | + |
| 145 | +* **No daemon dependency**: Eliminates daemon-related security risks by operating as a standalone tool. |
| 146 | + |
| 147 | +### Security Relevant Components |
| 148 | + |
| 149 | +* **Sigstore integration**: Support for sigstore-based image signing and verification. |
| 150 | + |
| 151 | +* **Policy enforcement**: Configurable policies for image acceptance and verification. |
| 152 | + |
| 153 | +* **Multi-registry security**: Secure handling of credentials across multiple registries. |
| 154 | + |
| 155 | +* **Audit logging**: Logging of security-relevant operations. |
| 156 | + |
| 157 | +## Project compliance |
| 158 | + |
| 159 | +* **OCI Compliance**: Skopeo is fully compliant with the Open Container Initiative (OCI) specifications for container images. |
| 160 | + |
| 161 | +* **OpenSSF Best Practices**: Skopeo has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10516), demonstrating adherence to security best practices. |
| 162 | + |
| 163 | +* **Image signing standards**: Supports standard image signing mechanisms including Sigstore. |
| 164 | + |
| 165 | +## Secure development practices |
| 166 | + |
| 167 | +### Development Pipeline |
| 168 | + |
| 169 | +* **Code Review Process**: All code changes require review by at least one maintainer before merging. The project uses GitHub pull requests for all contributions. |
| 170 | + |
| 171 | +* **Automated Testing**: Comprehensive test suite including unit tests, integration tests, and system tests that run on every pull request. |
| 172 | + |
| 173 | +* **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. |
| 174 | + |
| 175 | +* **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. |
| 176 | + |
| 177 | +* **Dynamic Analysis**: Comprehensive test suite is run in CI on every PR and also on a nightly basis, testing the skopeo binary compiled using the PR's source code and the latest HEAD commit respectively. |
| 178 | + |
| 179 | +* **OpenSSF Best Practices Compliance**: Skopeo has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10516), demonstrating adherence to security best practices including proper licensing, contribution guidelines, and security processes. |
| 180 | + |
| 181 | +### Communication Channels |
| 182 | + |
| 183 | +* Podman user room: [\#podman:fedoraproject.org](https://matrix.to/#/#podman:fedoraproject.org) |
| 184 | + |
| 185 | +* Podman dev room: [\#podman-dev:matrix.org](https://matrix.to/#/#podman-dev:matrix.org) |
| 186 | + |
| 187 | +* **Inbound**: |
| 188 | + |
| 189 | + - GitHub Issues for bug reports and feature requests |
| 190 | + - GitHub Discussions for community questions |
| 191 | + |
| 192 | + - Mailing lists for formal discussions |
| 193 | + - Clear contribution guidelines documented in [CONTRIBUTING.md](https://github.com/containers/skopeo/blob/main/CONTRIBUTING.md) |
| 194 | + |
| 195 | + |
| 196 | +* **Outbound**: |
| 197 | + |
| 198 | + - Release announcements via GitHub releases |
| 199 | + - 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) |
| 200 | + - Documentation updates and blog posts |
| 201 | + |
| 202 | +### Ecosystem |
| 203 | + |
| 204 | +Skopeo is a critical component of the cloud-native ecosystem: |
| 205 | + |
| 206 | +* **CI/CD Pipelines**: Widely used in CI/CD systems for copying, inspecting, and verifying container images. |
| 207 | + |
| 208 | +* **Registry Management**: Used by registry operators and administrators for managing container images across multiple registries. |
| 209 | + |
| 210 | +* **Security Tools**: Integrated into security scanning and compliance tools for image verification. |
| 211 | + |
| 212 | +## Security issue resolution |
| 213 | + |
| 214 | +### Responsible Disclosures Process |
| 215 | + |
| 216 | +* **Reporting**: Security vulnerabilities should be reported by email as documented in the [SECURITY.md](https://github.com/containers/skopeo/blob/main/SECURITY.md) file. |
| 217 | + |
| 218 | +* **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. |
| 219 | + |
| 220 | +* **Coordination**: For critical vulnerabilities, Red Hat Product Security coordinates with downstream projects and maintainers to ensure coordinated disclosure. |
| 221 | + |
| 222 | +* **Credit**: Security researchers who responsibly disclose vulnerabilities are credited in security advisories and release notes. |
| 223 | + |
| 224 | +* **Public Disclosure**: Vulnerabilities are disclosed by Red Hat Product Security with appropriate embargo periods for critical issues, following industry best practices for responsible disclosure. |
| 225 | + |
| 226 | +### Vulnerability Response Process |
| 227 | + |
| 228 | +* **Triage**: Security reports are triaged by the security team and assigned severity levels (Critical, High, Medium, Low) using CVSS scoring where applicable. |
| 229 | + |
| 230 | +* **Investigation**: The Red Hat Product Security team investigates the vulnerability, determines impact, and works with upstream to develop fixes. All medium and higher severity exploitable vulnerabilities discovered are fixed in a timely way after they are confirmed. |
| 231 | + |
| 232 | +* **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. |
| 233 | + |
| 234 | +* **Disclosure**: The project discloses vulnerabilities through security advisories at [https://access.redhat.com](https://access.redhat.com) and Bugzilla trackers for Fedora and RHEL on [bugzilla.redhat.com](http://bugzilla.redhat.com) |
| 235 | + |
| 236 | +### Incident Response |
| 237 | + |
| 238 | +* **Detection**: Security incidents in dependencies are detected and updated by tools like Renovate. Security issues are accepted through the Podman security mailing list. |
| 239 | + |
| 240 | +* **Assessment**: The team assesses the severity and impact of security incidents using CVSS scoring and industry-standard severity classification. |
| 241 | + |
| 242 | +* **Containment**: Immediate steps are taken to contain and mitigate the impact of security incidents. If tests point out any issues in the development phase, those get fixed before any code is merged. |
| 243 | + |
| 244 | +* **Communication**: Affected users are notified through security advisories and release notes. |
| 245 | + |
| 246 | + |
| 247 | +## Appendix |
| 248 | + |
| 249 | +### OpenSSF Best Practices |
| 250 | + |
| 251 | +* **Current Status**: Skopeo has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10516) (100% compliance), demonstrating adherence to security best practices. |
| 252 | + |
| 253 | +* **Key Achievements**: |
| 254 | + |
| 255 | + - Comprehensive project documentation and contribution guidelines |
| 256 | + - Robust security testing and analysis processes |
| 257 | + - Clear vulnerability disclosure and response procedures |
| 258 | + - Strong development practices with code review and automated testing |
| 259 | + - Proper licensing and project governance |
| 260 | + |
| 261 | + |
| 262 | +### Case Studies |
| 263 | + |
| 264 | +TBD. |
| 265 | + |
| 266 | +### Related Projects / Vendors |
| 267 | + |
| 268 | +* **Buildah**: A tool that facitiliates building OCI container images. |
| 269 | + |
| 270 | +* **Podman:** A command line utility for managing OCI containers and pods. |
0 commit comments