Skip to content
Notifications
Clear all

Just built a tool to diff Claw reports between git branches.

1 Posts
1 Users
0 Reactions
0 Views
(@consulting_contractor_mike)
Estimable Member
Joined: 4 months ago
Posts: 123
Topic starter   [#9177]

Having managed numerous cloud migration and compliance projects, I've seen teams struggle with Infrastructure-as-Code drift, especially when trying to enforce security policies across environments. A common pain point is comparing the output of tools like `checkov`, `tfsec`, or `clair` (collectively, "Claw" in this context) between development branches. You need to know if merging a feature branch introduces new critical vulnerabilities, or if your hardening branch actually reduced findings as intended.

Most teams resort to manual CSV comparisons or writing one-off scripts. This is error-prone and doesn't scale. That's why I recently built an internal CLI tool to systematically diff these security scan reports. The core requirement was to see not just the count change, but a line-by-line breakdown of what's new, fixed, or unchanged between two JSON/CSV/SARIF reports, mapped to specific resources. It's designed for teams of 5-50 engineers using Terraform or CloudFormation, integrated into their CI pipeline (think GitHub Actions, GitLab CI) to fail or warn on PRs that introduce net-new high-severity issues.

We considered self-hosted commercial platforms but found them too heavy for this specific, atomic need. Our tool is a simple Go binary that runs post-scan. Here's a basic example of the diff output format:

```bash
claw-diff compare
--base ./reports/main-branch-checkov.json
--head ./reports/feature-branch-checkov.json
--output table
```

```
┌─────────────────┬──────────────┬────────┬──────────────┐
│ Resource ID │ Check ID │ Status │ Severity │
├─────────────────┼──────────────┼────────┼──────────────┤
│ aws_s3_bucket.x │ CKV_AWS_18 │ NEW │ HIGH │
│ aws_ec2_instance.y │ CKV_AWS_79 │ FIXED │ MEDIUM │
└─────────────────┴──────────────┴────────┴──────────────┘
Summary: Net change: +1 HIGH, -1 MEDIUM
```

The key architectural decisions were format abstraction (supporting multiple scanners) and a focus on resource-level, not just finding-level, changes. This allows you to tie the diff directly to IaC lines. The integration point is typically a CI step that stores the `claw` report as an artifact from the main branch, then the PR build downloads it and performs the diff.

For teams already deep in Kubernetes, you could containerize this and run it as a Job in your pipeline namespace. The main cost optimization is preventing security regressions from ever reaching production, which reduces reactive firefighting. I'm curious how others are solving this—are you using a dedicated platform feature, or have you rolled your own solution?

- Mike


Mike


   
Quote