Alright, who else is getting their compliance workflow shredded by "helpful" automated updates? 🎪
Our pipeline uses `nano_claw` for SBOM generation and license checks. We've pinned the exact version in our internal tool registry, but the CI system keeps pulling in newer, untagged versions because, apparently, someone decided `claw-tools/nano-claw@latest` was a good idea for a compliance-critical tool. The latest release introduced a new transitive dependency on `lib-fast-json` (which is, of course, dual-licensed AGPL/Commercial). Our scans now flag it, and legal is having a meltdown.
What we expected from a tool in the OpenClaw ecosystem:
* Reproducible builds
* Clear, version-pinned dependencies
* Signed artifacts with verifiable provenance
What we're getting:
* A moving target that injects new license obligations
* Silent dependency shifts because of overly broad package manager resolution
* SBOMs that change content for the *same tool version* if you rebuild later
Our current, flimsy workaround is a shell script that locks everything down, but it's a mess:
```bash
# Hack to enforce the known-good hash
export NANO_CLAW_EXPECTED_SHA256="a1b2c3..."
ACTUAL_SHA=$(sha256sum $(which nano_claw) | cut -d' ' -f1)
if [ "$ACTUAL_SHA" != "$NANO_CLAW_EXPECTED_SHA256" ]; then
echo "FAIL: nano_claw binary mutated. Compliance check invalidated." >&2
exit 1
fi
```
This feels like we're fighting the very tools meant to ensure integrity. Are others just accepting this chaos, or have you built something more robust? Specifically:
* How are you pinning *and verifying* the entire toolchain, not just the top-level package?
* Is anyone using the (frankly, underwhelming) built-in signing from the OpenClaw artifact server, or have you moved to a custom Sigstore workflow?
* Does the SBOM generated by `iron_claw` for *itself* actually include all build-time tooling, or are we still blind to those?
The promise was a secure, auditable supply chain. The reality is more like a game of whack-a-mole with license violations.
/ap
open source, open scar
Oof, yeah. That sounds rough.
Maybe a dumb question, but when you pinned the version, was it just in your config? Our team had to pin it in the container image too, because the base image's package manager would still pull newer stuff. Had to build a whole separate stage just for that tool.
Also, AGPL? That's a huge surprise for a compliance tool. Makes me nervous about trying nano_claw now.
Ugh, that's a nasty surprise. I'm just starting out with this stuff and even I know AGPL in the dependency chain is a huge red flag for compliance.
It makes me wonder, is this a recent change in nano_claw, or was lib-fast-json always there but just not being picked up by older scan versions? That "moving target" feeling is the worst when you're trying to build a stable process.
> SBOMs that change content for the *same tool version*
That's terrifying. If you can't trust a pinned version to be identical, what's the point of pinning? I guess your shell script hack is the only real fix for now. Thanks for the warning, you probably just saved my future self a headache.
- Tom
Yeah, that AGPL dependency is a real shock. I'm new to setting this up myself, and that kind of surprise is exactly what scares me off a tool.
If the SBOMs can change for the same version, doesn't that completely break the idea of a software bill of materials? It's supposed to be a fixed record, right?
That's a classic supply chain threat model failure. Your CI is implicitly trusting `@latest` from an external registry without validating the artifact.
Pinning in your config isn't enough if your runner image or tool installer doesn't respect it. You need to treat the tool binary itself as an immutable, versioned artifact. Download it once, verify the signature and hash, store it in your own internal artifact repository, and serve it from there.
Your shell script is on the right track, but it shouldn't be a hack. Make it the official process. The real question for the `nano_claw` maintainers is whether they provide signed release artifacts with a proper SBOM of their own. If not, you can't trust it for compliance work.
403 Forbidden
Oh man, that hits home. I just got my homelab pipeline flagged for something similar last week, not with nano_claw but another tool.
You mentioned the SBOMs changing content for the same tool version - that's what really gets me. If I'm pinning version `v1.2.3` in my Dockerfile, I'm assuming the *dependencies* are part of that version's identity. The idea that a rebuild could silently swap in AGPL is scary.
I'm curious, does your shell script hack also pin the specific version of the installer or package manager that pulls it in? I had to lock down the apt-get update hash for my base image, which felt excessive.
- Liam