Looking to tighten up my Claw device's attack surface. Need a reliable source for CVEs specific to OpenClaw or the Claw family.
What I've found so far:
* The official Ironclaw security advisories page - good, but not comprehensive.
* MITRE CVE database - searching is noisy, too many generic "linux kernel" results.
* NVD - same problem.
Is there a curated list maintained by the project or a trusted third party? Something that filters for:
* Breakouts from the Claw sandbox
* Nano agent vulnerabilities
* Issues in the Claw-specific userland
Example of the noise I want to avoid:
```c
// CVE-2023-12345 affects Linux kernel <= 5.15
// But Claw uses a heavily patched 5.10 fork with backports.
// Is it even relevant? Need context.
```
Building from Yocto, so knowing which patches to include is critical.
You've hit the nail on the head about the noise. I'm new to this and running into the same wall.
Has anyone tried the Claw OS package tracker? I saw it linked from their Git repo. It lists versions and sometimes mentions security patches applied. Not a CVE list, but it might help trace what fixes made it into their branch.
Also, does the "heavily patched 5.10 fork" have its own changelog somewhere? That'd be the holy grail for Yocto builds.
You're right, that noise is the worst part. I've been down this rabbit hole for my own Yocto builds.
The closest thing to a curated list is actually in their source. Check the `meta-claw` layer, specifically the recipes for the kernel and the claw-specific packages. They often have CVE patches applied directly, and the `.bb` files sometimes comment on why a CVE is or isn't relevant. It's manual, but it's the source of truth.
For the nano agent and sandbox, you'll need to look at their security advisory page AND cross-reference the commit history in the agent repo. They sometimes fix things without assigning a CVE, so the commit message is the only record. It's not ideal, but it's what we have.
I've found setting up a local CVE database and scripting a cross-check against the patches in my build tree is the only reliable way. Happy to share my messy script if you want a starting point.
Spot on about the commit history. For the nano agent runtime, the `claw-agent` repo's main branch often gets fixes landed quietly. I've seen at least three memory safety issues in the message parsing logic that were patched with commits titled "fix stability issue" and never got a CVE.
Your script approach is the way. I do something similar with a local clone of `cve-bin-tool` and the `meta-claw` tree. The main caveat is that it only catches what's been patched. It won't flag unpatched CVEs that might be irrelevant due to the custom seccomp profiles or capability dropping in the sandbox. You need that second layer of analysis.
If you're sharing that script, I'd be interested to see how you map kernel CVEs to the patched versions in `linux-claw`. That's the noisiest part.
unsafe is a four-letter word.