diff --git a/README.md b/README.md index c9713d24c..9814fe679 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,6 @@ - [Meeting Information](#meeting-information) - [Slack Information](#communications) -- [Members](#members) - [Working Groups](#working-groups) ## About Us @@ -56,6 +55,7 @@ Join our open discussions and share news: - **Americas**: Weekly on Wednesdays at 10 am (UTC-7). [Zoom link](https://zoom-lfx.platform.linuxfoundation.org/meeting/92340369657?password=76e24ffd-69f2-41a8-8aed-13796805225d), Meeting ID: 923 4036 9657. - **EMEA**: Bi-weekly on Wednesdays at 1 pm UTC+0 (adjusts for daylight saving). [Zoom link](https://zoom-lfx.platform.linuxfoundation.org/meeting/98348738138?password=70e6a945-563a-491f-8485-ecf7394ec13a), Meeting ID: 983 4873 8138. +- **APAC**: Bi-weekly on Wednesdays at 11 am (UTC+9). [Zoom link](https://zoom-lfx.platform.linuxfoundation.org/meeting/94315508827?password=0d7eaab8-a217-4c1b-b0a5-27ceded5743f), Meeting ID: 943 1550 8827. Check your local timezone [here](https://time.is/). Meetings are listed on the [CNCF calendar](https://www.cncf.io/calendar/) and the [TAG Security Calendar](https://calendar.google.com/calendar/u/0?cid=MGI4dTVlbDh0YTRzOTN0MmNtNzJ0dXZoaGtAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ). @@ -70,10 +70,6 @@ If you are new to the group, we encourage you to check out our Explore groups affiliated with or relevant to Security TAG [here](governance/related-groups/README.md) -## Members - - - ## Leadership Details about the TAG Chairs, Tech Leads, and TOC Liaisons can be found on the [CNCF Technical Advisory Groups (TAGs) information page](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md) @@ -88,14 +84,15 @@ The TAG's working groups focus on specific areas and organize most community act These groups facilitate discussions, engagement, and publications with key stakeholders, operating differently based on their needs. Each group, led by a responsible leader, reaches consensus on issues and manages logistics. All materials, such as reports, white papers, documents, and reference architectures, are in the repository's /community directory. -| Project | Leads | -|---------------------------------|---------------------------------------------| -| [Automated Governance](/community/working-groups/automated-governance/README.md) | Matthew Flannery, Brandt Keller | -| [Catalog of Supply Chain Compromises](/community/catalog/README.md) | Santiago Arias Torres | -| [Compliance](/community/working-groups/compliance/README.md) | Anca Sailer, Robert Ficcaglia | -| [Controls](/community/working-groups/controls/README.md) | Jon Zeolla | -| [Security Reviews](/community/assessments/README.md) | Justin Cappos, Eddie Knight| -| [Software Supply Chain](/community/working-groups/supply-chain-security/README.md) | Marina Moore, Michael Liebermann, John Kjell | +| Project | Leads | STAG Rep | +|---------------------------------|---------------------------------------------|---------------------------------| +| [Automated Governance](/community/working-groups/automated-governance/README.md) | Brandt Keller | Matthew Flannery | +| [Catalog of Supply Chain Compromises](/community/catalog/README.md) | Santiago Arias Torres | Marina Moore | +| [Commons](/community/working-groups/commons/README.md) | Eddie Knight | Marco De Benedictis | +| [Compliance](/community/working-groups/compliance/README.md) | Anca Sailer, Robert Ficcaglia | Brandt Keller | +| [Controls](/community/working-groups/controls/README.md) | Jon Zeolla | Brandt Keller | +| [Security Reviews](/community/assessments/README.md) | Justin Cappos | Eddie Knight | +| [Software Supply Chain](/community/working-groups/supply-chain-security/README.md) | Michael Lieberman, John Kjell | Marina Moore | ## Additional information diff --git a/ci/links.sh b/ci/links.sh index ddbbad598..f2bc25bff 100755 --- a/ci/links.sh +++ b/ci/links.sh @@ -6,7 +6,7 @@ shopt -s globstar FAILURE=0 git config --global --add safe.directory /usr/src/app -npm install -g markdown-link-check +npm install -g markdown-link-check@3.12.2 git fetch origin main:main # To run this on the entire repo, replace the following command with `$(find ./ -type f | grep .md)` for file_name in $(git diff --name-only $HEAD main -- ./**/*.md); do diff --git a/ci/lint-config.json b/ci/lint-config.json index 513645b46..530ee6550 100644 --- a/ci/lint-config.json +++ b/ci/lint-config.json @@ -4,5 +4,8 @@ "code_blocks": false, "tables": false, "line_length": 512 + }, + "MD024": { + "siblings_only": true } } diff --git a/ci/spelling-config.json b/ci/spelling-config.json index 2d2989db1..8744fc9bc 100644 --- a/ci/spelling-config.json +++ b/ci/spelling-config.json @@ -8,6 +8,8 @@ "words": [ "ABAC", "addfetnetgrent", + "AEST", + "Anca", "Aniszczyk", "antifragile", "APAC", @@ -24,6 +26,7 @@ "cisecurity", "CISO", "cloudcustodian", + "CLOMonitor", "CMMC", "CNCF", "CNSC", @@ -55,7 +58,9 @@ "exploitability", "Expressibility", "Fianu", + "Ficcaglia", "FIPS", + "Flannery", "Flibble", "frontmatter", "Gamal", @@ -65,8 +70,8 @@ "GUAC", "helm", "HIPAA", - "HITRUST", "Hirschberg", + "HITRUST", "hotspots", "hyperconverged", "Inclusivity", @@ -79,6 +84,7 @@ "kata", "KETRMAX", "keycloak", + "Kjell", "Kube", "kubecon", "Kubernetes", @@ -174,6 +180,7 @@ "Virtool", "Wolt", "Yubi", - "Zalman" + "Zalman", + "Zeolla" ] } diff --git a/community/assessments/projects/containerd/self-assessment.md b/community/assessments/projects/containerd/self-assessment.md new file mode 100644 index 000000000..d229961f5 --- /dev/null +++ b/community/assessments/projects/containerd/self-assessment.md @@ -0,0 +1,329 @@ +# Containerd Self-assessment + +This assessment was created by community members as part of the [Security Pals](https://github.com/cncf/tag-security/issues/1102) process and is currently pending changes from the maintainer team. + +## Table of contents + +* [Metadata](#metadata) + * [Security links](#security-links) +* [Overview](#overview) + * [Actors](#actors) + * [Actions](#actions) + * [Background](#background) + * [Goals](#goals) + * [Non-goals](#non-goals) +* [Self-assessment use](#self-assessment-use) +* [Security functions and features](#security-functions-and-features) +* [Project compliance](#project-compliance) +* [Secure development practices](#secure-development-practices) +* [Security issue resolution](#security-issue-resolution) +* [Appendix](#appendix) + +## Metadata + + +| | | +| -- | -- | +| Assessment Stage | Incomplete | +| Software | [containerd](https://github.com/containerd/containerd) | +| Security Provider | No | +| Languages | Go, C++ | +| SBOM | [Packages](https://github.com/containerd/containerd/tree/main/pkg) [Versions](https://github.com/containerd/containerd/tree/main/version) | +| | | + + +### Security links + + +| Doc | url | +| -- | -- | +| Security file | https://github.com/containerd/project/blob/main/SECURITY.md | +| Default and optional configs | https://github.com/containerd/containerd/blob/main/docs/man/containerd-config.toml.5.md https://github.com/containerd/containerd/blob/main/docs/cri/config.md https://github.com/containerd/containerd/blob/main/docs/hosts.md | + + +## Overview + +Containerd is a container runtime focused on providing the core functionalities for managing container lifecycles. Specifically architected to focus on modularity and compatibility, it provides a secure and minimal approach making it a great option for integrating into different container orchestrators. + +![Overview Image](https://github.com/containerd/containerd/blob/main/docs/historical/design/architecture.png) + +### Background + +Containerd, a fundamental tool in the realm of containerization, provides a dependable and standardized approach to managing containers. It is a lightweight yet powerful container runtime, ensuring a consistent and efficient experience. + +Originally developed by Docker, Inc. as an integral part of the Docker project, containerd has evolved with the dynamic container ecosystem. Docker's decision to separate container runtime functionality from the runc project led to containerd, an independent project dedicated to container management. + +#### Core Features: + +**- Image and Container Management:** + +Containerd oversees the entire lifecycle of containers, handling tasks such as image storage, transfer, execution, and supervision. Its capabilities also extend to other essential operations like pushing, pulling, and managing container images. + +**- Pluggable Architecture:** + +Containerd boasts a modular and adaptable architecture, allowing for the assembly and reassembly of independent components. This flexibility caters to the diverse requirements of container environments. + +**- Security:** + +With a strong emphasis on security, Containerd implements features like user namespaces and seccomp profiles. These measures enhance container isolation, ensuring a robust security posture. + +**- Compatibility:** + +Aligned with the Open Container Initiative (OCI) specifications, containerd ensures compatibility with other runtimes and tools adhering to the OCI standard. This compatibility facilitates easy transitions between container runtimes supporting OCI. + +**- CLI and APIs:** + +Containerd provides well-defined APIs for programmatic interaction with container runtimes. Additionally, its Command-Line Interface (CLI) allows manual management of containers and images. + +**- Production Ready:** + +Widely adopted in multiple container orchestration platforms and cloud-native environments, Containerd has proven itself as a production-ready solution. Its reliability is evidenced by its integration into various deployments of containerized applications. + +**- Community and Governance:** + +As an open-source project under the Cloud Native Computing Foundation (CNCF), Containerd benefits from a diverse community of contributors. This collaborative approach ensures transparent decision-making, promoting inclusiveness and continuous improvement. + +### Actors + +**- Containerd Core:** + +Role: The core container orchestration engine, managing the complete container lifecycle. +Functionality: Coordinates tasks such as image storage, transfer, execution, and supervision. Ensures a consistent and efficient containerized application experience. +Isolation: Adopts a modular design, separating concerns to prevent unauthorized access and actions. Implements access controls to reinforce security. + +**- Container Runtimes:** + +Role: Executes containers based on specifications provided by containerd, interacting directly with the underlying operating system. +Functionality: Translates container configurations into running instances, ensuring compatibility and adherence to standards. +Isolation: Operates within well-defined boundaries, utilizing namespaces and cgroups for robust process and resource isolation. + +**- Image Registries:** + +Role: Repositories for container images, providing storage and retrieval for containerd in tasks such as image pulling, pushing, and metadata management. +Functionality: Stores and facilitates the distribution of container images, supporting seamless integration with containerd for efficient image management. +Isolation: Maintains a separate identity to prevent unauthorized modifications. Implements access controls to secure image repositories. + +### Actions + +**- Container Lifecycle Management:** + +Description: Orchestrates the complete lifecycle of containers, covering creation, initialization, termination, and removal. +Significance: Acts as the backbone of container orchestration, ensuring the smooth execution of containerized applications throughout their lifecycle. + +**- Image Operations:** + +Description: Manages various image-related operations, including pulling images from repositories, pushing images to registries, and handling image metadata. +Significance: Central to image management within the container ecosystem, enabling efficient distribution and storage of container images. + +**- Resource Isolation and Management:** + +Description: Enforces robust resource isolation for individual containers, including CPU, memory, and network resources. +Significance: Optimizes resource utilization, preventing interference between containers and ensuring performance isolation. + +**- Network Configuration:** + +Description: Configures and manages network settings for containers, facilitating communication and maintaining network isolation. +Significance: Ensures effective container communication while safeguarding against security vulnerabilities through proper network segmentation. + +**- Security Implementation:** + +Description: Implements comprehensive security measures within containers, covering access controls, encrypted communication, and permission management. +Significance: Strengthens the overall security posture of containerized applications, mitigating potential vulnerabilities and ensuring secure execution. + +### Goals + +**- Component Independence:** + +Components should not have tight dependencies on each other, allowing them to be used independently while maintaining a natural flow when used together. + +**- Primitives over Abstractions:** + +Containerd should expose primitives to solve problems instead of building high-level abstractions in the API. This allows flexibility for higher-level implementations. + +**- Extensibility:** + +Containerd should provide defined extension points for various components, allowing alternative implementations to be swapped. For example, it uses runc as the default runtime but supports other runtimes conforming to the OCI Runtime specification. + +**- Defaults:** + +Containerd comes with default implementations for various components, chosen by maintainers. These defaults should only change if better technology emerges. + +**- Scope Clarity:** + +The project scope is clearly defined, and any changes require a 100% vote from all maintainers. The whitelist approach ensures that anything not mentioned in scope is considered out of scope. + +### Non-goals + +**- Component Tight Coupling:** + +Components should not have tight dependencies, promoting independence. + +**- High-Level Abstractions in API:** + +Avoid building high-level abstractions in the API, focus on exposing primitives. + +**- Acceptance of Additional Implementations:** + +Additional implementations for core components should not be accepted into the core repository and should be developed separately. + +**- Build as a First-Class API:** + +Building images is considered a higher-level feature and is out of scope. + +**- Volume Management:** + +Volume management for external data is out of scope. The API supports mounts, binds, etc., allowing different volume systems to be built on top. + +**- Logging Persistence:** + +Logging persistence is considered out of scope. Clients can handle and persist container STDIO as needed. + +## Self-assessment use + +This self-assessment was authored by Swati Baleri, Vivek Radhakrishnan, Sunny Li, and Nathan Smith with a format established by the Containerd maintainers. The purpose of this document is to perform an internal analysis of the project's security. It is not intended to provide a security audit of Containerd, or function as an independent assessment or attestation of Containerd's security health. + +This document serves to provide Containerd users with an initial understanding of Containerd's security, where to find existing security documentation, Containerd plans for security, and general overview of Containerd security practices, both for development of Containerd as well as security of Containerd. + +This document provides the CNCF TAG-Security with an initial understanding of Containerd 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 Containerd seeks graduation and is preparing for a security audit. + +## Security functions and features + +#### Critical + +**- Namespaces:** + +Namespaces creates more security and efficiency by allowing multiple consumers to use the same containerd without conflicts. It has the benefit of separation of containers and images, while sharing content. Addionally, it keeps the designs as simple as it needs to be. + +**- Capabilities:** + +Containerd pushes toward a least-privilege process for managing access. This limits kernel capabilities for processes. Other systems with less least-privilege could create vulnerabilities and increase their attack surfaces. + +**- Isolation:** + +With its capability systems and namespaces, containerd provides industry standard resource isolation, ensuring the resources remain isolated and secured. Resource isolation is crucial for namespaces to function as intended and vice versa. + +**- Modularity:** + +Containerd allows people to use different container systems. This gives users of containerd authority over runtimes, but if not properly handled, could lead to severe access. + +#### Security Relevant + +**- Plug-ins:** + +Containerd is built with a modular architecture so that other technologies can be integrated to enable new capabilities. The advantage with containerd is that these plugins can enhance the functionality of the system without needing to rebuild the containerd itself. + +Popular systems include metadata, container managers, filesystem differentiators, and GRPC APIs. While this is a strength of Containerd, this modularity has been the culprit of most of its previous problems. This is mostly up to others and containerd has many times not handled these plugins correctly, leading to information being unnecessary leaked. In a way, one of its greatest strengths is its greatest security vulnerability. + +**- Network Security:** + +Containerd allows for network isolation, helping lockdown containers with network changes. This prevents unauthorzed communication, but needs to be monitored properly. + +**- Trust:** + +Containerd only stores identical content once, reducing risk of storing multiple copies of vulnerable content, thereby reducing the attack surface. If more things are uploaded, this needs to be monitored as it has a big effect on the attack surface. + +## Project compliance + +Containerd is not documented as meeting any major security standards except for having bypassed a test in fuzzing. The testing done by Adacompliance deemed that the fuzzing prevention was strong and with further testing was incredibly robust for industry application. + +It is reasonable to suggest its minimal framework could support CIS Benchmarks on least privilege and access control policies in ISO. However, there is no public documentation with proof to having matched any of these requirements. + +## Secure development practices + +**Development pipeline:** + +- Containerd contributors must sign commits to ensure contributor identity and prevent unauthorized code changes. +- Containerd images are immutable and signed. Additionally, all images are signed with a GPG key, which helps to verify the authenticity of the image. +- Continuous integration and deployment pipelines automatically test all changes in Containerd, enabling prompt issue detection. +- The open-source code, hosted on GitHub, encourages transparency and community involvement in reviews, aiding in early issue detection. +- All pull requests to the containerd codebase must be reviewed by at least two reviewers before they can be merged. +- Compliant with industry standards, including NIST SP 800-190 and CIS Docker Benchmark, Containerd prioritizes security and reliability benchmarks. It integrates with image scanning tools (Clair, Synk, Trivy, etc.), promoting trusted image registries. +- Containerd employs privilege-dropping techniques, supports Seccomp profiles, and can operate in unprivileged user mode to minimize attack surfaces and limit security impact. +- Resource quotas and cgroups enforce fair resource allocation, preventing resource exhaustion attacks in Containerd. +- TLS encryption safeguards data exchange, and secure networking configurations and communication protocols protect against unauthorized access. +- The use of secure communication protocols, such as HTTPS, when communicating with external services to protect data from exposure is also promoted. +- Security audits occur regularly (CNCF fuzzing audit, community-driven audits, etc.) complemented by a responsible disclosure policy for discreetly reporting and addressing security issues before public disclosure. +- Containerd releases updates with security patches, performance enhancements, and bug fixes, while comprehensive [documentation](https://containerd.io/docs/) guides secure deployment. + +**Communication Channels:** + +- *Internal*: The Containerd team mostly communicates with each other through Slack, GitHub, or email lists internally. +- *Inbound*: Prospective and existing users can communicate with the Containerd team through GitHub issues, mailing lists, or the dedicated Slack channel. +- *Outbound*: The containerd team communicates with its users through the containerd blog, social media channels such as Twitter and GitHub, and through mailing lists. + +**Ecosystem:** + +Containerd plays a pivotal role in the cloud-native ecosystem due to its core functionality as a lightweight container runtime, its integration with various container orchestration platforms, and its active participation in open-source projects. This makes it an essential component for building, deploying, and managing scalable and reliable cloud-native applications. + + +## Security issue resolution + +**- Responsible Disclosures Process**: + +The responsible disclosure process for containerd is designed to manage the identification of security issues, incidents, or vulnerabilities, whether discovered internally or externally. If a security issue is found within the project team, it is reported using the same procedures as external reports. External discoveries are encouraged to follow a responsible disclosure process, which involves reporting the issue either on GitHub or via email. GitHub is the primary platform, allowing individuals to navigate to the security tab, access the Advisories tab, and use the "Report a vulnerability" option. Alternatively, an email can be sent to security@containerd.io, including details of the issue and steps to reproduce. Reporters should anticipate an acknowledgment within 24 hours and are advised to contact any committer directly if there's no response. + +**- Vulnerability Response Process**: + +The responsibility for responding to a reported vulnerability rests with the committers of containerd. Once a committer confirms the relevance of the reported vulnerability, a draft security advisory is created on GitHub. Reports can be submitted through GitHub or via email to security@containerd.io. Reporters interested in participating in the discussion can provide their GitHub usernames for an invitation. Alternatively, they can opt to receive updates via email. If the vulnerability is accepted, a timeline for developing a patch, public disclosure, and patch release is established. In cases where an embargo period precedes public disclosure, an announcement is sent to the security announce mailing list, detailing the vulnerability scope, patch release date, and public disclosure date. Reporters are expected to engage in the discussion of the timeline and adhere to agreed-upon dates for public disclosure. + +**- Incident Response**: + +Defined procedures are in place for triaging reported vulnerabilities, assessing their severity and relevance. The confirmation process involves validating the reported vulnerability to determine its authenticity and impact. If the vulnerability is confirmed, the involved parties, including the reporter(s), are notified. A timeline for developing a patch and making updates available is determined. Depending on the embargo period, the vulnerability and patch release details are publicly disclosed using the security announce mailing list. Reporters are expected to comply with agreed-upon dates for public disclosure, ensuring a responsible and coordinated release of information. This process ensures a systematic and transparent approach to handling security issues, promoting responsible disclosure, and achieving timely resolution. + +## Appendix + + +* Known Issues Over Time: + + There have been some problems in the past with the plugins that containerd has. Even though it is a feature, it has led to problems when the plugins are not correctly inputted. + - https://github.com/containerd/containerd/pull/7347 + - https://github.com/containerd/containerd/pull/8056 + + There is also a few issues with its ability to access resources. In attempt to keep least-privilege access, the dulling out when available can be problematic + - https://github.com/containerd/containerd/issues/3351 + - https://www.cvedetails.com/cve/CVE-2023-25153/ + - https://www.cvedetails.com/cve/CVE-2022-31030/ + - https://www.cvedetails.com/cve/CVE-2022-23471/ + - https://www.cvedetails.com/cve/CVE-2021-32760/ + + +* Record in catching issues in code review or automated testing: + + **Current Level: [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/1271/badge)](https://www.bestpractices.dev/projects/1271)** + + The project achieved the following + - Basics: 13/13 passed + - Change Control: 9/9 passed + - Reporting: 8/8 passed + - Quality: 13/13 passed + - Security: 16/16 passed + - Analysis: 8/8 passed + + +* Case Studies: + + [Demonstrates how Red Hat OpenShift, integrated with containerd, streamlines containerization adoption and simplifies Kubernetes management.](https://swapnasagarpradhan.medium.com/install-a-kubernetes-cluster-on-rhel8-with-conatinerd-b48b9257877a) + + [Explores how containerd simplifies container management on Google Kubernetes Engine (GKE), Google Cloud's fully managed Kubernetes service.](https://cloud.google.com/kubernetes-engine) + + [Delves into the integration of containerd with Amazon Elastic Container Service (ECS), Amazon Web Services' container orchestration service](https://aws.amazon.com/blogs/containers/tag/containerd/) + + [Explores how containerd enables organizations to effectively manage containers on Azure Kubernetes Service (AKS), Microsoft Azure's managed Kubernetes service](https://azure.microsoft.com/en-us/updates/generally-available-containerd-support-for-windows-in-aks/) + +* Related Projects / Vendors: + + Docker uses Containerd for Container management, it offers complete container management service such as image building, user interface and a built-in runtime. + + https://www.docker.com/products/container-runtime/ + https://humalect.com/blog/containerd-vs-docker/ + https://www.wallarm.com/cloud-native-products-101/containerd-vs-docker-what-is-the-difference-between-the-tools/ + + Cri-o and containerd are both container runtimes, but they serve different purposes and have different relationships with Kubernetes. Cri-o is designed specifically for Kubernetes and has a smaller footprint, which is optimized for resource usage within Kubernetes. It leverages containerd's core functionalities for image management and execution, but adds Kubernetes-specific features and optimizations. + + https://cri-o.io/ + + + + + + diff --git a/community/assessments/projects/flatcar/joint-assessment.md b/community/assessments/projects/flatcar/joint-assessment.md index 03c0f8e4d..9223a9aff 100644 --- a/community/assessments/projects/flatcar/joint-assessment.md +++ b/community/assessments/projects/flatcar/joint-assessment.md @@ -44,7 +44,7 @@ Compromising the update server would allow an attacker to “un-publish” a new
2. Maintainers: That's a good catch, I've added 1.c. to discuss repository settings. 11. SSH credential password enforcement 12. 2FA for code repositories, build infrastructure, and VPN access -13. Usage of soft/hard tokens as opposed to SMS 2FA as per [CNCF_SSCP_v1.pdf](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +13. Usage of soft/hard tokens as opposed to SMS 2FA as per [CNCF_SSCP_v1.pdf](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 14. Consider preventing any outbound internet access to the build infrastructure, to avoid command and control for hostile actors diff --git a/community/assessments/projects/fluentd/fluentd/self-assessment.md b/community/assessments/projects/fluentd/fluentd/self-assessment.md index 6dcef073f..5588ff51c 100644 --- a/community/assessments/projects/fluentd/fluentd/self-assessment.md +++ b/community/assessments/projects/fluentd/fluentd/self-assessment.md @@ -172,7 +172,7 @@ Fluentd is the default standard to solve Logging in containerized environments, - Security vulnerabilites are to be reported at https://github.com/fluent/fluentd/security/advisories, as stated in their [security policy](https://github.com/fluent/fluentd/blob/master/SECURITY.md) * Incident Response. - Fluentd is trying to follow supply chain security using [DCO](https://probot.github.io/apps/dco/) - [(Supply chain security)](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) + [(Supply chain security)](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) - Because Fluentd is built on top of the Ruby Ecosystems, they must also check the licenses of dependent gems. ## Appendix diff --git a/community/assessments/projects/lima/self-assessment.md b/community/assessments/projects/lima/self-assessment.md new file mode 100644 index 000000000..1430ba889 --- /dev/null +++ b/community/assessments/projects/lima/self-assessment.md @@ -0,0 +1,371 @@ + +# Self-assessment + + + + +# Self-assessment outline + +## Table of contents + +* [Metadata](#metadata) + * [Security links](#security-links) +* [Overview](#overview) + * [Actors](#actors) + * [Actions](#actions) + * [Background](#background) + * [Goals](#goals) + * [Non-goals](#non-goals) +* [Self-assessment use](#self-assessment-use) +* [Security functions and features](#security-functions-and-features) +* [Project compliance](#project-compliance) +* [Secure development practices](#secure-development-practices) +* [Security issue resolution](#security-issue-resolution) +* [Appendix](#appendix) + +## Metadata + + + +||| +| -- | -- | +| Assessment Stage | Incomplete | +| Software | | +| Security Provider | No | +| Languages | Go | +| SBOM | `go.mod` and `go.sum` contain the dependency information | + +### Security links + + + +| Doc | url | +| -- | -- | +| Security file | | +| Default and optional configs | | + +## Overview + + + +[Lima](https://lima-vm.io/) launches Linux virtual machines with automatic file sharing and port forwarding (similar to WSL2). + +The original goal of Lima was to promote [containerd](https://containerd.io) including [nerdctl (contaiNERD ctl)](https://github.com/containerd/nerdctl) +to Mac users, but Lima can be used for non-container applications as well. + +### Background + + + +A typical usage of Lima is like: + +```bash +# Install +brew install lima + +# Start the VM with the default template +limactl start + +# Launch nerdctl (contaiNERD CTL) via Lima +lima nerdctl run --rm hello-world +``` + +Lima uses YAML files to define VM templates. +See for the examples of the templates. + +A malicious template may break host OS via host filesystem mounts. +It is users's responsibility to avoid using malicious templates. + +### Actors + + +* `limactl` CLI: the CLI provides CRUD operations for VM instances. + The CLI does not need the root privilege on the host OS. + A template file can be specified on creating an instance as follows: + +```bash +# Built-in template +limactl create template://docker + +# Local path +limactl create /usr/local/share/lima/templates/fedora.yaml + +# HTTPS URL (use with a caution) +limactl create https://raw.githubusercontent.com/lima-vm/lima/master/templates/alpine.yaml +``` + +* `lima` CLI: an alias of `limactl shell`, for logging into the guest OS. + +* VM drivers: the following virtual machine drivers are supported (no root privilege is needed): + * QEMU + * Apple Virtualization.framework (for macOS hosts) + * WSL2 (for Windows hosts) + +* SSH: + Lima generates an SSH key-pair and configure the guest OS so that the `lima` CLI (alias of `limactl shell`) + can login to the guest OS. + The SSH port is bound to the localhost of the host OS. + +* Port forwarder: + localhost ports of the guest OS are forwarded to the localhost of the host OS. + These forwarded ports are not exposed to non-localhost by default, but this behavior is customizable. + +* (Optional) SFTP: + When the filesystem mount type is configured to `reverse-sshfs` in a VM template, + Lima launches an SFTP server process on the host and associate its stream to + the SSH process so that the guest OS can mount the host filesystem. + The SFTP server process is launched as a non-root user. + +* (Optional) `socket_vmnet` daemon: + When the network type is set to `lima:shared` in a VM template, + Lima launches a [`socket_vmnet`](https://github.com/lima-vm/socket_vmnet) daemon with `sudo` + so as to enable enhanced networking mode, e.g., publish the VM's IP address to the physical network. + +### Actions + + +* `limactl create`: the CLI receives a template file via the argument, + and populates the disk image for the instance. + +* `limactl start`: the CLI launches the instance using the specified VM driver, + and sets up port forwarding and filesystem mounts. + This action does not need the root privilege on the host. + When the network mode is set to `lima:shared`, the CLI launches the `socket_vmnet` daemon with `sudo`. + The `sudoers` file for this operation can be generated with the `limactl sudoers` command. + +* `limactl sudoers`: the CLI generates `/etc/sudoers.d/lima` file to allow running `socket_vmnet`. + Not needed for the default configuration. + +* `lima`, `limactl shell`: the CLI launches `ssh` to login to the VM instance. + +* `limactl stop`: the CLI stops the specified VM instance. + +* `limactl delete`: the CLI deletes the specified VM instance. + +### Goals + + +* No root privilege is needed for installing and running VM + +* When the root privilege is needed (i.e., `socket_vmnet`), the privileged operation is performed + in a separate process that is confined with the `sudoers` file + +* No port is published to non-localhost by default + +### Non-goals + + +* Tolerance to malicious template files is out of our goals. + An instance created from a malicious template may read and write host files, + depending on the host mounts specified in the template. + +## Self-assessment use + + + +This self-assessment is created by the Lima team to perform an internal analysis of the +project's security. It is not intended to provide a security audit of Lima, or +function as an independent assessment or attestation of Lima's security health. + +This document serves to provide Lima users with an initial understanding of +Lima's security, where to find existing security documentation, Lima plans for +security, and general overview of Lima security practices, both for development of +Lima as well as security of Lima. + +This document provides the CNCF TAG-Security with an initial understanding of Lima +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 +Lima seeks graduation and is preparing for a security audit. + +## Security functions and features + + + +* The security of Lima critically depends on VM drivers (e.g., QEMU, Virtualization.framework), + SSH, SFTP, etc. + Users have to make sure to install the well-maintained version of these dependencies. + On macOS hosts, this can be typically accomplished by clicking the "Software Update" button of the System Preference, + and by running `brew upgrade`. + +## Project compliance + + + +N/A + +## Secure development practices + + + +* Development Pipeline: + * Every commit must be signed off with DCO, and every non-trivial commit must be approved by at least one other Maintainer (Committer or Reviewer). + See for the further information. + * Dependabot is enabled to bump up Go dependencies automatically: + + * Vulnerabilities of the Go dependencies are occasionally scanned with [govulncheck](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck) + * CodeQL is enabled. Maintainers can see the results in . + +* Communication Channels: + GitHub and Slack. See . + +* Ecosystem: + Lima has been widely adopted in several third-party projects, such as: + * [Rancher Desktop](https://rancherdesktop.io/): Kubernetes and container management to the desktop + * [Colima](https://github.com/abiosoft/colima): Docker (and Kubernetes) on macOS with minimal setup + * [Finch](https://github.com/runfinch/finch): Finch is a command line client for local container development + * [Podman Desktop](https://podman-desktop.io/): Podman Desktop GUI has a plug-in for Lima virtual machines + +## Security issue resolution + + + +* Responsible Disclosures Process: + Vulnerabilities are expected to be reported via . + Those who do not have a GitHub account may also use email to reach out to the Committers directly. + +* Incident Response: + Committers triage and confirm potential vulnerability reports, and ship a fix as soon as possible. + Committers may coordinate with well-known downstream projects (e.g., Rancher Desktop, Colima, and Finch) for + a disclosure of a serial vulnerability. + +## Appendix + + + +* Known Issues Over Time: See . + * [GHSA-f7qw-jj9c-rpq9](https://github.com/lima-vm/lima/security/advisories/GHSA-f7qw-jj9c-rpq9) (May 30, 2023): + A virtual machine instance with a malicious disk image could read a single file on the host filesystem, even when no filesystem is mounted from the host. + Fixed in Lima v0.16.0, by prohibiting using a backing file path in the VM base image. + +* CII Best Practices: See . Passing. + +* Case Studies: See Rancher Desktop (SUSE), Colima, Finch (AWS) below. + +* Related Projects / Vendors: + * [Rancher Desktop](https://rancherdesktop.io/): Kubernetes and container management to the desktop + * [Colima](https://github.com/abiosoft/colima): Docker (and Kubernetes) on macOS with minimal setup + * [Finch](https://github.com/runfinch/finch): Finch is a command line client for local container development + * [Podman Desktop](https://podman-desktop.io/): Podman Desktop GUI has a plug-in for Lima virtual machines + * [lima-xbar-plugin](https://github.com/unixorn/lima-xbar-plugin): xbar plugin to start/stop VMs from the menu bar and see their running status. + * [lima-gui](https://github.com/afbjorklund/lima-gui): Qt GUI for Lima diff --git a/community/assessments/projects/wasmcloud/self-assessment.md b/community/assessments/projects/wasmcloud/self-assessment.md new file mode 100644 index 000000000..3a1496c33 --- /dev/null +++ b/community/assessments/projects/wasmcloud/self-assessment.md @@ -0,0 +1,251 @@ +# wasmCloud Self-assessment + +## Table of contents + +- [wasmCloud Self-assessment](#wasmcloud-self-assessment) + - [Table of contents](#table-of-contents) + - [Metadata](#metadata) + - [Security links](#security-links) + - [Overview](#overview) + - [Background](#background) + - [Actors](#actors) + - [Actions](#actions) + - [Goals](#goals) + - [Non-goals](#non-goals) + - [Self-assessment use](#self-assessment-use) + - [Security functions and features](#security-functions-and-features) + - [Project compliance](#project-compliance) + - [Secure development practices](#secure-development-practices) + - [Security issue resolution](#security-issue-resolution) + - [Appendix](#appendix) + - [Related projects and vendors](#related-projects-and-vendors) + +## Metadata + +| | | +| ----------------- | ------------------------------------------------------ | +| Assessment Stage | In Progress | +| Software | https://github.com/wasmCloud/wasmCloud | +| Security Provider | No | +| Languages | Rust, Go, TypeScript, JavaScript, Shell | +| SBOM | wasmCloud does not currently generate SBOMs on release | + +### Security links + +| Document | URL | +| ------------- | ------------------------------------------------------------ | +| Security file | https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md | + +## Overview + +wasmCloud is a platform for building and deploying distributed applications using WebAssembly +(Wasm). It is designed to provide a lightweight, highly secure and portable WebAssembly runtime with +WebAssembly-native orchestration for managing and scaling declarative applications – enabling +secure, portable, and composable cloud native applications. This allows developers to build scalable +systems using any programming language that compiles to WebAssembly, providing a universal runtime +for cloud, edge, and IoT environments. + + +### Background + +wasmCloud is an open-source technology enabling platform engineering and application development +teams to deliver distributed applications built using WebAssembly. + +WebAssembly offers several core benefits that make it an increasingly important and interesting +technology for cloud-native computing workloads: + +* **Portability**: WebAssembly is designed to be platform-agnostic, meaning code written in + WebAssembly can run across different environments—whether in browsers, servers, cloud, edge, or + IoT devices—without modification. + +* **Performance**: WebAssembly is compiled into a binary format that runs at near-native speed, + providing efficient execution compared to traditional interpreted languages, especially in + resource-constrained environments. + +* **Security**: WebAssembly operates in a secure, sandboxed environment, isolating applications from + the host system. Each sandboxed module gets access to only the set of capabilities that it is + explicitly granted and nothing more. + +* **Lightweight**: WebAssembly Components are small and fast to load, which makes them ideal for + resource-constrained environments like edge devices and embedded systems, while also reducing + startup times in the cloud. + +wasmCloud goes beyond core WebAssembly by targetting WebAssembly Components as the unit of +deployment, which themselves bring along the following additional benefits on top of what +WebAssembly already provides: + +* **Language-agnostic Composition**: WebAssembly Components allow code to be written in different + programming languages to be seamlessly integrated into a single application. This means developers + can leverage the strengths of multiple languages while maintaining a unified runtime, enhancing + both flexibility and collaboration. + +* **Modularity and Reusability**: With WebAssembly Components, individual functionality can be + encapsulated into reusable modules, which can be composed into larger applications. This + modularity simplifies development and maintenance by enabling code reuse and simplifying upgrades + or replacement of specific components without disrupting the entire system. + +* **Interoperability**: WebAssembly Components are designed to communicate with each other in a + standardized way, regardless of the programming languages they were built in. This ensures that + components can be shared and reused across projects or ecosystems, enabling faster development + cycles and more interoperable systems. + +* **Security Isolation**: As with core WebAssembly modules, components are run inside of their own + secure sandboxes. Each component is fully isolated from the others, and they can interact with one + another over typed interface definitions. + +Finally, wasmCloud provides the necessary tooling to cover the entire software lifecycle from local +development to running and operating in prouction. + +### Actors + +The following table describes all actors of the wasmCloud project. + + +| Actor | Description | +| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| wasmCloud Host | The wasmCloud host is the core executable for wasmCloud. It uses the wasmtime runtime to execute WebAssembly Components and also executes providers. It connects to NATS as its communication backbone and provides a low-level API for controlling various components of the system. Hosts are separated from other hosts using what is called a "lattice" (a namespace) | +| Wadm (wasmCloud Deployment Manager) | A reconcilation loop based system comparable to the Kubernetes API and scheduler. This actor takes desired state and translates it to commands that are sent to individual hosts. It has the ability to manage multiple lattices but must authenticate to the Host APIs in the same way as any other entity | +| WebAssembly Components | Possibly untrusted, user-provided code compiled to WebAssembly. This is often the business logic of an application. WebAssembly Components are entirely introspectable so the system can identify exactly what capabilies are being requested or provided. These are subject to all the security guarantees described in the [background](#background) section. | +| Capability Providers | Providers are the most privileged actor in the wasmCloud ecosystem and should be under the most scrutiny. As indicated by their name, these binaries provide specific functionality required by WebAssembly Components in the system. Examples of these include database connections, HTTP connections, ML/AI processing, access to blobstores, and so on. Generally there are many components, but few providers. A provider is often meant to be reused by many components. They are generally provided as trusted wasmCloud maintained providers or as custom providers created by the organization running wasmCloud | + + +### Actions + +| Action | Description | +| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Host API calls | All wasmCloud APIs are via topic spaces in NATS, so authorization and authentication are initially provided by NATS. The recommended pattern for authn/z is via [decentralized JWT authentication](https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/jwt). These tokens can be used to restrict access to specific lattices (i.e. namespaces) or specific API operations. Additionally, there is an optional and extensible [policy service](https://wasmcloud.com/docs/deployment/security/policy-service) that API calls are subject to if configured. This allows users to integrate with existing frameworks like OPA for authorization | +| Wadm API calls | Similarly to the Host API, the Wadm API uses NATS topics and authn/z for connections, along with the same power to restrict those tokens. Wadm API calls eventually get translated to Host API calls, using the permissions of Wadm and not the user. | +| Linking components | Although this is technically a subset of the Host API, it is important to call out from a security actions perspective. wasmCloud gives you the ability to link components to their requested capabilities at runtime. This is a privileged operation often restricted to platform teams for production deployments. These links can be removed at any time for instant denial of capabilities or to hot swap capabilities when rolling out critical security fixes | +| Secrets management | wasmCloud provides [secrets backend](https://wasmcloud.com/docs/deployment/security/secrets) with the ability to hook in a variety of secret stores. These are provided via encrypted data as described in the [wasmCloud documentation](https://wasmcloud.com/docs/concepts/secrets) | + +### Goals + +wasmCloud's goal is to be the way to run standard WebAssembly Components (i.e. no custom wasmCloud +SDKs needed) in a distributed manner. As such, the project goal is to ensure all of the security +guarantees of WebAssembly are reflected in wasmCloud itself. Only those with proper API permssions +and roles are able to start entities within the system and link those entities together. By default +nothing is linked together unless explictly configured to do so, maintaining the sandbox +environment. + +The security of communications between hosts is reliant on the configuration of NATS and the access +tokens used to connect to it. If the NATS cluster is properly configured with token authentication +and TLS, communications should be secure and encrypted. Misconfiguration of NATS can result in +unintentional exposure or connections. + +### Non-goals + +wasmCloud does not attempt to enforce or handle other security guarantees outside of those provided +by WebAssembly or other systems integrated via capability provider + +## Self-assessment use + +This self-assessment is created by the wasmCloud team to perform an internal analysis of the +project’s security. It is not intended to provide a security audit of wasmCloud, or function as an +independent assessment or attestation of wasmCloud’s security health. + +This document serves to provide wasmCloud users with an initial understanding of wasmCloud’s +security, where to find existing security documentation, wasmCloud plans for security, and general +overview of wasmCloud security practices, both for development of wasmCloud as well as security of +wasmCloud. + +This document provides the CNCF TAG-Security with an initial understanding of wasmCloud 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 wasmCloud seeks graduation and is preparing +for a security audit. + +## Security functions and features + +**Critical** + +- wasmCloud Host: The host embeds the [Wasmtime runtime](https://wasmtime.dev/) as it's WebAssembly + runtime, which is fuzzed regularly. The security of the underlying WebAssembly sandbox relies + completely on its security. The wasmCloud host itself validates that various entities are + correctly linked and allowed to communicate. + +**Security Relevant** + +- Capability Providers: Providers are the most privileged actor in the wasmCloud ecosystem and + should be under the most scrutiny and review before adding the use of a new provider. +- NATS Cluster: The NATS cluster used for wasmCloud should be properly secured and encrypted to + guarantee security of communications. It is highly recommended to use [decentralized JWT + authentication](https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/jwt) + to best restrict access to specific API topics +- Policy Service: If used, integration with policy engines should have testing in place for the + various rules + +## Project compliance + +The wasmCloud project does not comply with any specific security standard. However, various security +standards may be applied to related projects such as NATS or services to which capability providers +can connect. + +## Secure development practices + +**Development Pipeline** + +- All wasmCloud repos use Dependabot configured with regular scans for all projects, including + automatic update PRs +- The main wasmCloud host is also subject to `cargo audit` on all PRs. +- All PRs require reviews from the proper subject matter expert before merging + +**Communication Channels** + +Most communication happens on the wasmCloud Slack for both inbound/outbound communication from/to +the community as well as internal communication between project and org maintainers. There is also +the cncf-wasmCloud-maintainers@lists.cncf.io that can be used for asynchronous communication + +**Ecosystem** + +wasmCloud is deeply integrated into the cloud native ecosystem. The project uses CNCF incubating +project NATS for the messaging layer of its application. wasmCloud supports running its WebAssembly +binaries by downloading from OCI compliant registries, exporting traces, logs, and metrics to +OpenTelemetry compatible collectors, and defines its declarative application manifests using the +Open Application Model. + +Additionally, there are integrations with other technologies within the CNCF such as a Kubernetes +operator, policy engine support for OpenPolicyAgent, and many other extension points. + +## Security issue resolution + +The project's security disclosure and incident processes are thoroughly documented in the +[SECURITY.md](https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md) doc in the main repo of +the project. + +An example of the resulting advisory can been seen +[here](https://github.com/wasmCloud/wasmcloud-otp/security/advisories/GHSA-2cmx-rr54-88g5) + +## Appendix + +- Known Issues Over Time: There has only been one recorded CVE. Details of that CVE can be found + [here](https://github.com/wasmCloud/wasmcloud-otp/security/advisories/GHSA-2cmx-rr54-88g5). + Anecdotally, various security bugs have been prevented from the project's testing pipelines +- The wasmCloud project has passed OpenSSF best practices: + https://www.bestpractices.dev/en/projects/6363 +- Various users have provided real-world case studies of using wasmCloud. Links to those case + studies and talks are provided for convenience below. More will also be available as the project + finishes adopter interviews for moving to incubating + - https://www.cncf.io/blog/2024/01/05/bringing-webassembly-to-telecoms-with-cncf-wasmcloud/ + - https://www.cncf.io/blog/2022/11/17/better-together-a-kubernetes-and-wasm-case-study/ + - https://www.cncf.io/blog/2024/08/23/wasmcloud-on-the-factory-floor-efficient-and-secure-processing-of-high-velocity-machine-data/ + - https://www.youtube.com/live/lUV49UjFAQM?si=oHxguYRRXFDHLdaF + - https://youtu.be/1sWQqgK-79c?si=m3g0UqH1qp2_qAUm + +Also of note is that the wasmCloud project has already complete and passed a security audit with +Trail of Bits. A summary of that audit can be found here: +https://ostif.org/ostif-has-completed-a-security-audit-of-wasmcloud/ + +### Related projects and vendors + +Within the WebAssembly space, wasmCloud is most often compared with Fermyon Spin or with WasmEdge. A +brief discussion of the differences are discussed below: + +- WasmEdge is a CNCF WebAssembly runtime with many batteries included. In many ways, WasmEdge is + more similar to Spin and other Serverless runtimes than wasmCloud. A key difference is that + wasmCloud is a distributed platform and not a runtime. wasmCloud embeds a runtime (Wasmtime), but + is designed for distributed workloads. WasmCloud includes a WebAssembly Components native + orchestrator that enables running components from the edge to the cloud. +- Fermyon’s Spin project is a FaaS style runtime (Wasmtime) with a heavy focus on a smooth developer + experience. Like WasmEdge, they have a batteries-included runtime and are built on the component + model, but require the use of their custom multi-language Spin developer SDKs. They have the most + polished developer experience but do not have many options for running in a distributed + environment outside of relying on Kubernetes to orchestrate and scale deployments. diff --git a/community/assets/tag-emeritus-leaders.md b/community/assets/tag-emeritus-leaders.md index 84cf3bc8f..ba27dd238 100644 --- a/community/assets/tag-emeritus-leaders.md +++ b/community/assets/tag-emeritus-leaders.md @@ -1,17 +1,18 @@ # TAG Security Chair Emeriti -A big thank you to all the [tag emeritus leaders](/tag-emeritus-leaders.md) of this TAG! Your hard work and dedication have helped to make this project a success. Your valuable contributions have enabled us to develop a strong contributor strategy and build a thriving open-source community. Thank you for all that you have done! +A big thank you to all the emeritus leaders of this TAG! Your hard work and dedication have helped to make this project a success. Your valuable contributions have enabled us to develop a strong contributor strategy and build a thriving open-source community. Thank you for all that you have done! -| Name | Organization | Term | Handle | -|-----------------------|------------------------|---------------------|-----------| -| Dan Shaw | PayPal | June, 2019 - September, 2020 | @dshaw | -| Sarah Allen | | June, 2019 - June, 2021 | @ultrasaurus | -| Jeyappragash JJ | Tetrate.io | June, 2019 - June, 2021 | @pragashj | -| Emily Fox | Apple | September, 2020 - February, 2022 | @TheFoxAtWork | -| Brandon Lum | Google | June, 2021 - June, 2023 | @lumjjb | -| Aradhana Chetal | TIAA | June, 2021 - September, 2023 | @achetal01 | -| Andrew Martin | ControlPlane | March, 2022 - March, 2024 | @sublimino| +| Name | Organization | Term | Handle | +|------------------|-----------------|-----------------------------------|---------------| +| Dan Shaw | PayPal | June, 2019 - September, 2020 | @dshaw | +| Sarah Allen | | June, 2019 - June, 2021 | @ultrasaurus | +| Jeyappragash JJ | Tetrate.io | June, 2019 - June, 2021 | @pragashj | +| Emily Fox | Apple | September, 2020 - February, 2022 | @TheFoxAtWork | +| Brandon Lum | Google | June, 2021 - June, 2023 | @lumjjb | +| Aradhana Chetal | TIAA | June, 2021 - September, 2023 | @achetal01 | +| Andrew Martin | ControlPlane | March, 2022 - March, 2024 | @sublimino | +| Pushkar Joglekar | Independent | June, 2023 - June, 2025 | @PushkarJ | diff --git a/community/events/cloud_native_security.md b/community/events/cloud-native-security.md similarity index 96% rename from community/events/cloud_native_security.md rename to community/events/cloud-native-security.md index 481e0c80c..a0a68eca8 100644 --- a/community/events/cloud_native_security.md +++ b/community/events/cloud-native-security.md @@ -108,3 +108,10 @@ project, architecture, and enhance team awareness on security. - Seattle, WA - February 1-2, 2023 + +### 2024 + +[CloudNativeSecurityCon North America](https://cloudnativesecurityconna24.sched.com/) + +- Seattle, WA +- June 26-27, 2024 diff --git a/community/publications/README.md b/community/publications/README.md index e6af8db25..f290aca83 100644 --- a/community/publications/README.md +++ b/community/publications/README.md @@ -4,20 +4,20 @@ This document lists all the publications and resources that TAG Security has pro | Publication | Description | Format | Link | |-------------|--------------|--------|------| -| **Cloud Native Security Controls Catalog** | Mapping of Cloud Native Security Whitepaper and Software Supply Chain Best Practices Paper to NIST SP800-53r5 | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/cloud-native-controls/phase-one-announcement.md) | +| **Cloud Native Security Controls Catalog** | Mapping of Cloud Native Security Whitepaper and Software Supply Chain Best Practices Paper to NIST SP800-53r5 | Markdown | [Link](/community/working-groups/controls/phase-one-announcement.md) | | | | Spreadsheet | [Link](https://docs.google.com/spreadsheets/d/1GUohOTlLw9FKUQ3O23X7ypvJLXN-B3veJGe6YE6JYfU/edit?usp=sharing) | -| **Cloud Native Security Lexicon** | Standardization of terminologies specific to Cloud Native Security | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/security-lexicon/cloud-native-security-lexicon.md) | -| **Cloud Native Security Whitepaper** | Information about building, distributing, deploying, and running secure cloud native capabilities | Markdown (v2) | [Link](https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/cloud-native-security-whitepaper.md) | -| | | PDF (v2) | [Link](https://www.cncf.io/wp-content/uploads/2022/06/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) | +| **Cloud Native Security Lexicon** | Standardization of terminologies specific to Cloud Native Security | Markdown | [Link](/community/resources/security-lexicon/cloud-native-security-lexicon.md) | +| **Cloud Native Security Whitepaper** | Information about building, distributing, deploying, and running secure cloud native capabilities | Markdown (v2) | [Link](/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md) | +| | | PDF (v2) | [Link](/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) | | | | Audio (v1) | [Link](https://soundcloud.com/user-769472014/sets/cncf-tag-security-cloud-native-security-whitepaper-version-v1) | | | **Translations** | | | -| | | Portuguese (v1) | [Link](https://github.com/cncf/tag-security/blob/main/security-whitepaper/v1/cloud-native-security-whitepaper-brazilian-portugese.md) | -| | | Chinese (v1) | [Link](https://github.com/cncf/tag-security/blob/main/security-whitepaper/v1/cloud-native-security-whitepaper-simplified-chinese.md) | +| | | Portuguese (v1) | [Link](/community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-brazilian-portugese.md) | +| | | Chinese (v2) | [Link](/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf) | | **Open and Secure - A Manual for Practicing Threat Modeling to Assess and Fortify Open Source Security** | Guide for assessing and understanding the security of open source software projects | PDF | [Link](/community/assessments/Open_and_Secure.pdf) | | **Policy** | | | | -| | Formal Verification for Policy Configurations | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/policy/overview-policy-formal-verification.md) | -| | Handling build-time dependency vulnerabilities | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/policy/overview-policy-build-time-dependency-vulns.md) | -| **Secure Defaults: Cloud Native 8** | | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) | +| | Formal Verification for Policy Configurations | Markdown | [Link](/community/working-groups/archive/policy/overview-policy-formal-verification.md) | +| | Handling build-time dependency vulnerabilities | Markdown | [Link](/community/working-groups/archive/policy/overview-policy-build-time-dependency-vulns.md) | +| **Secure Defaults: Cloud Native 8** | | Markdown | [Link](/community/resources/security-whitepaper/secure-defaults-cloud-native-8.md) | | **Security Assessments** | Assessments of several CNCF projects | | | | | Buildpacks | Markdown | [Link](/community/assessments/projects/buildpacks) | | | Cloud Custodian | Markdown | [Link](/community/assessments/projects/custodian) | @@ -28,10 +28,10 @@ This document lists all the publications and resources that TAG Security has pro | | OPA | Markdown | [Link](/community/assessments/projects/opa) | | | Spiffe-Spire | Markdown | [Link](/community/assessments/projects/spiffe-spire) | | **Supply Chain Security** | | | | -| | Software Supply Chain Best Practices | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md) | -| | | PDF | [Link](https://github.com/cncf/tag-security/raw/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) | -| | Evaluating your supply chain security | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md) | -| | Secure Software Factory | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/supply-chain-security/secure-software-factory/secure-software-factory.md) | -| | | PDF | [Link](https://github.com/cncf/tag-security/raw/main/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf) | -| | Catalog of Supply Chain Compromises | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises) | -| **Use Cases & Personas** | List of use cases to enable secure access, policy control, and safety for users of cloud native technology | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/usecase-personas/README.md) | +| | Software Supply Chain Best Practices | Markdown | [Link](/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp.md) | +| | | PDF | [Link](/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) | +| | Evaluating your supply chain security | Markdown | [Link](/community/working-groups/supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md) | +| | Secure Software Factory | Markdown | [Link](/community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory.md) | +| | | PDF | [Link](/community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf) | +| | Catalog of Supply Chain Compromises | Markdown | [Link](/community/catalog/compromises) | +| **Use Cases & Personas** | List of use cases to enable secure access, policy control, and safety for users of cloud native technology | Markdown | [Link](/community/resources/usecase-personas/README.md) | diff --git a/community/publications/paper-process.md b/community/publications/paper-process.md index 1f440b445..452f3a507 100644 --- a/community/publications/paper-process.md +++ b/community/publications/paper-process.md @@ -90,7 +90,7 @@ The paper lead creates a README.md with: - Original design decisions - Links to files in the repo -### Blog Publishing and Coordination +#### Blog Publishing and Coordination Coordinate with TAG leadership and CNCF for a blog post to increase visibility. Consider presenting at community events. diff --git a/community/resources/security-whitepaper/v1/secure-software-factory.md b/community/resources/security-whitepaper/v1/secure-software-factory.md index 100bf985a..564140ee5 100644 --- a/community/resources/security-whitepaper/v1/secure-software-factory.md +++ b/community/resources/security-whitepaper/v1/secure-software-factory.md @@ -1,6 +1,6 @@ ## Introduction -A software supply chain is the series of steps performed when writing, testing, packaging, and distributing application software to end consumers. Given the increased prominence of software supply chain exploits and attacks, the [Cloud Native Computing Foundation (CNCF) Technical Advisory Group for Security](https://github.com/cncf/tag-security) published a whitepaper titled [“Software Supply Chain Best Practices”](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)[^1], which captures over 50 recommended practices to secure the software supply chain. That document is considered a prerequisite for the content described in this reference architecture. +A software supply chain is the series of steps performed when writing, testing, packaging, and distributing application software to end consumers. Given the increased prominence of software supply chain exploits and attacks, the [Cloud Native Computing Foundation (CNCF) Technical Advisory Group for Security](https://github.com/cncf/tag-security) published a whitepaper titled [“Software Supply Chain Best Practices”](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)[^1], which captures over 50 recommended practices to secure the software supply chain. That document is considered a prerequisite for the content described in this reference architecture. This publication is a follow-up to that paper, targeted at system architects, developers, operators, and engineers in the areas of software development, security, and compliance. This reference architecture adopts the “Software Factory” model[^2] for designing a secure software supply chain. @@ -1554,7 +1554,7 @@ Software Factory: [https://en.wikipedia.org/wiki/Software_factory](https://en.wi CNCF TAG-Security: [https://github.com/cncf/tag-security](https://github.com/cncf/tag-security) -CNCF Supply Chain Security Paper: [https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +CNCF Supply Chain Security Paper: [https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) CNCF Cloud Native Security Whitepaper: [https://github.com/cncf/tag-security/blob/main/security-whitepaper/CNCF_cloud-native-security-whitepaper-Nov2020.pdf](https://github.com/cncf/tag-security/blob/main/security-whitepaper/CNCF_cloud-native-security-whitepaper-Nov2020.pdf) diff --git a/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf b/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf index b78f25018..c829608d7 100644 Binary files a/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf and b/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf differ diff --git a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-it.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-it.md index 9d7a3e4ee..63ef172d0 100644 --- a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-it.md +++ b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-it.md @@ -686,7 +686,7 @@ Gli amministratori e i team di sicurezza dovrebbero archiviare tutte le informaz Un programma SBOM, CVE e VEX maturo e automatizzato può fornire informazioni rilevanti ad altri controlli di sicurezza e conformità. Ad esempio, l'infrastruttura può segnalare automaticamente i sistemi non conformi a una piattaforma di osservabilità o negare di fornire l'identità crittografica di un workload, mettendola effettivamente in quarantena da sistemi conformi in ambienti Zero-Trust. -La CNCF ha pubblicato il [Whitepaper sulle Best Practice nella Supply Chain](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) per fornire un supporto nella progettazione di un processo sicuro all’interno della supply chain. Questo whitepaper fornisce maggiori dettagli sulla protezione della supply chain del software e discute i progetti CNCF rilevanti che sviluppatori e operatori possono utilizzare per proteggerne le varie fasi. +La CNCF ha pubblicato il [Whitepaper sulle Best Practice nella Supply Chain](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) per fornire un supporto nella progettazione di un processo sicuro all’interno della supply chain. Questo whitepaper fornisce maggiori dettagli sulla protezione della supply chain del software e discute i progetti CNCF rilevanti che sviluppatori e operatori possono utilizzare per proteggerne le varie fasi. ##### GitOps (novità nella v2) @@ -1106,7 +1106,7 @@ Runtime 26. [Secure Defaults: Cloud Native 8](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) -27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 28. Cloud Native Security Map - [https://cnsmap.netlify.app](https://cnsmap.netlify.app) diff --git a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md index 2b5469d25..d2f95b5bf 100644 --- a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md +++ b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md @@ -653,7 +653,7 @@ SBOMには何千もの依存関係が含まれていることがあり、それ 成熟し自動化されたSBOMやCVEおよびVEXプログラムは、他のセキュリティおよびコンプライアンス管理に関連情報を提供する可能性があります。例えば、インフラストラクチャは、非準拠のシステムを観測可能性プラットフォームに自動的に報告したり、必要な暗号化ワークロードのID提供を拒否したりして、ゼロトラスト環境において準拠システムから効果的に隔離することができます。 -CNCFは、安全なサプライチェーンプロセスの設計を支援するために、[ソフトウェアサプライチェーンのベストプラクティス白書](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)を作成しました。この白書は、ソフトウェアサプライチェーンのセキュリティ確保に関する詳細を提供し、開発者とオペレータがサプライチェーンの様々な段階でのセキュリティ確保に利用できるCNCFの関連プロジェクトについて説明しています。 +CNCFは、安全なサプライチェーンプロセスの設計を支援するために、[ソフトウェアサプライチェーンのベストプラクティス白書](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)を作成しました。この白書は、ソフトウェアサプライチェーンのセキュリティ確保に関する詳細を提供し、開発者とオペレータがサプライチェーンの様々な段階でのセキュリティ確保に利用できるCNCFの関連プロジェクトについて説明しています。 ##### GitOps(v2で追記) @@ -1037,7 +1037,7 @@ RV.3.2 24. [ATT&CK’s Threat matrix for containers](https://medium.com/mitre-engenuity/att-ck-for-containers-now-available-4c2359654bf1) 25. [NIST Incident Response Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf) 26. [Secure Defaults: Cloud Native 8](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) -27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 28. Cloud Native Security Map - [https://cnsmap.netlify.app](https://cnsmap.netlify.app) 29. [Center for Internet Security (CIS)](https://www.cisecurity.org/) 30. [OpenSCAP](https://www.open-scap.org/) diff --git a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md index 4280e54c7..c68f0b399 100644 --- a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md +++ b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md @@ -638,7 +638,7 @@ ATT&CK 的威胁矩阵由行和列组成，行表示技术，列表示战术。 成熟和自动化的 SBOM、CVE 和 VEX 程序可为其他安全和合规控制提供相关信息。例如，基础设施可能会自动向可观察平台报告不符合要求的系统，或拒绝提供必要的加密工作负载身份，从而在零信任环境中有效地将其与符合要求的系统隔离开来。 -CNCF 制作了[软件供应链最佳实践白皮书](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)，以帮助您设计安全的供应链流程。本白皮书提供了有关保护软件供应链的更多详细信息，并讨论了开发人员和运营商可用于保护供应链各个阶段的相关 CNCF 项目。 +CNCF 制作了[软件供应链最佳实践白皮书](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)，以帮助您设计安全的供应链流程。本白皮书提供了有关保护软件供应链的更多详细信息，并讨论了开发人员和运营商可用于保护供应链各个阶段的相关 CNCF 项目。 ##### GitOps（v2 新增） @@ -898,7 +898,7 @@ GitOps 流程负责向生产环境提供更改，如果该流程受到危害， 24. [ATT&CK’s Threat matrix for containers](https://medium.com/mitre-engenuity/att-ck-for-containers-now-available-4c2359654bf1) 25. [NIST Incident Response Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf) 26. [Secure Defaults: Cloud Native 8](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) -27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 28. Cloud Native Security Map - [https://cnsmap.netlify.app](https://cnsmap.netlify.app) 29. [Center for Internet Security (CIS)](https://www.cisecurity.org/) 30. [OpenSCAP](https://www.open-scap.org/) diff --git a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md index bbb3761bc..2bc3d79cb 100644 --- a/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md +++ b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md @@ -1306,7 +1306,7 @@ deny providing a necessary cryptographic workload identity, effectively quaranti Zero-Trust environments. The CNCF has produced -the [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +the [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) to assist you with designing a secure supply chain process. This whitepaper provides more details about securing the software supply chain and discusses relevant CNCF projects that developers and operators can use to secure various stages of the supply chain. @@ -1815,7 +1815,7 @@ Runtime 24. [ATT&CK’s Threat matrix for containers](https://medium.com/mitre-engenuity/att-ck-for-containers-now-available-4c2359654bf1) 25. [NIST Incident Response Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf) 26. [Secure Defaults: Cloud Native 8](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) -27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +27. [Software Supply Chain Best Practices White Paper](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 28. Cloud Native Security Map - [https://cnsmap.netlify.app](https://cnsmap.netlify.app) 29. [Center for Internet Security (CIS)](https://www.cisecurity.org/) 30. [OpenSCAP](https://www.open-scap.org/) diff --git a/community/working-groups/automated-governance/README.md b/community/working-groups/automated-governance/README.md index 9045a3e43..80cc4bee1 100644 --- a/community/working-groups/automated-governance/README.md +++ b/community/working-groups/automated-governance/README.md @@ -17,6 +17,10 @@ The scope of this project includes: - Creation of best practice guidelines and documentation. - Potential development of tooling or integration patterns for common CI/CD platforms. +## WIP Documentation + +- **Working Draft:** [Google Docs](https://docs.google.com/document/d/14pV0ooE40yuo0u_CH-OeWS8lZgMBfxo8F38QRIaKUXY) + ## Meeting Information - **Meeting:** Every 2 weeks on Tuesday at 2:00 PM Pacific Time (US and Canada) ([Calendar Invite](https://zoom.us/meeting/tJUtduGoqz4qGddkUvgs3jVjzUEY6Y8MEcT6/ics?icsToken=98tyKuCprjoiGtGQsBqERowcAoj4WfTwmCVfjadZlyrzBDMAaDX8LNdnC-RGSPX1)) diff --git a/community/working-groups/commons/README.md b/community/working-groups/commons/README.md new file mode 100644 index 000000000..5fca93264 --- /dev/null +++ b/community/working-groups/commons/README.md @@ -0,0 +1,28 @@ +# Commons Working Group + +## Goals + +- Create a bridge for knowledge sharing between the STAG and other bodies within the Linux Foundation +- Seek opportunities to mitigate duplication of security efforts between bodies within the Linux Foundation +- Ensure hygiene recommendations for CNCF projects align closely with corresponding OpenSSF recommendations + +## Scope + +- Coordinate discussion between contributors from STAG and OpenSSF +- Highlight opportunities for the STAG to contribute to codebases, standards, and publications that may benefit the CNCF and/or STAG goals + +## Deliverables + +1. Aid in the creation of a universal open source project security baseline. +1. Contribute to the development of evaluation probes that can be used to evaluate Linux Foundation (and CNCF) projects against the universal open source project security baseline. + +## Meeting Information + +- **Meeting:** Every 2 weeks on Wednesday at 10:30 ET ([Calendar Invite](https://zoom-lfx.platform.linuxfoundation.org/meeting/98902119803?password=089ce577-a05d-4d3c-9caa-73f8bfd90e5c)) +- **Meeting Notes:** [Google Docs](https://docs.google.com/document/d/14xJf4c4ugjwmSmk-V49-_xPNaqZe771zI9qn95TN7ws/edit) + +## Contact + +- **Lead:** Eddie Knight +- **STAG Rep:** Marco De Benedictis +- **Slack Channel:** [Link](https://cloud-native.slack.com/archives/C07EX4ZU15Y) diff --git a/community/working-groups/compliance/README.md b/community/working-groups/compliance/README.md index cbfdfae83..b073a08db 100644 --- a/community/working-groups/compliance/README.md +++ b/community/working-groups/compliance/README.md @@ -26,7 +26,7 @@ Reviewing industry and governmental standards (e.g., NIST, PCI, HIPAA) from a cl ## Meeting Information - **Weekly Meetings:** 10:00 AM Eastern Time (US and Canada) -- **Meeting Link:** [Zoom Meeting](https://zoom.us/j/92729235315?pwd=ZFIxU3RSanlVODh4a1g2SFdJOGpoZz09) +- **Meeting Link:** [Zoom Meeting](https://zoom-lfx.platform.linuxfoundation.org/meeting/94852354733?password=c99601ab-0a5a-4ea9-98e3-af9d12c59547) - **Meeting Notes:** [Meeting Notes Link](https://docs.google.com/document/d/1z9xvt-Z97j4CtEH1-nR9sMWul7jQkUi_fNY7BdMPgxM/edit#heading=h.88owgl3gm8w4) - **Calendar Invite:** See [CNCF calendar](https://calendar.google.com/calendar/u/0/embed?src=0b8u5el8ta4s93t2cm72tuvhhk@group.calendar.google.com&ctz=America/Los_Angeles) for invite diff --git a/community/working-groups/compliance/content/readme.md b/community/working-groups/compliance/content/readme.md new file mode 100644 index 000000000..fcb97a300 --- /dev/null +++ b/community/working-groups/compliance/content/readme.md @@ -0,0 +1,3 @@ +# Folder for Compliance WG Content + +This folder contains content created by Compliance WG diff --git a/community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf b/community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf index a6ca03245..c3c6b99f8 100644 Binary files a/community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf and b/community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf differ diff --git a/community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory.md b/community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory.md index 4ab395cbc..dc86184ff 100644 --- a/community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory.md +++ b/community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory.md @@ -1,7 +1,7 @@ # Introduction -A software supply chain is the series of steps performed when writing, testing, packaging, and distributing application software to end consumers. Given the increased prominence of software supply chain exploits and attacks, the [Cloud Native Computing Foundation (CNCF) Technical Advisory Group for Security](https://github.com/cncf/tag-security) published a whitepaper titled [“Software Supply Chain Best Practices”](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf), which captures over 50 recommended practices to securing the software supply chain. That document is considered a prerequisite for the content described in this reference architecture. +A software supply chain is the series of steps performed when writing, testing, packaging, and distributing application software to end consumers. Given the increased prominence of software supply chain exploits and attacks, the [Cloud Native Computing Foundation (CNCF) Technical Advisory Group for Security](https://github.com/cncf/tag-security) published a whitepaper titled [“Software Supply Chain Best Practices”](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf), which captures over 50 recommended practices to securing the software supply chain. That document is considered a prerequisite for the content described in this reference architecture. This publication is a follow-up to that paper, targeted at system architects, developers, operators, and engineers in the areas of software development, security and compliance. This reference architecture adopts the “Software Factory” model[^1] for designing a secure software supply chain. @@ -124,7 +124,7 @@ In the matrix below, we attempt to overlay these entities, concerns, and activit -This reference architecture focuses specifically on the critical concern of provenance and primarily on the activity stage of the “build.” There are numerous other publications and guides which address issues around trustworthiness, including practices like SAST/DAST scanning, code signing, etc, including the [CNCF Software Supply Chain Best Practices Paper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf). We direct readers to these documents for more information on those facets of supply chain security. +This reference architecture focuses specifically on the critical concern of provenance and primarily on the activity stage of the “build.” There are numerous other publications and guides which address issues around trustworthiness, including practices like SAST/DAST scanning, code signing, etc, including the [CNCF Software Supply Chain Best Practices Paper](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf). We direct readers to these documents for more information on those facets of supply chain security. Our decision to emphasize provenance and the build pipeline in this paper is based on the foundational role provenance verification plays in other supply chain security concerns. Provenance provides the evidence, for example, that SAST/DAST scanning was completed as claimed. If you are relying on the results of SAST/DAST scans of a software artefact to inform your decision on its trustworthiness, you need to know that those claims are accurate. Provenance provides that assurance. It also provides assurance that an artefact which claims to be the product of a specific codebase and a specific build process is in fact the product it claims to be or that the artefact downloaded from a remote source is the same one you expected to receive. All of these claims are foundational to being able to make informed decisions about an artefact's trustworthiness: you must be able to trust the evidence presented about an artefact’s trustworthiness is valid evidence before you can trust the claims that evidence makes about the artefact. diff --git a/community/working-groups/supply-chain-security/supply-chain-security-paper/README.md b/community/working-groups/supply-chain-security/supply-chain-security-paper/README.md index 363848536..18b8f7a8c 100644 --- a/community/working-groups/supply-chain-security/supply-chain-security-paper/README.md +++ b/community/working-groups/supply-chain-security/supply-chain-security-paper/README.md @@ -64,4 +64,4 @@ approval on the PR. At which point the markdown state will be changed to Links: * [Managed version in Markdown](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md) -* [Final PDF](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) +* [Final PDF](https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) diff --git a/docker-compose.yml b/docker-compose.yml index a35f2433a..b79fec1c9 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -1,22 +1,22 @@ --- services: setup: - image: node:18 + image: node:22 working_dir: /usr/src/app volumes: - "${PWD}:/usr/src/app" lint: - image: node:18 + image: node:22 working_dir: /usr/src/app volumes: - "${PWD}:/usr/src/app" spelling: - image: node:18 + image: node:22 working_dir: /usr/src/app volumes: - "${PWD}:/usr/src/app" links: - image: node:18 + image: node:22 working_dir: /usr/src/app volumes: - "${PWD}:/usr/src/app" diff --git a/project-resources/moving-levels-review-template.md b/project-resources/moving-levels-review-template.md index a160e5b7d..e5d774b1b 100644 --- a/project-resources/moving-levels-review-template.md +++ b/project-resources/moving-levels-review-template.md @@ -1,4 +1,4 @@ -# Template for TAG recommendation to TOC +# TAG recommendation to TOC ## Project Overview @@ -8,13 +8,17 @@ What ecosystem adoption has the project seen? ### Past TOC Reviews -How has the project addressed comments from previous reviews (incubation if graduation, sandbox if incubating, etc)? +If the project has undergone a previous TAG or TOC review, how has the project addressed comments from those reviews? ## Security Reviews ### TAG Security Assessments -Has the project completed a TAG Security Self-Assessment and/or Joint Assessment? If yes, please add a link and discuss how this has impacted their security posture. +If applying for incubation, has the project completed a self-assessment? _(If not, the TAG cannot provide any recommendation to the TOC.)_ + +If applying for graduation, has the project completed a joint assessment? _(If not, the TAG cannot provide any recommendation to the TOC.)_ + +If yes to either, were there any findings or recommendations that the project has addressed or added to a roadmap? Please provide links if applicable. ### Security Audit @@ -24,14 +28,34 @@ Has the project completed an external security audit? If yes, how have they addr ### Metrics -Which security best practices does the project follow (for example CNCF best practices badge, OpenSSF Best Practices, CLO monitor), and how does it rate by these metrics? +Which security best practices does the project follow (for example CNCF best practices badge, OpenSSF Best Practices, LFX Insights, CLOmonitor)? + +How does it rate by these metrics? Please provide links if applicable. ### Static Analysis -Does the project perform static analysis? +Does the project perform static analysis such as SAST or SCA? Please provide links if applicable. ## Sub-project Considerations +### Role of Sub-projects in the Project Ecosystem + +Does your project have sub-projects? If so, how do they interact with the main project? + +What is the maturity and adoption of each sub-project? + +Please provide links to any sub-projects that are compiled into the main project. + +Please provide links to any other sub-projects that are currently intended for end-user adoption. + +### Security Posture of Sub-projects + If the project has sub-projects, how does their security posture compare to the base project? ## TAG Recommendation to the TOC + + + + + + diff --git a/website/layouts/partials/head.html b/website/layouts/partials/head.html index 1d11449df..dfc1002f1 100644 --- a/website/layouts/partials/head.html +++ b/website/layouts/partials/head.html @@ -16,6 +16,7 @@ {{- partial "twitter_cards.html" . -}} + {{ if hugo.IsProduction }} diff --git a/website/package-lock.json b/website/package-lock.json index 3a00ccb18..721b32c5f 100644 --- a/website/package-lock.json +++ b/website/package-lock.json @@ -1276,11 +1276,11 @@ } }, "node_modules/micromatch": { - "version": "4.0.5", - "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz", - "integrity": "sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==", + "version": "4.0.8", + "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.8.tgz", + "integrity": "sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==", "dependencies": { - "braces": "^3.0.2", + "braces": "^3.0.3", "picomatch": "^2.3.1" }, "engines": {