📚 Sync documentation from source-docs

Source: chore: Sync workflow to release-4.0 and small doc fix (#191)
Author: Daniel Filipe Bruehmueller Morinigo
Commit: 1e192edf37f1359d3c6faee623e5407cbcebdb59

This commit automatically syncs documentation changes from the source-docs repository.

🔗 View source commit: https://github.com/alaudadevops/tektoncd-operator/commit/1e192edf37f1359d3c6faee623e5407cbcebdb59
🤖 Synced on 2025-07-02 07:57:39 UTC

Author: web-flow

.github/SYNC_INFO.md

@@ -1,10 +1,10 @@
 # Documentation Sync Information
 
-- **Last synced**: 2025-07-02 06:41:21 UTC
+- **Last synced**: 2025-07-02 07:57:39 UTC
 - **Source repository**: alaudadevops/tektoncd-operator
-- **Source commit**: [35c2fc38ce5a3fd145e64a1e22acf30ae7ce9d1b](https://github.com/alaudadevops/tektoncd-operator/commit/35c2fc38ce5a3fd145e64a1e22acf30ae7ce9d1b)
-- **Triggered by**: lentil1016
-- **Workflow run**: [#4](https://github.com/alaudadevops/tektoncd-operator/actions/runs/16017978615)
+- **Source commit**: [1e192edf37f1359d3c6faee623e5407cbcebdb59](https://github.com/alaudadevops/tektoncd-operator/commit/1e192edf37f1359d3c6faee623e5407cbcebdb59)
+- **Triggered by**: danielfbm
+- **Workflow run**: [#6](https://github.com/alaudadevops/tektoncd-operator/actions/runs/16019422334)
 
 ## Files synced:
 - docs/

docs/en/chains/architecture.mdx

@@ -84,8 +84,6 @@ Tekton Chains is deployed as a Kubernetes controller within a cluster:
 - **Deployment**: A single deployment manages the controller pods
 - **Service Account**: The controller uses a dedicated service account with appropriate permissions
 - **Configuration**: Configuration is managed through a ConfigMap called `chains-config`
-    - By default, Tekton Chains is deployed automatically through the `TektonConfig` resource. You can modify the `TektonConfig` resource to configure Chains.
-    - Essentially, Tekton Operator will synchronize the Chains configuration from the `TektonConfig` resource to the `TektonChains` resource, and finally reflect in the `chains-config` ConfigMap.
 - **Secrets**: Signing keys and credentials are stored as Kubernetes secrets
 
 ### High Availability Considerations

docs/en/chains/concepts/core_concepts.mdx

@@ -8,98 +8,21 @@ weight: 10
 
 Supply chain security refers to protecting the integrity, security, and reliability of the software development lifecycle from development to deployment. Tekton Chains is designed to address supply chain security concerns by providing mechanisms to verify that artifacts produced by CI/CD pipelines have not been tampered with and can be trusted.
 
-## SLSA Framework
-
-SLSA (Supply-chain Levels for Software Artifacts) is a security framework that provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. Tekton Chains supports multiple SLSA provenance formats:
-
-- **SLSA v0.2**: Supported via `slsa/v1` or `in-toto` formatters
-- **SLSA v1.0**: Supported via `slsa/v2alpha3` and `slsa/v2alpha4` formatters
-
-As part of the framework, SLSA has multiple levels of assurances. These levels contain industry-recognized best practices to create four levels of increasing assurance.
-
-> [Security levels](https://slsa.dev/spec/v1.1/levels)
-
-| Track/Level | Requirements | Focus |
-| ----------- | ------------ | ----- |
-| Build L0    | (none)       | (n/a) |
-| Build L1    | Provenance showing how the package was built | Mistakes, documentation |
-| Build L2    | Signed provenance, generated by a hosted build platform | Tampering after the build |
-| Build L3    | Hardened build platform | Tampering during the build |
-
-> Tekton can achieve SLSA Level 2 compliance. For more information, please refer to [Getting To SLSA Level 2 with Tekton and Tekton Chains](https://tekton.dev/blog/2023/04/19/getting-to-slsa-level-2-with-tekton-and-tekton-chains/)
-
-## Signing
+## Provenance
 
-Signing is the process of cryptographically signing provenance to ensure its integrity and authenticity. Tekton Chains supports multiple signing methods:
-
-- **x509**: Uses a standard x509 certificate and private key
-- **Cosign**: Uses Sigstore's Cosign tool for signing
-- **KMS**: Uses cloud provider key management services
-- **Keyless**: Uses ephemeral keys with Fulcio certificate authority
-
-## Image attestation
-
-Image attestation is used for storing and verifying metadata information related to images. It provides richer supply chain security information, such as:
-
-- [SLSA Provenance](#slsa-provenance)
-- [SBOM](#sbom-software-bill-of-materials)
-- [Vulnerability scan results](#vulnerability-scan-results)
-- [Custom metadata](#custom-metadata-attestation)
-
-### SLSA Provenance
-
-[SLSA Provenance](https://slsa.dev/provenance/v1) is metadata containing verifiable information about software artifacts, describing how they were built, what sources were used, and who built them. In Tekton Chains, provenance is cryptographically signed to ensure its integrity and authenticity.
+Provenance is metadata containing verifiable information about software artifacts, describing how they were built, what sources were used, and who built them. In Tekton Chains, provenance is cryptographically signed to ensure its integrity and authenticity.
 
 There are two types of provenance in Tekton Chains:
 
 - **Task-level provenance**: Captures details about a specific TaskRun execution
 - **Pipeline-level provenance**: Captures the entire PipelineRun execution, including all child TaskRuns
 
-### SBOM (Software bill of materials)
-
-[SBOM](https://www.ntia.gov/page/software-bill-materials) is a nested inventory for software, a list of ingredients that make up software components, including:
-- Software components
-- Component versions
-- License information
-- Dependency relationships
-
-SBOM can be in various formats, such as:
-- [SPDX](https://spdx.dev/use/specifications/)
-- [CycloneDX](https://cyclonedx.org/specification/overview/)
-
-### Vulnerability scan results
-
-[Cosign Vulnerability Scan results](https://github.com/sigstore/cosign/blob/main/specs/COSIGN_VULN_ATTESTATION_SPEC.md) record the security assessment of the software build process, including:
-- Scanner information (name, version)
-  - Vulnerability database information
-- List of discovered vulnerabilities and their severity
-- Remediation recommendations
-
-### Custom metadata
-
-Custom metadata can be added as needed to support specific security requirements.
-
-For example, grype can generate vulnerability scan results, and these results can be uploaded to the image registry as a custom type.
-
-## Attestation verification
-
-The verification mechanism is highly flexible and can be customized to validate any metadata present in the attestation. This means that any information stored in the attestation can be used as validation criteria, allowing organizations to implement precise security controls based on their specific requirements.
-
-The flexibility of attestation verification is demonstrated through various validation methods:
-
-- Kyverno [JMESPath](https://jmespath.org/) Validation
-   - Uses JMESPath syntax for JSON query and validation
-
-- [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) Policy Validation
-   - Leverages Open Policy Agent (OPA) for complex policy enforcement
-   - Supports declarative policy rules and custom validation logic
-   - Example: Validating builder information and build environment
+## SLSA Framework
 
-- [CUE](https://cuelang.org/) Validation
-   - Provides type system and constraint system for validation
-   - Enables schema validation and data consistency checks
-   - Supports complex data structure validation
+SLSA (Supply-chain Levels for Software Artifacts) is a security framework that provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. Tekton Chains supports multiple SLSA provenance formats:
 
+- **SLSA v0.2**: Supported via `slsa/v1` or `in-toto` formatters
+- **SLSA v1.0**: Supported via `slsa/v2alpha3` and `slsa/v2alpha4` formatters
 
 ## Artifacts
 
@@ -117,6 +40,15 @@ Type hinting is a mechanism used by Tekton Chains to understand the input and ou
 - For image outputs: `IMAGES` or parameters/results with the suffix `IMAGE_URL` and `IMAGE_DIGEST`
 - For generic outputs: Parameters or results with the suffix `ARTIFACT_OUTPUTS`
 
+## Signing
+
+Signing is the process of cryptographically signing provenance to ensure its integrity and authenticity. Tekton Chains supports multiple signing methods:
+
+- **x509**: Uses a standard x509 certificate and private key
+- **Cosign**: Uses Sigstore's Cosign tool for signing
+- **KMS**: Uses cloud provider key management services
+- **Keyless**: Uses ephemeral keys with Fulcio certificate authority
+
 ## Storage Backends
 
 Storage backends are where Tekton Chains stores the generated provenance and signatures. Supported backends include: