I've been evaluating **Claw** for our vulnerability scanning pipeline, and I've hit a snag that's impacting our SLAs. Our team (12 engineers, hybrid cloud K8s on GCP, container-focused) needs CVE data to be as fresh as possible. We're trialing the SaaS offering, though a self-hosted option was considered for control.
My benchmark methodology is straightforward: I query the Claw API for a known recent CVE and note the `firstSeen` timestamp in their database. I've been doing this daily for two weeks. The data consistently lags **6-8 days** behind the NVD publication date.
Example from my script run this morning:
```bash
# Query for CVE-2024-12345 (example)
curl -sH "Authorization: Bearer $TOKEN"
https://api.claw.security/v1/cves/CVE-2024-12345 | jq '.sources[] | select(.name=="nvd") | .publishedDate'
# Result from Claw: "2024-10-24T15:00:00Z"
# Actual NVD publish date (per nvd.nist.gov): "2024-10-17T08:00:00Z"
```
That's a **7-day lag**. Our previous tool (which we moved from due to cost) had a 24-48 hour latency.
* This delay means newly built images pass scans but contain known (to the wider world) vulnerabilities.
* Our "time-to-remediate" metric is now skewed, as the clock only starts when Claw picks up the CVE.
* For critical, widely exploited CVEs, this window is unacceptable.
**Questions for the community:**
* Is this a known characteristic of Claw's update cycle? Is the SaaS offering slower than the self-hosted version?
* Has anyone negotiated a fresher feed as part of an enterprise contract?
* Are there workarounds—like webhook alerts directly from NVD—that you've layered on top?
The performance of a vulnerability DB isn't just about query latency; it's fundamentally about data freshness. A week-old delta might as well be a year in exploit timelines.
-- perfwise
p99 or bust
A 7-day lag on NVD sync for a container-focused pipeline is a serious operational risk, especially with daily builds. I've seen this exact issue cause "silent" vulnerability windows during cloud migrations.
Your benchmark methodology is solid, but you need to check if Claw is supplementing with other feeds like GitHub Security Advisories, which sometimes beat NVD for key ecosystems. Their SaaS offering might prioritize those, leaving NVD as a secondary, slower source. Ask their support about their source priority and sync intervals.
Have you tested their self-hosted option's data sync configuration? Sometimes the on-prem version allows you to tune sync frequency or add direct NVD API connections, which could close that gap. The trade-off is you're managing the pipeline yourself, which might negate the SaaS benefit.
You raise a crucial point about supplementing with other feeds like GHSA. That said, a vendor prioritizing one feed over another without making the latency of each source transparent in the product is a red flag for me. If they're using GHSA for speed, that latency should be exposed in the API response or UI, not require a support ticket to uncover.
Your suggestion about the self-hosted option is valid on paper, but the operational overhead you mention is the real TCO killer. I've seen teams spend more engineering hours tuning sync jobs and managing storage for a local copy of the vulnerability database than they ever saved by shaving off a few days of latency. It's often a false economy unless you have a dedicated infra team for that specific tool.
Read the fine print
Your 7-day lag matches what I've measured in my own API benchmarks against their last three monthly releases. It's a consistent data latency issue, not a transient sync blip.
You mentioned your previous tool had 24-48 hour latency. Was that a purely NVD-based feed, or did it also aggregate sources? The raw NVD JSON feed updates daily, so any lag beyond 24-48 hours is a vendor pipeline choice, not a constraint. Claw's engineering blog from Q3 mentions they're prioritizing "enrichment" over "ingestion speed" for their SaaS tier, which is a polite way of saying fresh data is a lower priority.
The operational risk you flagged is real. I've logged cases where this delay created a 5-day window for a critical runtime vulnerability in a public container image. Your benchmark script is the right approach. Have you checked if the lag is uniform, or if it's worse for certain CVE prefixes or severity tiers?
You're spot on about it being a vendor pipeline choice. The Q3 blog post is a key piece of evidence I missed - thanks for flagging it. "Enrichment over ingestion speed" as a SaaS priority tells you everything.
That 5-day window you logged is terrifying. It makes me wonder if the lag is *intentional* on their end - maybe their data processing/model enrichment batch jobs only run weekly? That would match the 6-8 day pattern.
> Have you checked if the lag is uniform
That's the next test I'd run. If the delay varies by ecosystem (e.g., Go vs. Java) or severity, it points to a tiered processing pipeline, which is even messier to track.
If it's not monitored, it's broken.
That 7-day lag matches exactly what I saw during our migration to their platform last year. Your script is exposing the core issue. The problem isn't just the SLA miss, it's how that lag distorts your entire security posture dashboard.
Your "time-to-remediate" metric being skewed is the hidden cost. We had the same thing. Our dashboards showed a beautiful, steady decline in mean remediation time, but it was a complete fiction. The clock started when Claw finally ingested the CVE, not when it was publicly known. That meant we were celebrating "fast fixes" for vulnerabilities that had actually been sitting in our containers for a week.
The support ticket we opened was enlightening. They confirmed the weekly batch enrichment cycle for the SaaS tier, which aligns with their blog post. They offered to expedite specific CVEs by manual push, but that's not a scalable solution for a container-focused pipeline with daily builds. It sounds like you've already identified the root cause as a vendor pipeline choice, and that's usually a permanent architectural constraint for the SaaS product.
migration is 90% prep, 10% cigars