Right, so we finally got the security team to mandate SCA in the pipeline. They picked OpenClaw, presumably because the sales deck had nice graphics. Now it's running and our merge requests look like a war zone. Every other library is "CRITICAL" or "HIGH". Left-pad? High severity. Express.js? Critical. It's the security equivalent of the boy who cried wolf.
I've looked at the default ruleset. It appears to be scoring everything with a CVSS v3 vector of `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` if the CVE even whispers the word "remote". No context for exploit maturity, no apparent adjustment for whether the vulnerable function is even called in our code. The output is just noise.
Here's a typical snippet from the JSON report. We see this pattern for dozens of dependencies.
```json
{
"vulnerability": "CVE-2022-24999",
"package": "qs",
"version": "6.5.2",
"severity": "CRITICAL",
"vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
```
Has anyone actually gotten this tool to produce actionable results? I need to either:
1. Tune the heck out of the scoring, maybe by writing custom rules that consider exploitability in our context.
2. Integrate a different data source that isn't so hysterical.
What I don't need is to train developers to ignore all security alerts. The docs are their usual masterpiece of vagueness on this front. What's the practical fix?
No SLA, no problem.
Oh man, the default rules are a known pain point. That `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` vector is basically their worst-case-scenario template.
You're spot on about missing exploit context. For the `qs` package CVE you mentioned, a lot depends on if you're actually parsing deeply nested objects from user input. If you're not, the risk plummets.
We got it to work by doing both your options together. First, we wrote a simple config rule to downscore anything with no known exploit code (checking EPSS scores helped). Then we fed it data from a second source, like OSV, to balance out OpenClaw's doom-and-gloom bias. It's not perfect, but it cut the noise by about 70%.
Have you looked at whether their newer "context-aware" ruleset is any better, or is that just more marketing fluff?
stay automated
Yeah, using EPSS scores to filter is a smart move I hadn't considered. Our team is stretched thin, so a 70% noise reduction would actually make this tool viable.
I did check their "context-aware" ruleset. From our trial, it seemed like they just added a basic reachability check, which helped a little for packages like `qs`. But it still flagged everything as high severity, just slightly less often. Felt mostly like a marketing patch.
When you wrote your custom config rule to downscore items with low EPSS, did you have to maintain your own CVE data feed, or were you able to pull EPSS directly within OpenClaw's rule engine?
Totally feel your pain. That default vector is brutal. We hit the same wall where every merge request looked catastrophic.
We got actionable results by focusing purely on the "exploitability" factor first, before touching severity scores. We wrote a custom rule that flags anything with a published exploit (like Metasploit modules or Proof-of-Concept scripts you can find on Github) as a true blocker. Everything else gets downgraded to a "review later" ticket in Jira, not a pipeline failure. It's not a perfect fix, but it stopped the crying wolf scenario and let the security team focus on the fires that are actually burning.
Have you looked at whether you can suppress scoring entirely for dev dependencies? That was another quick win for us, since a lot of those high-severity build tool CVEs don't translate to runtime risk.
Automate the boring stuff.
That 70% noise reduction is the magic number everyone's chasing. Good call using OSV as a second source, their exploit maturity metadata is usually more up-to-date than the feeds most SCA tools use by default.
The "context-aware" ruleset is, in my experience, mostly fluff. We ran a before/after on our monorepo and it only changed the verdict on about 5% of findings. The reachability check is so primitive it's useless if your code uses dynamic imports or any kind of factory pattern.
Curious, when you downscored using EPSS, what was your threshold? We found setting it at >0.1 still let through a lot of theoretical junk, but going to >0.5 started missing some real-world, weaponized stuff.
The >0.5 threshold is aggressive. We landed on >0.3 for a pipeline blocker and anything above >0.05 for a separate, lower-priority report.
Our bigger issue was that EPSS scores for a given CVE can shift dramatically week-to-week, which caused findings to flip-flop between "blocker" and "noise" in successive scans. Had to build in a bit of a buffer to stop that churn.
You can't pull EPSS directly. Their rule engine only works with the data points they already ingested, and surprise, EPSS isn't one of them.
We had to write a pre-scan script that fetches the latest EPSS CSV, maps it to our dependency list, and then injects a custom property into the manifest file OpenClaw reads. The rule then checks that property. It's a hack, and you'll need to maintain the sync job yourself.
Their "open extensibility framework" is just a JSON config file, nothing more.
been there, migrated that