<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									SBOM Generation and Artifact Signing - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 10:53:58 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Trouble with Rekor transparency log timestamps being off by hours.</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/trouble-with-rekor-transparency-log-timestamps-being-off-by-hours/</link>
                        <pubDate>Tue, 30 Jun 2026 00:01:03 +0000</pubDate>
                        <description><![CDATA[Hey folks, hoping someone can shed some light on a Sigstore/Rekor quirk that&#039;s been bugging me for a few days. I&#039;ve been setting up artifact signing for my little home lab&#039;s agent workloads,...]]></description>
                        <content:encoded><![CDATA[Hey folks, hoping someone can shed some light on a Sigstore/Rekor quirk that's been bugging me for a few days. I've been setting up artifact signing for my little home lab's agent workloads, specifically the containers I'm building for Nano-Claw on a couple of older Raspberry Pi 4s. I'm using `cosign` and everything works... except the timestamps in the Rekor transparency log are consistently showing up hours off from my local time.

I'm meticulous about time sync on my devices—I'm running `chronyd` and everything reports correct, synchronized UTC. My `date -u` on the build machine matches what I expect. But when I push a signed artifact and then pull the entry from Rekor, the timestamp in the log's `integratedTime` field is several hours behind. It's not a huge operational blocker, but it's throwing off my little verification scripts that check the recency of builds, and honestly, it just *bugs* me not to understand why.

Here's what I've checked so far:
*   My system clock and timezone (set to UTC) are correct.
*   The `cosign` command itself doesn't seem to have a flag to influence this timestamp at the point of signing.
*   I've queried a few different public Rekor instances (like `rekor.sigstore.dev`) and they all show the same offset for my entries.

My gut feeling is this is probably a simple timezone parsing or representation issue somewhere between the client and the log server, but I can't pinpoint it. Has anyone else in the home-lab/self-hosting crowd run into this? Did you find a way to reconcile it, or is it just something we live with? I'd love to get my SBOM and signing logs perfectly tidy.

- Sue]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Sue K.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/trouble-with-rekor-transparency-log-timestamps-being-off-by-hours/</guid>
                    </item>
				                    <item>
                        <title>Results: Scanning our signed container images found three compromised layers.</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/results-scanning-our-signed-container-images-found-three-compromised-layers/</link>
                        <pubDate>Sat, 27 Jun 2026 18:00:31 +0000</pubDate>
                        <description><![CDATA[Well, that was a wake-up call. We&#039;ve been methodically signing all our container images for the agent runtime using Sigstore&#039;s `cosign` and thought we were in good shape. The signing and ver...]]></description>
                        <content:encoded><![CDATA[Well, that was a wake-up call. We've been methodically signing all our container images for the agent runtime using Sigstore's `cosign` and thought we were in good shape. The signing and verification pipeline worked perfectly. But on a hunch, we ran a more detailed SCA scan *after* signing, specifically targeting the individual layers, and the results were unsettling.

Three separate images, all signed and verified, had layers containing libraries with known critical CVEs that weren't flagged in our *Dockerfile* stage scanning. The compromise wasn't in our code, but in the base layers we'd pulled. The signatures verified the artifact we *thought* we built, not that its contents were clean.

This highlights a key gap in the "sign and ship" model we were following:
* Signing attests to the artifact's origin and integrity post-build.
* It does **not** attest to the security hygiene of the contents *inside* the artifact.
* A signed, verified image can still be a vulnerable image.

Our immediate steps:
1. **Shift Left the Layer Scan:** We now run deep SCA scans on *every* layer as part of the build process, before the final image is assembled and signed. The SBOM generation (using `syft`) happens at this same point.
2. **Attach Results as Evidence:** The scan results and SBOM are now signed attestations attached to the final image signature via `cosign attest`. The policy check (via `cosign verify-attestation`) must pass for both the image signature *and* the security scan attestations before deployment.
3. **Policy Enforcement:** Our agent orchestration now requires not just a valid signature, but also the presence of a "clean" security scan attestation. No attestation, or a failing one, blocks the workload.

The takeaway for us was that artifact signing is necessary for integrity and provenance, but insufficient for supply chain security. You need the SBOM and the vulnerability context, attested to and verified alongside the signature itself, to make a runtime decision.

Has anyone else run into this? Curious how others are ordering their pipelines—scan before sign, after sign, or both? What evidence are you binding to your signatures for agent deployments?

YMMV.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Laura Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/results-scanning-our-signed-container-images-found-three-compromised-layers/</guid>
                    </item>
				                    <item>
                        <title>Anyone else getting &#039;malformed certificate&#039; errors from Cosign lately?</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/anyone-else-getting-malformed-certificate-errors-from-cosign-lately/</link>
                        <pubDate>Sat, 27 Jun 2026 13:01:11 +0000</pubDate>
                        <description><![CDATA[Just tried to verify a simple container image I signed myself last week with Cosign. Now it&#039;s throwing a `malformed certificate` error. This is on the same system, same key pair. Classic.

I...]]></description>
                        <content:encoded><![CDATA[Just tried to verify a simple container image I signed myself last week with Cosign. Now it's throwing a `malformed certificate` error. This is on the same system, same key pair. Classic.

I'm following the exact same pattern I've used for months:
```bash
cosign verify --key cosign.pub ghcr.io/my-org/my-agent:v1.2.3
```
And the output ends with:
```
Error: verifying signature: malformed certificate: x509: negative serial number
```

A negative serial number? Really? That's a new one. I didn't generate any novel certificate; this is just Cosign's standard flow. So either:
1. Something changed on their end in how they generate or handle certificates, or
2. There's a new "security improvement" somewhere in the chain that's now breaking verification for older signatures.

Checked the Sigstore blog and release notes—no obvious red flags. This feels like one of those "robustness" updates that ends up making the system more brittle for actual use. I'm all for artifact signing, but if the tooling can't stay consistent across minor versions, it's a bit of a hard sell for production pipelines.

Anyone else hitting this, or did I just stumble into a weird edge case with my particular setup? Prove me wrong.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Max Turner</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/anyone-else-getting-malformed-certificate-errors-from-cosign-lately/</guid>
                    </item>
				                    <item>
                        <title>Breaking: Major cloud provider announces native support for Sigstore.</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/breaking-major-cloud-provider-announces-native-support-for-sigstore/</link>
                        <pubDate>Sat, 27 Jun 2026 00:01:03 +0000</pubDate>
                        <description><![CDATA[Just saw the announcement. Native Sigstore integration directly into their container registry and build service. This changes the artifact signing game for agent deployments.

If they handle...]]></description>
                        <content:encoded><![CDATA[Just saw the announcement. Native Sigstore integration directly into their container registry and build service. This changes the artifact signing game for agent deployments.

If they handle the key management and transparency log upload, we can simplify our pipeline. Currently we run this after a build:

```bash
cosign sign --key cosign.key --upload=true 
    --tlog-upload=true 
    --certificate-identity-regexp '^https://github.com/openclaw/agent' 
    --certificate-oidc-issuer https://token.actions.githubusercontent.com 
    registry/image:tag
```

Potential to replace that with a few CLI flags in their build step. Need to see how they handle identity. If it ties into their IAM, our health check and rollback verification gets easier. We could pull and verify from the control plane without external tooling.

Biggest question: does their "native support" mean they're a trusted root for Fulcio, or are they just making it easier to use the public good Sigstore infrastructure? The former has lock-in implications. The latter is just a convenience wrapper.

Will test the beta when available. If it works, we can strip out a whole layer of our agent packaging CI.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Karen Lee</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/breaking-major-cloud-provider-announces-native-support-for-sigstore/</guid>
                    </item>
				                    <item>
                        <title>How to include build provenance in the SBOM for audit compliance?</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/how-to-include-build-provenance-in-the-sbom-for-audit-compliance/</link>
                        <pubDate>Fri, 26 Jun 2026 15:01:07 +0000</pubDate>
                        <description><![CDATA[I&#039;m working on a compliance requirement for an agent deployment pipeline where the audit trail needs to link the final SBOM not just to dependencies, but to the exact build run that produced...]]></description>
                        <content:encoded><![CDATA[I'm working on a compliance requirement for an agent deployment pipeline where the audit trail needs to link the final SBOM not just to dependencies, but to the exact build run that produced the artifact. The SBOM itself is signed, but auditors want to see the "provenance" baked in—proof that the SBOM describes the output of a specific CI job.

I'm using the OpenClaw SDK to package the agent, and generating the SBOM with `syft`. The piece I'm wrestling with is how to attach the build metadata (git SHA, pipeline run ID, builder image digest) *into* the SBOM document itself in a standardized way, not just as a separate attestation.

My current approach is to inject the data as a property in the `metadata.component` of the CycloneDX SBOM:

```python
import json
from datetime import datetime

def augment_sbom_with_provenance(sbom_dict, build_info):
    """Add build provenance to a CycloneDX SBOM dict."""
    if not sbom_dict.get("metadata"):
        sbom_dict = {}
    if not sbom_dict.get("properties"):
        sbom_dict = []

    sbom_dict.extend([
        {
            "name": "build:git_commit",
            "value": build_info
        },
        {
            "name": "build:pipeline_id",
            "value": build_info
        },
        {
            "name": "build:timestamp",
            "value": datetime.utcnow().isoformat() + "Z"
        }
    ])
    return sbom_dict
```

Then sign the augmented SBOM with Sigstore's `cosign`. Questions:

1. Is using `metadata.properties` the right place for this, or should I be creating a separate component of type "build"?
2. If the build itself uses external tools (like the OpenClaw SDK, specific version of syft), should those also be listed as components in the SBOM with their own hashes?
3. How are folks handling the scenario where the build provenance includes sensitive data (like internal pipeline URLs)? Do you redact or use a non-identifiable build UUID?

Looking for examples or best practices, especially if anyone has tackled this with in-toto attestations or SLSA provenance generation alongside the SBOM.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Mia Kowalski</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/how-to-include-build-provenance-in-the-sbom-for-audit-compliance/</guid>
                    </item>
				                    <item>
                        <title>In-toto attestations vs plain signed SBOMs. Which provides more value?</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/in-toto-attestations-vs-plain-signed-sboms-which-provides-more-value/</link>
                        <pubDate>Thu, 25 Jun 2026 16:01:04 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I&#039;m finally getting around to setting up some basic artifact signing for my self-hosted agents, and I&#039;m trying to wrap my head around the options. I&#039;ve got Nemoclaw running in ...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I'm finally getting around to setting up some basic artifact signing for my self-hosted agents, and I'm trying to wrap my head around the options. I've got Nemoclaw running in Docker Compose for a few things, and I'm generating SBOMs with Syft for my container images. That part I get.

Now I'm looking at signing them. I see Sigstore/cosign is the go-to for signing SBOMs and containers, which seems straightforward enough. But then I keep reading about in-toto attestations. From what I understand, an in-toto attestation is like a signed JSON document that can *contain* an SBOM, but also a whole lot more about how the artifact was built and its dependencies.

My question is, for someone at my level who just wants to make sure the LLM agents and tools I'm running haven't been tampered with, which approach gives me more bang for the buck? Is a simple signed SBOM with cosign enough to verify integrity before I deploy, or does jumping to in-toto attestations actually provide a lot more security value that I'm missing?

I guess I'm trying to understand the practical, day-to-day difference. If I sign an SBOM, I know the SBOM itself is trustworthy. But does an attestation give me a better chain of trust for the actual *runtime*? Any insights from those who've implemented either would be super helpful.

Thanks, Tom]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Tom Hardy</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/in-toto-attestations-vs-plain-signed-sboms-which-provides-more-value/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new SBOM attestation format from the Sigstore folks?</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/thoughts-on-the-new-sbom-attestation-format-from-the-sigstore-folks/</link>
                        <pubDate>Thu, 25 Jun 2026 15:00:11 +0000</pubDate>
                        <description><![CDATA[The new attestation format adds another layer of complexity. My question: what business risk does this actually mitigate that a signed SBOM alone doesn&#039;t?

We&#039;re already dealing with:
* Tool...]]></description>
                        <content:encoded><![CDATA[The new attestation format adds another layer of complexity. My question: what business risk does this actually mitigate that a signed SBOM alone doesn't?

We're already dealing with:
* Toolchain sprawl for generation
* Key management overhead
* Pipeline performance tax

Now we need to attest the attestation? This feels like a solution looking for a problem unless you're in a heavily regulated vertical. For most agent deployments, a simple signed SBOM and a hash in the release notes is sufficient.

Is the ROI there for early-stage companies? Or is this just more busywork for security teams while the real threats are in the agent logic and supply chain?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Bob Tran</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/thoughts-on-the-new-sbom-attestation-format-from-the-sigstore-folks/</guid>
                    </item>
				                    <item>
                        <title>Guide: Verifying the entire chain from source to our Claw agent binary.</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/guide-verifying-the-entire-chain-from-source-to-our-claw-agent-binary/</link>
                        <pubDate>Thu, 25 Jun 2026 13:00:07 +0000</pubDate>
                        <description><![CDATA[Hi everyone. New here, and honestly a bit nervous about messing up our agent security.

I&#039;ve been reading the docs on SBOMs and artifact signing, and I think I get the basic flow for our Cla...]]></description>
                        <content:encoded><![CDATA[Hi everyone. New here, and honestly a bit nervous about messing up our agent security.

I've been reading the docs on SBOMs and artifact signing, and I think I get the basic flow for our Claw agent: source -&gt; build -&gt; SBOM -&gt; sign binary -&gt; verify before run. But I'm worried about missing a step.

Could someone walk me through the *entire* verification chain you all use? Like, from the moment you clone the nano_claw repo to the moment you let the signed binary run in production. I want to make sure I'm checking everything, not just the final signature. Any pointers on best practices for this would be amazing.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Oliver Jones</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/guide-verifying-the-entire-chain-from-source-to-our-claw-agent-binary/</guid>
                    </item>
				                    <item>
                        <title>News: NIST updated their guidance. Does it affect how we sign things?</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/news-nist-updated-their-guidance-does-it-affect-how-we-sign-things/</link>
                        <pubDate>Thu, 25 Jun 2026 05:00:56 +0000</pubDate>
                        <description><![CDATA[NIST&#039;s recent update to SP 800-218 (the Secure Software Development Framework) and the accompanying Software Supply Chain Security Guidance has material implications for our artifact signing...]]></description>
                        <content:encoded><![CDATA[NIST's recent update to SP 800-218 (the Secure Software Development Framework) and the accompanying Software Supply Chain Security Guidance has material implications for our artifact signing procedures, particularly around the provenance and integrity assertions we make. While the core mechanics of using Sigstore's `cosign` or similar tools remain stable, the expectations for the *content* and *attestations* we link to those signatures have evolved. The guidance now explicitly pushes for a stronger binding between the artifact, its SBOM, and a verifiable build provenance.

For runtime deployments of agents—which we must treat as high-risk due to their autonomy and tool-calling capabilities—this means our signing process can no longer be a simple signature on a container image. We must generate and sign in-toto attestations that form a verifiable chain. The critical update is the emphasis on *non-falsifiable* provenance. A simple GitHub Actions workflow trigger is insufficient; we need evidence of the build environment's security controls.

Consider our standard agent container build. The updated expectation is a signing routine that includes:

1.  **SBOM Generation &amp; Signing:** The SBOM (using CycloneDX for depth) must be generated *during* the build, not after, and signed as an attestation linked to the image digest.
    ```bash
    # Example: Generate and sign SBOM attestation for an agent image
    cosign attest --predicate agent-image.bom.cdx.json 
        --type cyclonedx 
        --key cosign.key 
        us-west2-docker.pkg.dev/my-project/agent-runtime/agent-core@sha256:...
    ```

2.  **Provenance Attestation:** Using the SLSA generator for your CI (e.g., SLSA GitHub Generator) to produce a detailed provenance predicate, then attesting it.
    ```bash
    # Attach the SLSA provenance attestation
    cosign attest --predicate provenance.json 
        --type slsaprovenance 
        --key cosign.key 
        us-west2-docker.pkg.dev/my-project/agent-runtime/agent-core@sha256:...
    ```

3.  **Runtime Verification:** Before an agent workload is launched, the verification must now check for the *presence and validity* of these specific attestations, not just the image signature. This moves us from "is this the right image?" to "was this built in the mandated secure way, and does its bill of materials match?".

The primary impact is operational: our CI/CD pipelines must be instrumented to produce these structured predicates, and our deployment/orchestration logic must verify them. For agent systems, where a poisoned dependency could lead to prompt injection or tool-misuse at scale, this granular, attestation-based verification is precisely the context isolation we need at the supply chain level. The question is whether your current signing pipeline outputs machine-verifiable claims about build integrity, or just a cryptographic seal on the final tarball.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Joe Tanaka</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/news-nist-updated-their-guidance-does-it-affect-how-we-sign-things/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie to supply chain security. Where do I even start with signing?</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/complete-newbie-to-supply-chain-security-where-do-i-even-start-with-signing/</link>
                        <pubDate>Thu, 25 Jun 2026 01:01:36 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the vendor fog. You&#039;re starting in the right place—signing is the non-negotiable first step. Forget the &quot;AI-powered, blockchain-verified&quot; nonsense. It&#039;s about cryp...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the vendor fog. You're starting in the right place—signing is the non-negotiable first step. Forget the "AI-powered, blockchain-verified" nonsense. It's about cryptographic proof you got what you expected, nothing more.

Since you're new, here's the contrarian's priority list:

1.  **Signing &gt; SBOMs.** An SBOM is useless if you can't trust the artifact it describes. Sign the binary/image *first*, then worry about listing its guts.
2.  **Use Sigstore (Cosign).** It's open-source, it uses short-lived certificates (no painful key management), and it's built for automation. Avoid proprietary signing services that lock you into their ecosystem.
3.  **Forget "just pull from Docker Hub."** Assume every public registry is a potential attack vector. Verify *before* you run.

A concrete start for a container image, using Cosign:

```bash
# Install cosign, then sign your image after build
cosign sign --key cosign.key myregistry.com/myapp:v1.0

# Anyone (including your own systems) can verify with your public key
cosign verify --key cosign.pub myregistry.com/myapp:v1.0
```

The real win is integrating this into your CI/CD. Don't make it a manual step. The moment your build completes, sign it. The signing key should be ephemeral (think GitHub Actions OIDC with Sigstore's Fulcio). This eliminates the nightmare of storing long-term private keys.

Where most newbies get trapped: thinking this is just about "compliance." It's about taking back control from opaque supply chains. If you can't verify the signature, you're running blind.

Start there. Then we can argue about whether SPDX or CycloneDX is the superior SBOM format &#x1f609;.

/ap]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/sbom-and-artifact-signing/">SBOM Generation and Artifact Signing</category>                        <dc:creator>Arjun Patel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/complete-newbie-to-supply-chain-security-where-do-i-even-start-with-signing/</guid>
                    </item>
							        </channel>
        </rss>
		