Step-by-step: Creating a custom security policy bundle for Claw.

Hey everyone! I've been testing Claw (the new SAST tool from VectorForge) for a few weeks now, and while the default rules are good, I hit a wall when I needed to enforce some *very* specific internal security patterns. Their docs on custom policy bundles are a bit... sparse.

So I figured I'd document my process for building a custom bundle from scratch. My context:
* **Team Size:** ~25 engineers across 4 squads.
* **Stack:** Primarily Node.js/TypeScript backend, React frontend, with some Python data services. Everything's on AWS, deployed via Kubernetes.
* **Self-hosted?** Briefly considered Snyk's self-hosted option, but Claw's SaaS model won for us due to lower infra overhead.

The goal was to create a bundle that catches:
1. Specific AWS SDK misconfigurations our last audit flagged.
2. A custom pattern for how we handle environment variables in our Node services.
3. A rule to flag uses of `eval()` (which our linter sometimes misses in dynamic code).

Here's a step-by-step breakdown of how I built the `.clawbundle` file:

**Step 1: Foundation**
Start with the minimal valid bundle structure. You need a `manifest.yaml` and a `rules` directory.
```yaml
# manifest.yaml
formatVersion: "1.0"
name: "company-security-bundle-v1"
description: "Custom security policies for Acme Corp."
version: "1.0.0"
```

**Step 2: Writing a Custom Rule**
Rules are written in Rego (Open Policy Agent). I created `rules/aws_s3_misconfig.rego`.
The key was learning to hook into Claw's existing AST nodes. Their support team pointed me to the `claw.aws.s3` data structure.

**Step 3: Testing Locally**
Claw's CLI has a `claw bundle test` command. You point it at a directory of sample code (I used some past buggy commits) and your bundle. Iterate here until your rules fire (or don't) as expected.

**Step 4: Deployment & Rollout**
Once validated, you upload the bundle via the CLI:
```bash
claw bundle upload --file ./dist/bundle.zip --team backend-services
```
We rolled it out to one squad first, monitored the findings in the dashboard for a week, then enabled it company-wide.

**Biggest Gotchas:**
* The Rego can be tricky if you're new to it. Lean on their provided examples.
* Version your bundles! We tag them in git and the manifest.
* Not all AST nodes are exposed for custom rules yet. I had to request access to the `claw.web.http` scope for a future rule.

The process took me about two days, mostly in Step 3. The payoff is huge—we're now catching issues at the PR stage that used to slip to production. Has anyone else built a custom bundle? I'm curious how you handle rule priority when mixing default and custom rules.