chore(docs): migrate WASMEdge and Kyverno security assessments

projects/kyverno/security-assessment/self-assessment.md

@@ -4,7 +4,7 @@
 |**Completed**:               | *tbd*                                 |
 |-----------------------------|---------------------------------------|
 |**Security reviewer(s)**:    | <!-- cspell:disable --> John Kinsella, Wesley Steehouwer (@dutchshark) |
-|**Project security lead**:   | <!-- cspell:disable --> Jim Bugwadia  |
+|**Project security lead**:   | <!-- cspell:disable --> Jim Bugwadia, Shuting Zhao  |
 | **Source code**:            | https://github.com/kyverno/kyverno    |
 | **Web site**:               | https://kyverno.io/                   |
 
@@ -44,7 +44,7 @@
 
 ## Overview
 
-Kyverno helps secure and automates Kubernetes configurations using policies defined as Kubernetes custom resources. It operates as an Kubernetes admission controller and a command-line for off-cluster use.
+Kyverno helps secure and automates configurations using policies defined as Kubernetes custom resources. It operates as a Kubernetes admission controller and provides command-line tools for off-cluster use. Additionally, Kyverno has been extended with new policy types (`ValidatingPolicy`, `ImageValidatingPolicy`, `MutatingPolicy`) that utilize CommonExpressionLanguage (CEL) to support non-Kubernetes resources, enabling policy validation for any JSON or YAML payload including Terraform files, Dockerfiles, cloud configurations, and service authorization requests.
 
 ### Background
 
@@ -55,28 +55,28 @@ While this is powerful, it also creates a few challenges:
 2. Kubernetes configurations are not secure by default. Security and best practices need to be configured for workloads.
 3. A resource's configurations is shared across organizational roles (dev-sec-ops) and chances of misconfigurations, or lack of proper configuration, increase as there is no clear ownership. Whether developers, operators, or security engineers are responsible for more `advanced` configuration settings may not be obvious.
 
-### Goal
+### Goals
 
-The goal of the Kyverno project is to simplify Kubernetes configuration security and automate processes that otherwise require manual handoffs and coordination across Kubernetes cluster operators and developers.
+The goal is to enforce security policies across Kubernetes resources to prevent insecure configurations and ensure compliance. User-defined YAML and CEL policies are enforced through admission control to prevent non-compliant Kubernetes resources from being created or modified, providing immediate feedback to users. If the admission controller is unavailable, CLI tools and background scanning provide alternative enforcement mechanisms to maintain security posture. Kyverno also provides automation through mutation and generation capabilities to automatically fix configurations and create required resources, simplifying security management. CLI tools extend this enforcement to non-Kubernetes resources like Terraform files and Dockerfiles.
 
 ### Non-goals
 
-Kyverno is not a general purpose policy engine i.e. it is not designed for use outside of Kubernetes.
+Kyverno is NOT designed to address Kubernetes security flaws, as it cannot protect against vulnerabilities in the Kubernetes API server or underlying infrastructure and Kyverno's policy enforcement may be bypassed if Kubernetes has a security flaw. Kyverno does not enforce security requirements that weren't explicitly defined, it enforces only the policies that users define. Kyverno does not replace Kubernetes RBAC, as RBAC controls access while Kyverno enforces policy compliance. Kyverno also does not replace Kubernetes' built-in policy controls like ValidatingAdmissionPolicies and MutatingAdmissionPolicies, but complements these native controls with additional features such as comprehensive reporting, exception management, and periodic scanning.
 
 ## Self-assessment use
 
-This self-assessment is created by the Kyverno team to perform an internal analysis of the
-project's security.  It is not intended to provide a security audit of Kyverno, or
+This self-assessment is created by the Kyverno team to perform an internal analysis of the 
+project's security. It is not intended to provide a security audit of Kyverno, or 
 function as an independent assessment or attestation of Kyverno's security health.
 
-This document serves to provide Kyverno users with an initial understanding of
-Kyverno's security, where to find existing security documentation, Kyverno plans for
-security, and general overview of Kyverno security practices, both for development of
+This document serves to provide Kyverno users with an initial understanding of Kyverno's 
+security, where to find existing security documentation, Kyverno plans for 
+security, and general overview of Kyverno security practices, both for development of 
 Kyverno as well as security of Kyverno.
 
