diff --git a/.github/workflows/wc-build-push-test.yml b/.github/workflows/wc-build-push-test.yml index 7fa64260..332a2fc8 100644 --- a/.github/workflows/wc-build-push-test.yml +++ b/.github/workflows/wc-build-push-test.yml @@ -134,6 +134,7 @@ jobs: runner-labels: ${{ inputs.runner-labels }} build-test-runner-labels: ${{ inputs.build-test-runner-labels }} + # @sbdl test-compat-0001 is test { custom:title is "Docker runtime compatibility"; requirement is req-compat-0001 } integration-test-docker: name: 🧪 if: ${{ inputs.integration-test-file }} @@ -150,6 +151,7 @@ jobs: registry: ${{ inputs.registry }} test-file: ${{ inputs.integration-test-file }} + # @sbdl test-compat-0002 is test { custom:title is "Podman runtime compatibility"; requirement is req-compat-0001 } integration-test-podman: name: 🧪 if: ${{ inputs.integration-test-file && inputs.integration-test-podman }} diff --git a/.github/workflows/wc-build-push.yml b/.github/workflows/wc-build-push.yml index 8d725810..1a62ef52 100644 --- a/.github/workflows/wc-build-push.yml +++ b/.github/workflows/wc-build-push.yml @@ -254,6 +254,7 @@ jobs: subject-digest: ${{ steps.inspect-manifest.outputs.digest }} show-summary: false push-to-registry: true + # @sbdl test-sec-0001 is test { custom:title is "Verify attestation"; requirement is req-sec-0002 } - name: Verify attestation run: gh attestation verify --repo "${GH_REPO}" --signer-workflow philips-software/amp-devcontainer/.github/workflows/wc-build-push.yml "oci://${FULLY_QUALIFIED_IMAGE_NAME}@${DIGEST}" env: diff --git a/.github/workflows/wc-document-generation.yml b/.github/workflows/wc-document-generation.yml index 0683f8cb..bed8aba8 100644 --- a/.github/workflows/wc-document-generation.yml +++ b/.github/workflows/wc-document-generation.yml @@ -31,7 +31,7 @@ jobs: sudo apt-get update && sudo apt-get install --no-install-recommends -y plantuml python -m pip install sbdl==1.22.7 - name: Build & Validate SBDL model - run: sbdl -m compile test/cpp/integration-tests.bats test/cpp/features/*.feature test/embedded-cpp/integration-tests.bats test/embedded-cpp/features/*.feature > amp-devcontainer.sbdl + run: sbdl -m compile -r . > amp-devcontainer.sbdl - name: Create document control context env: GITHUB_REF_NAME: ${{ github.ref_name }} @@ -54,18 +54,18 @@ jobs: SBDL - name: 📄 Generate SRS document run: sbdl -m template-fill --set-config template_extensions_file docs/templates/jinja-extensions.py --template docs/templates/software-requirements-specification.md.j2 amp-devcontainer.sbdl document-control.sbdl > software-requirements-specification.md - - name: 🧪 Generate STP document - run: sbdl -m template-fill --set-config template_extensions_file docs/templates/jinja-extensions.py --template docs/templates/software-test-plan.md.j2 amp-devcontainer.sbdl document-control.sbdl > software-test-plan.md + - name: 🧪 Generate SVP document + run: sbdl -m template-fill --set-config template_extensions_file docs/templates/jinja-extensions.py --template docs/templates/software-verification-plan.md.j2 amp-devcontainer.sbdl document-control.sbdl > software-verification-plan.md - name: 🧩 Generate RTM document run: sbdl -m template-fill --set-config template_extensions_file docs/templates/jinja-extensions.py --template docs/templates/requirements-traceability-matrix.md.j2 amp-devcontainer.sbdl document-control.sbdl > requirements-traceability-matrix.md - name: 📄 Generate SRS PDF uses: docker://pandoc/extra:3.9.0.0-ubuntu@sha256:72afa9c8d3300e5f10c9c4330e101725687f2179bffd912fb859c6d2ae85de62 with: args: --template eisvogel --syntax-highlighting idiomatic --number-sections --output software-requirements-specification.pdf software-requirements-specification.md - - name: 🧪 Generate STP PDF + - name: 🧪 Generate SVP PDF uses: docker://pandoc/extra:3.9.0.0-ubuntu@sha256:72afa9c8d3300e5f10c9c4330e101725687f2179bffd912fb859c6d2ae85de62 with: - args: --template eisvogel --syntax-highlighting idiomatic --number-sections --output software-test-plan.pdf software-test-plan.md + args: --template eisvogel --syntax-highlighting idiomatic --number-sections --output software-verification-plan.pdf software-verification-plan.md - name: 🧩 Generate RTM PDF uses: docker://pandoc/extra:3.9.0.0-ubuntu@sha256:72afa9c8d3300e5f10c9c4330e101725687f2179bffd912fb859c6d2ae85de62 with: diff --git a/docs/templates/software-requirements-specification.md.j2 b/docs/templates/software-requirements-specification.md.j2 index b93bf0d5..eb65900c 100644 --- a/docs/templates/software-requirements-specification.md.j2 +++ b/docs/templates/software-requirements-specification.md.j2 @@ -26,35 +26,51 @@ footer-right: "\\thepage \\hspace{1pt} of \\pageref*{lastpage}" ## Purpose -This document describes the software system requirements for amp-devcontainer. +This document defines the software system requirements for amp-devcontainer. +It establishes the functional and non-functional requirements the system shall satisfy and provides the basis for verification, traceability, and change control activities throughout the software lifecycle. + +## Abstract + +amp-devcontainer is a set of Development Containers ([devcontainers](https://containers.dev/)) tailored towards modern software development. + +The containers may be used for both local development and continuous integration workflows. + +amp-devcontainer is intended as a general-purpose development environment and is not tied to a specific regulated use case. +The project follows a "qualification-friendly by design" philosophy, emphasizing reproducibility, transparency, configuration control, traceability, supply-chain security controls, and automated generation of objective verification evidence to support organizations in assessing and qualifying the tool for their intended use. + +Objective evidence may include automated verification results, software bills of materials (SBOMs), build provenance, cryptographic attestations, and traceability artifacts generated as part of the software lifecycle. ## Scope -This document covers the requirements for the amp-devcontainer project: a set of devcontainers tailored towards modern, embedded, software development. +This document defines requirements for the amp-devcontainer container images, supporting build system, and associated lifecycle controls. +The requirements defined in this document address the amp-devcontainer project itself and shall not be interpreted as qualification evidence for any specific use of the containers within a regulated software development lifecycle. -The following is in scope: +The following are in scope: - Container image flavors for C++ and Rust development -- Tooling for compilation, debugging, static and dynamic analysis -- Compatibility with IDEs, container runtimes, and ci/cd systems -- Security properties of released container images -- Maintainability of the container images and their build system +- Compilation, debugging, static analysis, and dynamic analysis tooling provided by the containers +- Compatibility with supported development environments, container runtimes, and continuous integration systems +- Security characteristics of released container images and associated supply-chain artifacts +- Build, release, and maintenance capabilities of the project -The following is out of scope: +The following are out of scope: -- Application-level software built using the containers -- Deployment of end-user products -- Requirements for third-party tools and dependencies included in the containers +- Application software developed using the containers +- Validation or qualification of the containers for a specific intended use within a regulated development process +- Deployment and operation of end-user products +- Requirements governing third-party tools and dependencies outside of the project's control ## References -| Identifier | Title | -|------------|------------------------------------------------------------------------------------------------------------------------------------------| -| RFC 2119 | [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119) | -| OCI | [Open Container Initiative Image Specification](https://github.com/opencontainers/image-spec/blob/main/spec.md) | -| SLSA | [Supply-chain Levels for Software Artifacts v1.0](https://slsa.dev/spec/v1.0/levels) | -| SemVer | [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) | -| DevC | [Development Containers Specification](https://containers.dev/) | +| Identifier | Title | +|------------|-----------------------------------------------------------------------------------------------------------------| +| DevC | [Development Containers Specification](https://containers.dev/) | +| in-toto | [Supply Chain Integrity Framework](https://in-toto.io/) | +| OCI | [Open Container Initiative Image Specification](https://github.com/opencontainers/image-spec/blob/main/spec.md) | +| RFC 2119 | [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119) | +| SemVer | [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) | +| SLSA | [Supply-chain Levels for Software Artifacts v1.0](https://slsa.dev/spec/v1.0/levels) | +| SPDX | [Software Package Data Exchange Specification v2.3](https://spdx.github.io/spdx-spec/v2.3/) | ## Document Control @@ -69,21 +85,21 @@ Changes to requirements are tracked at the individual requirement level through The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*, *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY*, and *OPTIONAL* in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). -## Abstract - -amp-devcontainer is a set of [devcontainers](https://containers.dev/) tailored towards modern, embedded, software development. - -The containers may be used both for local development and continuous integration (ci). - ## Terminology and Abbreviations | Term | Description/Definition | |-----------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------| | ARM | A family of RISC architectures for computer processors and micro controllers, formerly an acronym for Advanced RISC Machines and originally Acorn RISC Machine | +| Attestation | Cryptographically signed statement about an artifact | | Continuous Delivery (cd) | Extends ci by automating the release of validated code, extending test automation to ensure that code is production-ready | | Continuous Integration (ci) | The practice of continuously integrating developers' work to a shared code-base; including automation for build and test | | ELF | Executable and Linkable Format, formerly named Extensible Linking Format | +| OCI | Open Container Initiative | +| Provenance | Verifiable metadata describing how a software artifact was built | | RISC | Reduced Instruction Set Computer | +| SBOM | Software Bill of Materials | +| SLSA | Supply-chain Levels for Software Artifacts | +| SPDX | Software Package Data Exchange | # Requirements @@ -100,8 +116,12 @@ The containers may be used both for local development and continuous integration ### {{ req_ref.identifier }}: {{ utils.reencode(utils.strip_gherkin_prefix(req['custom:title'])) }} +_Requirement_ + {{ utils.reencode(req.description) }} +_Rationale_ + {{ utils.reencode(req.remark) }} {%- endfor %} diff --git a/docs/templates/software-test-plan.md.j2 b/docs/templates/software-test-plan.md.j2 deleted file mode 100644 index 3e473012..00000000 --- a/docs/templates/software-test-plan.md.j2 +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: "Software test plan for amp-devcontainer" -author: ["@rjaegers"] -colorlinks: true -date: "{{ sbdl['doc_control']['custom:generated_at'] | strftime('%Y-%m-%d') }}" -keywords: [Software, Test, Plan, STP, amp-devcontainer] -lang: "en" -titlepage: true -titlepage-color: "0B5ED7" -titlepage-text-color: "FFFFFF" -titlepage-rule-color: "FFFFFF" -titlepage-rule-height: 2 -toc: true -toc-own-page: true -header-includes: - - \AtEndDocument{\label{lastpage}} -{%- if sbdl['doc_control']['custom:is_release'] != 'true' %} -watermark: "DRAFT" -{%- endif %} -footer-right: "\\thepage \\hspace{1pt} of \\pageref*{lastpage}" -... - -{% import "partials/text-utilities.j2" as utils %} - -# Introduction - -## Purpose - -This document describes the test plan for amp-devcontainer. -It defines the test strategy, methodology, and environment, and enumerates the tests that verify each requirement. - -For the full requirement descriptions, refer to the *Software Requirements Specification (SRS)*. -For the coverage overview, refer to the *Requirements Traceability Matrix (RTM)*. - -## Scope - -This document covers the following types of tests: - -- **Gherkin verification tests**: Scenario-based tests defined in Gherkin feature files and executed with Playwright. These tests verify behavioral requirements at the system level. -- **BATS integration tests**: Shell-based integration tests defined in BATS (Bash Automated Testing System) files. These tests verify tool availability, version alignment, and end-to-end compilation and analysis workflows. - -## References - -| Identifier | Title | -|------------|---------------------------------------------------------------------------------------------------------------------------------------| -| SRS | Software Requirements Specification for amp-devcontainer | -| RTM | Requirements Traceability Matrix for amp-devcontainer | -| RFC 2119 | [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119) | - -## Document Control - -{% include "partials/document-control.md.j2" with context %} - -This document is generated from a formal model defined in [sbdl](https://sbdl.dev) and versioned alongside the source code in Git. -The authoritative source of change history is the [Git log](https://github.com/philips-software/amp-devcontainer/commits/) of the source material from which the model is built. - -## Definitions of key words - -The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*, *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY*, and *OPTIONAL* in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). - -# Test environment - -Tests are executed in a container built from the amp-devcontainer image. The container provides all necessary compilers, tools, and dependencies. - -| Component | Description | -|---|---| -| Container runtime | OCI-compatible container engine (e.g. Docker, Podman) | -| Gherkin test runner | Playwright with Gherkin step definitions | -| Integration test runner | BATS (Bash Automated Testing System) | -| CI platform | GitHub Actions | - -# Test methodology - -## Gherkin verification tests - -Gherkin scenarios follow the Given-When-Then structure. Each scenario exercises a specific capability of the devcontainer by automating interactions with the development environment. Tests are executed via Playwright inside a running devcontainer instance (GitHub Codespace or local). A scenario passes when all of its steps complete without error. - -## BATS integration tests - -BATS tests verify tool presence, version alignment, and end-to-end workflows (compilation, analysis, formatting) by executing shell commands inside the devcontainer. Each test function runs in isolation. A BATS test passes when the test function exits with code 0. - -## Expected results - -> **Note**: Structured expected-result data per test is not yet available in the current toolchain. This section will be extended when test result rendering is implemented. Currently, a test is considered passed when it completes without error as described above. - -# Tests by requirement area -{%- for id, item in sbdl.items() %} -{%- if item.type == 'aspect' and 'custom:title' in item %} - -## {{ utils.reencode(utils.strip_gherkin_prefix(item['custom:title'])) }} - -{%- if 'requirement' in item %} -{%- for req_ref in item.requirement %} -{%- set req = sbdl[req_ref.identifier] %} - -### {{ req_ref.identifier }}: {{ utils.reencode(utils.strip_gherkin_prefix(req['custom:title'])) }} - -{%- set ns_tests = namespace(has_tests=false) -%} - -{%- for test_id, test_elem in sbdl.items() -%} -{%- if test_elem.type == 'test' -%} -{%- if 'requirement' in test_elem -%} -{%- for test_req_ref in test_elem.requirement if test_req_ref.identifier == req_ref.identifier -%} -{%- set ns_tests.has_tests = true %} -- **{{ test_id }}**: {{ utils.reencode(utils.strip_bats_syntax(test_elem['custom:title'])) }} -{%- endfor -%} -{%- endif -%} -{%- endif -%} -{%- endfor -%} - -{%- if not ns_tests.has_tests %} -- *No tests traced to this requirement.* -{%- endif -%} - -{%- endfor %} -{%- endif %} -{%- endif %} -{%- endfor %} - -# Anomaly handling - -Test failures are tracked as issues in the project's issue tracker. Each failure is triaged, assigned a severity, and linked to the affected requirement(s). Resolution is verified by re-running the affected test(s). diff --git a/docs/templates/software-verification-plan.md.j2 b/docs/templates/software-verification-plan.md.j2 new file mode 100644 index 00000000..86091a02 --- /dev/null +++ b/docs/templates/software-verification-plan.md.j2 @@ -0,0 +1,188 @@ +--- +title: "Software verification plan for amp-devcontainer" +author: ["@rjaegers"] +colorlinks: true +date: "{{ sbdl['doc_control']['custom:generated_at'] | strftime('%Y-%m-%d') }}" +keywords: [Software, Verification, Plan, SVP, amp-devcontainer] +lang: "en" +titlepage: true +titlepage-color: "0B5ED7" +titlepage-text-color: "FFFFFF" +titlepage-rule-color: "FFFFFF" +titlepage-rule-height: 2 +toc: true +toc-own-page: true +header-includes: + - \AtEndDocument{\label{lastpage}} +{%- if sbdl['doc_control']['custom:is_release'] != 'true' %} +watermark: "DRAFT" +{%- endif %} +footer-right: "\\thepage \\hspace{1pt} of \\pageref*{lastpage}" +... + +{% import "partials/text-utilities.j2" as utils %} + +# Introduction + +## Purpose + +This document defines the verification strategy, methodology, and environment, and identifies the tests, analyses, inspections, demonstrations, and automated gates used to verify requirements. +For the full requirement descriptions, refer to the *Software Requirements Specification (SRS)*. +For the coverage overview, refer to the *Requirements Traceability Matrix (RTM)*. + +## Scope + +This document covers the following verification activities: + +- **Gherkin verification tests**: Scenario-based tests defined in Gherkin feature files and executed with Playwright. These tests verify behavioral requirements at the system level. +- **BATS integration tests**: Shell-based integration tests defined in BATS (Bash Automated Testing System) files. These tests verify tool availability, version alignment, and end-to-end compilation and analysis workflows. +- **CI Verification Gates**: Automated verification activities executed as part of continuous integration and release workflows. A verification gate prevents further workflow execution when a verification criterion is not satisfied. Verification gates provide objective evidence that specific requirements have been verified prior to release. + +## References + +| Identifier | Title | +|------------|----------------------------------------------------------------------------------------------------| +| SRS | Software Requirements Specification for amp-devcontainer | +| RTM | Requirements Traceability Matrix for amp-devcontainer | +| RFC 2119 | [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119) | + +## Document Control + +{% include "partials/document-control.md.j2" with context %} + +This document is generated from a formal model defined in [sbdl](https://sbdl.dev) and versioned alongside the source code in Git. +The authoritative source of change history is the [Git log](https://github.com/philips-software/amp-devcontainer/commits/) of the source material from which the model is built. + +## Definitions of key words + +The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*, *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY*, and *OPTIONAL* in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). + +# Verification Strategy + +The verification method selected for a requirement is based on the nature of the requirement and the type of evidence required to demonstrate conformance. + +## Verification Principles + +Where appropriate, verification includes both positive and negative scenarios. + +Positive verification demonstrates that a requirement can be successfully satisfied. + +Negative verification demonstrates that invalid, incomplete, tampered, or non-conformant artifacts are correctly rejected by the verification mechanism. + +## Verification Environment + +Verification activities are executed on a specific container flavor built from the amp-devcontainer project. +The container provides all necessary tools and dependencies. + +| Component | Description | +|-------------------------|-------------------------------------------------------| +| Container runtime | OCI-compatible container engine (e.g. Docker, Podman) | +| Gherkin test runner | Playwright with Gherkin step definitions | +| Integration test runner | BATS (Bash Automated Testing System) | +| CI platform | GitHub Actions | + +## Verification Methods + +Requirements are verified using one or more of the following methods. + +### Test + +Verification by execution of software under defined conditions. + +#### Gherkin verification tests + +Gherkin scenarios follow the Given-When-Then structure. Each scenario exercises a specific capability of the devcontainer by automating interactions with the development environment. Tests are executed via Playwright inside a running devcontainer instance (GitHub Codespace or local). A scenario passes when all of its steps complete without error. + +#### BATS integration tests + +BATS tests verify tool presence, version alignment, and end-to-end workflows (compilation, analysis, formatting) by executing shell commands inside the devcontainer. Each test function runs in isolation. A BATS test passes when the test function exits with code 0. + +### Analysis + +Verification by examination of generated outputs, metadata, reports, or artifacts. + +### Inspection + +Verification by review of static information such as configurations, generated documents, or released artifacts. + +### Demonstration + +Verification through successful operation of the system within a representative environment. + +### CI Verification Gates + +CI verification gates are automated workflow activities defined in continuous integration and release pipelines. + +A verification gate fails when a required verification criterion is not satisfied, preventing non-conforming artifacts from progressing through the lifecycle or being released. + +Verification gates provide objective and repeatable evidence that requirements have been verified prior to release. + +## Pass and Fail Criteria + +Each verification activity defines objective pass and fail criteria. Depending on the verification method, evidence may include: + +- Successful test execution +- Expected command output +- Successful cryptographic verification +- Successful generation of required artifacts +- Successful completion of CI verification gates +- Verification that invalid conditions are rejected + +Detailed expected results are maintained alongside the verification implementation and are rendered automatically where supported by the toolchain. + +Evidence may be retained in the form of test results, workflow logs, generated reports, attestations, SBOMs, provenance records, and other lifecycle artifacts. + +# Verification Activities by Requirement Area +{%- for id, item in sbdl.items() %} +{%- if item.type == 'aspect' and 'custom:title' in item %} + +## {{ utils.reencode(utils.strip_gherkin_prefix(item['custom:title'])) }} + +{%- if 'requirement' in item %} +{%- for req_ref in item.requirement %} +{%- set req = sbdl[req_ref.identifier] %} + +### {{ req_ref.identifier }}: {{ utils.reencode(utils.strip_gherkin_prefix(req['custom:title'])) }} +{%- if 'custom:verification-type' in req %} + +_Verification method_ + +{{ utils.reencode(req['custom:verification-type']) }} +{%- endif %} +{%- if 'custom:verification-rationale' in req %} + +_Verification rationale_ + +{{ utils.reencode(req['custom:verification-rationale']) }} +{%- endif %} + +_Verification activities_ +{% set ns_tests = namespace(has_tests=false) -%} +{%- for test_id, test_elem in sbdl.items() -%} +{%- if test_elem.type == 'test' -%} +{%- if 'requirement' in test_elem -%} +{%- for test_req_ref in test_elem.requirement if test_req_ref.identifier == req_ref.identifier -%} +{%- set ns_tests.has_tests = true %} +- **{{ test_id }}**: {{ utils.reencode(utils.strip_bats_syntax(test_elem['custom:title'])) }} +{%- endfor -%} +{%- endif -%} +{%- endif -%} +{%- endfor -%} + +{%- if not ns_tests.has_tests %} +- *No verification activity traced to this requirement.* +{%- endif -%} + +{%- endfor %} +{%- endif %} +{%- endif %} +{%- endfor %} + +# Anomaly handling + +Verification failures are tracked as issues in the project's issue tracker. +Each failure is triaged, assigned a severity, and linked to the affected requirement(s). + +Resolution is verified by re-running the affected verification activity. + +Failures of automated CI verification gates are treated as verification failures and are subject to the same anomaly handling process. diff --git a/test/cpp/features/compatibility.feature b/test/cpp/features/compatibility.feature index 06dc0b19..34b06db3 100644 --- a/test/cpp/features/compatibility.feature +++ b/test/cpp/features/compatibility.feature @@ -19,8 +19,17 @@ Feature: Compatibility "amp-devcontainer images *SHALL* be compatible with the [OCI image specification](https://github.com/opencontainers/image-spec/blob/main/spec.md)" remark is - "To guarantee compatibility with container runtimes and container- and image tooling; - amp-devcontainer shall be compatible with the OCI image specification." + "Compatibility with the OCI Image Specification promotes interoperability + across container runtimes and tooling." + custom:verification-type is "CI Verification Gate" + custom:verification-rationale is + "OCI compatibility is verified through successful consumption and + execution of released images using multiple independent OCI-compatible + container runtimes (Docker and Podman). + + Successful operation across multiple OCI implementations provides + objective evidence that the produced images conform to the + interoperability expectations of the OCI Image Specification." } # @sbdl-end diff --git a/test/cpp/features/security.feature b/test/cpp/features/security.feature index 41827b50..89fb2281 100644 --- a/test/cpp/features/security.feature +++ b/test/cpp/features/security.feature @@ -40,6 +40,14 @@ Feature: Security guarantees. It enables consumers to verify that the container image hasn't been tampered with and that it indeed originates from the expected publisher. This helps mitigate several classes of [supply chain threats](https://slsa.dev/spec/v1.0/threats)." + custom:verification-type is "CI Verification Gate" + custom:verification-rationale is + "Cryptographic signing of released container images is verified through successful + verification of the signature using the public identity of the publisher. + + Successful verification of the signature provides objective + evidence that the container image has not been tampered with and that it indeed originates + from the expected publisher." } # @sbdl-end