While evaluating Claw's static analysis capabilities for a CI/CD pipeline integration, I discovered a particularly useful feature that isn't prominently highlighted: the ability to export all security and code quality findings as a CSV file. This moves the tool from a simple dashboard viewer to a viable data source for longitudinal analysis.
The command is straightforward:
```bash
claw export --format=csv --output=claw_findings_$(date +%Y%m%d).csv
```
The resulting CSV includes columns for vulnerability type, severity, file path, line number, commit hash, and detection rule. This export functionality was critical for my team's context (approx. 15 engineers, Go/Python stack, self-hosted GitLab). We needed to correlate findings over time with other metrics from our monitoring stack, something the native UI couldn't support.
Primary use cases we validated:
* **Trend Analysis:** Joining the CSV with Jira data to track fix velocity per severity level.
* **Custom Reporting:** Generating team-specific reports filtered by service ownership, which we derived from the file path patterns.
* **Benchmarking Baseline:** Creating a performance baseline before and after major static analysis rule updates.
We had previously considered purely dashboard-centric tools, but this data portability was a deciding factor. The CSV structure is clean, allowing for direct ingestion into data warehouses or simple spreadsheet analysis. For teams requiring audit trails or wanting to build custom severity scoring, this feature significantly increases the tool's utility.
Benchmarks > marketing.
BenchMark
Oh that's super handy! I've been struggling to get my team interested in Claw's dashboard. Maybe if I could put the findings into our weekly metrics report they'd actually pay attention.
How well does the CSV handle large projects? I'm nervous about exporting our whole codebase at once and ending up with a huge, messy file.
The CSV handles size decently, but you're right to be nervous. It's a raw dump, not a summary. On a monorepo with 400+ services, I've gotten 80MB files that choked Excel but were fine in pandas or BigQuery.
If you're doing weekly metrics, you'll need to post-process. I usually pipe the CSV through a quick Python script to roll things up by severity and team ownership before it hits a dashboard. The real power is joining that data with your Jira tickets or deployment history to see if fixes are actually getting done.
Honestly, a huge messy file is sometimes the best motivator. Nothing says "we have a problem" like a spreadsheet that takes three minutes to open. Good luck
Yep, that's the exact workflow. Feeding the CSV into a small Python script or even just SQL against a staging table gives you way more flexibility than the dashboard ever could.
One thing I'd add: joining with deployment history is a game-changer. We've started tagging exports with the deployment ID and feeding them into a data lake. A few months of that and you can start to see if new releases are actually *adding* new categories of vulns or just rehashing old ones. Makes for a much better story than a static count.
> Honestly, a huge messy file is sometimes the best motivator.
True, but I've also seen it cause alert fatigue. A 10,000-row CSV can make a problem seem too big to start on. Rolling it up to, say, "top 5 critical vuln types this week" usually gets better traction from management in my experience.
ship it
Nice find! That export feature saved our bacon during last year's PCI compliance push. We had to prove we were reducing certain finding categories over time, and the dashboard just didn't cut it for the auditors.
One watch-out from my experience: the file path column can be a blessing and a curse for > custom reporting. If your repo structures aren't perfectly consistent, you'll spend a fair bit of time writing regex to parse out service names reliably. Our "backend/user_service" and "backend-userservice" patterns caused some headaches before we standardized.
Feeding this into a simple timeseries DB (we used Influx) made those trend graphs a breeze, though.
it worked on my machine
That's exactly where we landed too! The file path parsing for service ownership becomes a proper mini-project of its own. We ended up writing a simple mapping file that translated regex patterns to team names, which we then used in our weekly roll-up script.
One nuance we hit - the commit hash is golden for linking to deployment data, but only if your Claw scans are actually tied to the same commits that get deployed. If you're scanning main nightly but deploying feature branches, the correlation gets fuzzy. We had to adjust our scan trigger to match our release cadence more closely.
Have you found a clean way to handle findings that reappear in the same file but on a different line after a refactor? Our scripts initially counted them as new, which skewed the 'fix' rate.
Try everything, keep what works.
That correlation with Jira is exactly what we're missing right now. You mentioned using the file path to figure out team ownership. How do you handle services that multiple teams touch? Does each team just get the whole list, or do you split it somehow?
Yeah, that longitudinal angle is clutch. I've seen so many teams get stuck in the "point-in-time" dashboard trap. The export turns it into a data asset you can actually work with.
We did something similar but fed the CSV into a dedicated Postgres instance instead of joining directly with Jira. It let us write some pretty slick queries to track, for example, if high-severity findings in a specific service were *ever* linked to a ticket, or if they just disappeared (probably ignored or swept into a massive refactor ticket).
One thing I'd watch with the commit hash correlation: if your development style uses a lot of squash merges, the hash Claw sees on `main` might not match the hash from the original feature branch. Threw off our early "time to fix" metrics until we normalized on the merge commit.
Still looking for the perfect one
The merge commit normalization is a critical point that gets missed in a lot of benchmarks. We found the same issue and built a small reconciliation service that maps the post-squash hash back to the original feature branch commit using the Git log, storing both in our analytics table.
Your Postgres approach is interesting. We went with a dedicated data warehouse, but the core query pattern is similar. The most valuable metric that emerged for us was the "ticket creation rate" for new high-severity findings. We could see teams that consistently created tickets within 24 hours of a scan vs. those where findings languished. It turned abstract "fix rates" into a measurable process gap.
Have you tracked the performance overhead of running those joins in Postgres once the finding history grows to, say, a million rows? We had to add some aggressive indexing on the commit hash and file path.
—chris
That's a fantastic discovery! So many teams get stuck just watching the dashboard and never get to the real goal: improving over time.
Your point about correlating with Jira data for fix velocity is key. We started doing that and found a huge gap between "findings introduced" and "findings fixed" that the dashboard totally masked. The CSV made it impossible to ignore.
One tiny thing I'd add: when you're joining with Jira, be mindful of ticket *reopenings*. We initially just counted a 'linked' ticket as a 'fix,' but some tickets would get reopened weeks later when the finding resurfaced. We had to start tracking the *last closed date* on the ticket to get a true picture. It made our fix-rate graphs a lot less optimistic, but way more accurate!
Automate all the things
Great point about using the CSV for benchmarking baselines. We did the same thing right before rolling out a new secure coding workshop. Being able to show a concrete "before" snapshot made the "after" results feel much more real to the team.
One thing we learned the hard way: if you're using this for a pre/post benchmark, make sure you run the export from the *exact same* Claw version and rule set. They pushed a minor rules update midway through our experiment and suddenly we were comparing apples to oranges. We had to re-run the old version to get a clean baseline.
Beta tester at heart
You're right, it's a useful feature. But I'd call that table stakes for any tool in this category that wants to be taken seriously in a procurement process. If you can't get your own data out, you're just renting a dashboard.
The real test is what you're allowed to do with that CSV after you've exported it. Check your license agreement for clauses about "derivative works" or restrictions on aggregating their findings data with other sources. Some vendors get nervous when you stop looking at their pretty graphs and start building your own analysis. It can become a contract sticking point on renewal.
Show me the TCO.
Oh that's a good point about the license agreement. I hadn't thought about that at all. It makes sense though - if they see you building your own dashboards, maybe they think you won't renew.
Has anyone actually had a vendor push back on that? Like, gotten a call from their sales team asking why you're exporting so much? 😅
Spotting a vendor getting nervous about data exports is more common than you might think, especially in pre-sales security reviews. I've seen it manifest not as a direct call, but as restrictive clauses in the final license language aimed at prohibiting "aggregation with third-party tooling" or creating "composite metrics." The goal is often to lock you into their ecosystem for reporting.
The proactive move is to include data portability and usage rights as a non-negotiable line item in your initial RFI. Frame it as an operational necessity for audit trails and regulatory compliance, not just convenience. That shifts the discussion from a "maybe" to a requirement.
Glad you found the CSV export, but calling it a "feature" is a bit generous, isn't it? It's your data. Exporting it should be the default state, not a hidden gem they forgot to advertise.
You're right about the UI being limiting, but that's the point. The vendors *want* you stuck in their dashboard. Once you start joining with Jira and building your own reports, you realize how little value their shiny interface actually adds to the raw data.
The real test is if they let you run that export in an automated pipeline without hitting API limits. Some "open" platforms get real cagey when you start pulling nightly dumps for your own warehouse.
FOSS advocate