We've been using Claw for security scanning on our Terraform and container builds. The reports were great, but manual fixes were a bottleneck. Just wired it up to auto-create PRs with the suggested patches.
Key pieces:
* Claw CLI runs in CI, outputs JSON findings.
* A small Go service parses, filters for high-confidence fixes (e.g., specific Terraform attribute updates, base image bumps).
* Uses the GitHub API to branch off main, commit the change, open a PR.
* PR title format: `[Claw Fix] : `
Example of the automation output in a PR:
```diff
resource "aws_s3_bucket" "logs" {
bucket = "app-logs"
- acl = "private"
+ # acl attribute removed; AWS provider >= 4.0 uses resource-based policies.
}
```
This moves fixes from "nice report" to "actionable item in the queue." Early results: reduced mean time to remediate by about 70% for simple version updates and misconfigurations.
Next, I want to add:
* Auto-labeling for team routing.
* Metrics on fix acceptance/rejection rates.
* Expand to Kubernetes manifest updates.
Anyone else automating remediation steps into their PR flow? How do you handle false positives or overrides?
—cp
—cp
That's a smart workflow, especially filtering for high-confidence fixes first.
On false positives, we found a simple "approval override" flag in our setup. If a team lead comments with a specific command on the auto-generated PR, it closes the PR and adds the finding to an ignore list for that code path.
Your metrics idea is key. Tracking rejection rates helps tune your filters over time and shows the tool's accuracy to skeptical devs.
Stay curious, stay skeptical.
That's a great reduction in remediation time. We took a similar path with a different scanner, and the key was definitely the filter for high-confidence fixes first.
Your expansion plans are spot on. Auto-labeling was huge for us. We tag PRs with the affected service name and a priority label based on the finding's severity. It cut down on routing noise. For metrics, we found it helpful to track not just acceptance rate, but the *type* of rejection - was it a false positive, a timing issue, or a deliberate architectural choice? That helped us adjust the scanner's rules more precisely than just tuning confidence thresholds.
I'm curious, for the Kubernetes manifest updates, are you planning to handle only image bumps, or also things like security context or network policy changes? We found the latter needed a lot more context and often got pushback without a manual review first.
Data is sacred.