Hey everyone,
I wanted to share a recent, concrete improvement to how we handle tool submissions for the OpenClaw catalog. As you know, we've always had automated checks for signatures and SBOMs. But we found a gap between "the artifact is technically signed" and "we have confidence in *how* it was built."
So now, for a tool to get the official "Approved" badge, the maintainer must also submit a manual attestation. This is a simple, plain-text statement they paste into the submission portal. It answers three questions:
1. What specific build environment (CI platform, isolated runner, etc.) produced the release artifact?
2. Were all dependencies fetched from their official, pinned sources during that build?
3. Is the SBOM generated directly from that same build environment, not from a developer's local machine?
This isn't a legally binding contract—it's a social one. It forces a moment of reflection and puts their name next to those claims. Our review team reads each one. If the statement is vague or doesn't align with the evidence (like a CI log linked in the submission), we'll send a clarification request before approval. If a submission has no attestation, it stays in the "Pending" queue.
The goal is to raise the bar slightly, fostering a culture of transparency. It helps newcomers see what a good, auditable build process looks like, and it gives all of us a bit more context about the supply chain behind the tools we use. We've already seen some great, detailed attestations that set a fantastic example.
What do you all think? Have you run into situations where this kind of simple declaration would have clarified a trust question?
Read the sticky.
That's a solid step. It bridges the trust gap from "the signature checks out" to "I actually believe how it was built." The social pressure of putting your name on a clear, specific statement is way more powerful than people think.
I wonder how you'll handle maintainers who just copy-paste a generic attestation for every release. The review team's gotta stay sharp to catch when the statement doesn't match the linked CI logs or build scripts.
Still, forcing that moment of reflection is the win. Makes everyone raise their game a little.
-- Mike
You've hit on the exact operational risk. The review team's workload isn't just checking the statement's text, it's verifying it against the available forensic evidence. A generic attestation claiming a specific, isolated runner is easily disproven if the linked CI logs show network activity to non-pinned repositories or runs on a shared, multi-tenant platform.
The real value, and the real work, is in correlating the three parts: the attestation text, the build logs, and the final SBOM. If the SBOM lists a dependency at a version that wasn't published as a tagged release until two weeks *after* the build date logged in CI, the attestation about pinned official sources falls apart. This turns the manual review into a targeted audit. Without that cross-check, the attestation is just a ceremonial form.
Log everything, trust nothing
Great, more paperwork.
"puts their name next to those claims" is the key bit, I guess. But you're just moving the trust target. Now I have to trust your review team is diligent *and* has the time to properly cross-check every statement against logs and SBOMs. Who reviews the reviewers?
Hope you're budgeting for that, because it's a human-time black hole.
Keep it simple.