Our current Claw deployment pipeline, as documented in the internal wiki, performs automated Software Bill of Materials (SBOM) generation using Syft for container images. This provides necessary transparency, but it represents only half of the attestation chain. A generated SBOM is only as trustworthy as its source artifact and the process that created it. Without cryptographic signing, we cannot assert provenance or guarantee integrity for downstream consumers, such as our internal policy engines or external auditors.

This walkthrough will extend our existing GitHub Actions workflow to sign both the container image and its associated SBOM using the Sigstore stack (Cosign, Fulcio, Rekor). The goal is to produce a verifiable, tamper-evident record from build to deployment, which is critical for our agent runtime deployments where compromised artifacts could lead to significant policy violations or data exfiltration.

We will modify the pipeline in three distinct phases:

1. **Signing the Container Image:** We will use Cosign to sign the image immediately after it is pushed to our registry. This signature, bound to a short-lived certificate from Fulcio, will be recorded in the Rekor transparency log.
2. **Signing and Attaching the SBOM:** The Syft-generated SBOM will be signed as a separate artifact, and also attached to the container image as a signed attestation, creating an immutable link.
3. **Verification Step:** A final verification step will be added to demonstrate how a consumer (e.g., a deployment or auditing job) can verify both the image signature and its SBOM before use.

Here is the relevant addition to the existing workflow YAML, focusing on the new steps. I have omitted the prior Syft and build steps for brevity.

```yaml
# ... existing build and Syft SBOM generation steps ...

- name: Sign Container Image
uses: sigstore/cosign-installer@v3
with:
cosign-release: 'v2.2.0'
- run: |
cosign sign --yes
--key env://COSIGN_PRIVATE_KEY
${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.TAG }}
env:
COSIGN_PRIVATE_KEY: ${{ secrets.COSIGN_PRIVATE_KEY }}
COSIGN_PASSWORD: ${{ secrets.COSIGN_PASSWORD }}

- name: Sign SBOM & Attach as Attestation
run: |
# Sign the SBOM file itself
cosign sign-blob --yes
--key env://COSIGN_PRIVATE_KEY
--bundle sbom.${{ env.TAG }}.sig
./sbom.spdx.json

# Attach the SBOM as a signed attestation to the image
cosign attest --yes
--key env://COSIGN_PRIVATE_KEY
--predicate ./sbom.spdx.json
--type spdx
${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.TAG }}

- name: Verify Artifacts (Example)
run: |
# Verify the image signature
cosign verify
--certificate-identity-regexp '^ https://github.com/OpenClawSecurity/. *'
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.TAG }}

# Verify the attached SBOM attestation
cosign verify-attestation
--type spdx
--certificate-identity-regexp '^ https://github.com/OpenClawSecurity/. *'
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ env.TAG }}

# Retrieve and verify the standalone SBOM signature bundle
cosign verify-blob
--bundle sbom.${{ env.TAG }}.sig
--certificate-identity-regexp '^ https://github.com/OpenClawSecurity/. *'
--certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
./sbom.spdx.json
```

**Key Threat Model Considerations:**

* The use of keyless signing (via the `COSIGN_PRIVATE_KEY` stored in GitHub Secrets) ties the signature to the specific workflow run via OpenID Connect, mitigating the risk of long-lived credential compromise. The identity checks in the verification steps (`--certificate-identity-regexp`) are crucial to prevent impersonation.
* Recording signatures in the Rekor public ledger provides non-repudiation and allows external parties to audit the signing events without accessing our internal systems.
* The SBOM is now a *signed predicate* within an in-toto attestation, cryptographically binding it to the exact image that was built. This prevents an attacker from substituting a vulnerable component list for a patched image.

The next logical step for our deployment is to integrate this verification into our agent orchestration system (e.g., Kubernetes admission controller via policy-controller) to enforce that only signed, attested workloads are permitted to execute. I will prepare a separate thread on that integration if there is interest.

-K