-This document provides the CNCF SIG-Security with an initial understanding of Kyverno
-to assist in a joint-review, necessary for projects under incubation.  Taken
-together, this document and the joint-review serve as a cornerstone for if and when
+This document provides the CNCF TAG-Security with an initial understanding of Kyverno
+to assist in a joint-review, necessary for projects under incubation. Taken 
+together, this document and the joint-review serve as a cornerstone for if and when 
 Kyverno seeks graduation and is preparing for a security audit.
 
 
@@ -86,43 +86,79 @@ The following diagram shows the logical architecture for Kyverno. Each major com
 
 ![Kyverno Logical Architecture](images/kyverno-architecture.png)
 
-### Webhook
+Kyverno consists of four main controllers that work together to provide comprehensive policy management capabilities. Each controller handles specific aspects of policy processing, from admission control to background operations and cleanup tasks.
 
-The `Webhook` component registers as a validating and mutating admission webhook and receives `AdmissionReview` requests from the API server to validate and mutate configuration changes, based on policies. Users can configure which namespaces and resources the webhooks will receive via command line options or the ConfigMap.
+### Admission Controller 
 
-The `Webhook` also creates and updates `GenerateRequest` and `PolicyChangeRequest` resources to trigger updates via other Kyverno controllers.
+* Receives AdmissionReview requests from the Kubernetes API server through validating and mutating webhooks.
+* Processes validate, mutate, and image validating rules.
+* Manages and renews certificates as Kubernetes Secrets for webhook use through the embedded Cert Renewer.
+* Manages and configures webhook rules dynamically based on installed policies through the embedded Webhook Controller.
+* Performs policy validation for the `Policy`, `ClusterPolicy`, `ValidatingPolicy`, `ImageValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, and `PolicyException` custom resources.
+* Processes Policy Exceptions.
+* Generates `EphemeralReport` and `ClusterEphemeralReport` intermediary resources for further processing by the Reports Controller.
+* Generates `UpdateRequest` intermediary resources for further processing by the Background Controller.
 
-### Webhook Monitor
+### Reports Controller 
 
-On startup, Kyverno's `Webhook Monitor` component generates a self-signed certificate (or uses a user-provided certificate) and auto-creates the webhook configurations required to register Kyverno as an admission webhook. The component also periodically monitors if Kyverno is receiving webhook events and recreates the certificate and webhook configurations if needed.
+* Responsible for creation and reconciliation of the final `PolicyReport` and `ClusterPolicyReport` custom resources.
+* Performs background scans and generates, processes, and converts `EphemeralReport` and `ClusterEphemeralReport` intermediary resources into the final policy report resources.
 
-### Generate Controller
+### Background Controller 
 
-The `Generate Controller` watches `GenerateRequest` resources and creates, updates, and deletes Kubernetes resources based on Kyverno [generate rules](https://kyverno.io/docs/writing-policies/generate/). The `Generate Controller` also watches for changes in policy definitions to update generated resources.
+* Processes generate and mutate-existing rules of the `Policy` or `ClusterPolicy`, and the mutate-existing functionality of the `MutatingPolicy` and `GeneratingPolicy`.
+* Processes policy add, update, and delete events.
+* Processes and generates `UpdateRequest` intermediary resources to generate or mutate the final resource.
+* Generates `EphemeralReport` and `ClusterEphemeralReport` intermediary resources for further processing by the Reports Controller.
 
-### Policy Controller
+### Cleanup Controller 
 
-The `Policy Controller` performs periodic background scans on existing configurations and creates or updates policy reports based on changes and background scans. The `Policy Controller` watches `ReportChangeRequest` resources and creates, updates, and delete Kyverno [Policy Report](https://kyverno.io/docs/policy-reports/) resources. The `Policy Controller` also watches for changes in policies definitions to update policy reports.
+* Processes `CleanupPolicy` and `DeletingPolicy` resources.
+* Performs policy validation for the CleanupPolicy and ClusterCleanupPolicy custom resources through a webhook server.
+* Reconciles its webhook through a webhook controller.
+* Manages and renews certificates as Kubernetes Secrets for use in the webhook.
+* Creates and reconciles CronJobs used as the mechanism to trigger cleanup.
+* Handles the cleanup by deleting resources from the Kubernetes API.
 
 ## Physical Architecture
 
-Kyverno can be installed using a [Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) or YAML files (see [installation doc](https://kyverno.io/docs/installation/)).  
-
-The Kyverno application consists of a:
-1. Service
-2. Deployment
-3. Roles
-4. Role Bindings
-5. Custom Resource Definitions
-6. Service account
-
-When Kyverno runs, it will check for a named `Secret` with a certificate to use for webhook registration. If the secret does not exist, Kyverno will generate a self-signed certificate and store it in the secret. Kyverno will then generate or update the mutating and validating webhook configurations.
+Kyverno can be installed using a [Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) or YAML files (see [installation doc](https://kyverno.io/docs/installation/)).
 
 The diagram below shows the Kyverno physical architecture:
 
 ![Kyverno Physical Architecture](images/kyverno-physical-architecture.png)
 
-**NOTE:** Currently Kyverno runs as one multi-instance (HA) `Pod` managed by a single `Deployment`. In the future the different controllers may be packaged in separate deployments to allow flexibility in scaling and tuning each component.
+A standard Kyverno installation consists of a number of different components, some of which are optional:
+
+**Deployments**
+* Admission controller (required): The main component of Kyverno which handles webhook callbacks from the API server for verification, mutation, Policy Exceptions, and the processing engine.
+* Background controller (optional): The component responsible for processing of generate and mutate-existing rules.
+* Reports controller (optional): The component responsible for handling of Policy Reports.
+* Cleanup controller (optional): The component responsible for processing of Cleanup Policies and Deleting Policies.
+
+**Services**
+* Services needed to receive webhook requests.
+* Services needed for monitoring of metrics.
+
+**ServiceAccounts**
+* One ServiceAccount per controller to segregate and confine the permissions needed for each controller to operate on the resources for which it is responsible.
+
+**ConfigMaps**
+* ConfigMap for holding the main Kyverno configuration.
+* ConfigMap for holding the metrics configuration.
+
+**Secrets**
+* Secrets for webhook registration and authentication with the API server.
+
+**Roles and Bindings**
+* Roles and ClusterRoles, Bindings and ClusterRoleBindings authorizing the various ServiceAccounts to act on the resources in their scope.
+
+**Webhooks**
+* ValidatingWebhookConfigurations for receiving both policy and resource validation requests.
+* MutatingWebhookConfigurations for receiving both policy and resource mutating requests.
+
+**CustomResourceDefinitions**
+* CRDs which define the custom resources corresponding to policies, reports, and their intermediary resources.
 
 ## Security functions and features
 
@@ -145,7 +181,7 @@ Kyverno does not currently document meeting particular compliance standards.
 
 ## Secure development practices
 
-The Kyverno project follows established CNCF and OSS best practices for code development and delivery:
+The Kyverno project follows established CNCF and OSS best practices for code development and delivery.
 
 ### Development Pipeline
 
@@ -157,7 +193,7 @@ The [Kyverno container images](https://github.com/orgs/kyverno/packages) are hos
 
 The [Kyverno Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) is hosted in ArtifactHub. There is a pending issue to to sign the Helm Chart using Sigstore Cosign (https://github.com/kyverno/kyverno/issues/2758).
 
-The [Kyverno installation YAMLs](https://github.com/kyverno/kyverno/blob/main/definitions/install.yaml) are hosted in the GitHub repository.
+The [Kyverno installation YAMLs](https://github.com/kyverno/kyverno/blob/main/config/install-latest-testing.yaml) are hosted in the GitHub repository.
 
 A Software Bill of Materials (SBOM) is produced and made available for each release (https://main.kyverno.io/docs/security/#fetching-the-sbom-for-kyverno).
 
@@ -187,9 +223,9 @@ All Kyverno security related issues (both fixes and enhancements) are labeled wi
   https://github.com/kyverno/kyverno/labels/security
 
 
-### [CII Best Practices](https://www.coreinfrastructure.org/programs/best-practices-program/)
+### [CII Best Practices](https://www.bestpractices.dev/)
 
-The Kyverno project has adopted the OSSF/Scorecard and is tracking progress in [issue #2617](https://github.com/kyverno/kyverno/issues/2617).
+The Kyverno project has passed the OpenSSF Scorecard check and is actively working towards achieving silver/gold level certification. Progress is being tracked via [issue 10908](https://github.com/kyverno/kyverno/issues/10908).
 
 ### Related Projects / Vendors
 

projects/wasmedge/security-assessment/joint-assessment.md

@@ -0,0 +1,53 @@
+# WasmEdge TAG-Security Security Assessment
+<!-- cSpell:ignore Ying Shen Hsieh ibmibmibm hydai wasmedge Constanze Röedig entlein Camila Vilarinho camilaavilarinho victorjunlu Meng WASI crun userbase Uptane wasi-->
+
+Completed: 01 07 2025
+
+Security reviewers: Justin Cappos @JustinCappos, Marina Moore @mnm678, Constanze Röedig @entlein, Camila Vilarinho @camilaavilarinho, and Victor Lu @victorjunlu
+
+Project security lead: Hung-Ying Tai @hydai
+
+Project team: Hung-Ying Tai @hydai, Meng-Han Lee @dm4
+
+* Source code: <https://github.com/WasmEdge/WasmEdge>
+* Web site: <https://wasmedge.org/>
+
+## Summary
+
+The project has built a reasonably secure system with appropriate security controls. However, the security limitations, testing requirements, and benefits could be better communicated to users. Additional focus on going above common recommendations would strengthen the project's security posture. The assessment team appreciates WasmEdge's cooperation in answering questions and clarifying the self-assessment document.
+
+## Recommendations
+
+### CNCF recommendations
+
+* Improve documentation translation across languages, especially into English
+* Consider adopting CNCF security best practices for software supply chain attestations (in-toto/SLSA)
+* Explore integration with CNCF security projects like SPIFFE/SPIRE for workload identity
+
+### Project recommendations
+
+1. The document needs to clearly say about whether you add a formal verifier for your runtime.   What do other runtimes provide to validate they are correctly implementing the WASM spec?
+2. Have you done validation of how you’re using WASI, what interfaces you are providing, their security, etc.?  For example, as an illustrative example, can you explain how you’ve validated that your \--dir interface doesn’t have path traversal vulnerabilities?  What is the guidance you give to users who want to use this interface to make sure they do so securely?   Are they free to add symlinks / mount file systems, etc. into that part of the directory namespace, etc.?  
+3. Does the fact that WASI isn’t portable and has a lot of undefined behavior give users any security concerns?  
+4. How are you doing updates of your core functionality on the device?  [https://uptane.org/](https://uptane.org/)
+   or [https://theupdateframework.com/](https://theupdateframework.com/)
+5. Do you (or should you) be attesting to the software running on the edge device?   Are you doing software supply chain attestations (in-toto / SLSA, etc.)?   Would this be helpful / useful?  Would users expect this functionality?  Consider:   [https://github.com/in-toto/in-toto](https://github.com/in-toto/in-toto)  [https://datatracker.ietf.org/group/scitt/about/](https://datatracker.ietf.org/group/scitt/about/)  [https://slsa.dev/](https://slsa.dev/)
+6. Please explain clearly about how one would use things like non-human identities, monitoring, security filtering, etc. Is everything completely compatible with SPIFFE/SPIRE?  Are there any differences in use in comparison to e.g.:    [https://wasmcloud.com/blog/2025-03-04-why-were-adopting-spiffe-for-webassembly-workload-identity/](https://wasmcloud.com/blog/2025-03-04-why-were-adopting-spiffe-for-webassembly-workload-identity/)
+7. What should users be thinking about with respect to data residency and jurisdictional constraints when processing sensitive data in WasmEdge?  How does being at the edge change this equation?  
+8. Please, add to the main body of the document (and on github)  
+   \- how you ensure continuous verification/testing of the WASM specification of all components (the Verifier, the Loader, the Engine \- every main component in scope of WASM-Edge).  
+   Example:
+   Where Side Channel Attacks are tested against and how the code verifiably written in  “side-channel resistant” way.  [https://github.com/WebAssembly/constant-time/blob/main/proposals/constant-time/Overview.md](https://github.com/WebAssembly/constant-time/blob/main/proposals/constant-time/Overview.md)
+   Can you add to the document for each major attack-class: how is it being tested/fuzzed and can you show in your repo/artifacts, and comment how you’d resolve any failures.  
+9. Ensure that it is clear why you are having failures on tests when building the code.   Your code is being pushed to production regardless.   Why is this appropriate?  
+10. The project could benefit from more effort to explain the security aspects of their design to their userbase.
+11. The project would benefit from putting a link (and also a github-badge) in the main-README that goes directly to the security testing/definitions.  Fixed by [https://github.com/WasmEdge/WasmEdge/pull/4216](https://github.com/WasmEdge/WasmEdge/pull/4216)
+
+### Additional recommendations
+
+* Consider implementing Uptane or TUF for secure updates of core functionality on edge devices
+* Evaluate implementing software attestation for edge device workloads
+* Provide clearer guidance on data residency and jurisdictional constraints for sensitive data processing
+
+Tracking issue: <https://github.com/WasmEdge/WasmEdge/issues/4237>
+Tracking project board: <https://github.com/orgs/WasmEdge/projects/14>