Alright, who else is staring at a 3 AM pager alert because your fancy AI assistant decided to `subprocess.call(os.remove('/'))`? 😅 My OpenClaw agent has been a beast for generating Terraform modules, but its Python output... let's just say it's a little too creative with `eval()` and hardcoded secrets.
I need to bake a security linting step into its workflow before it commits another CVSS 10 masterpiece to my repo. I'm already running the generated code through `black` for formatting, but I need something that catches the *dangerous* stuff.
Current setup is basically a GitHub Actions workflow that:
1. Triggers on a PR with generated code
2. Runs `black --check`
3. Runs `pytest` on a simple test suite
4. Merges if green
I'm thinking of slotting in `bandit` or `safety` right after step 2. But I've got questions for the trenches:
* **Bandit config:** What's the minimal `.bandit.yml` to catch the real nightmares (shell injection, deserialization, temp file races) without drowning in false positives from generated code patterns?
* **Failure mode:** Should this be a hard gate (break the build) or just a warning comment on the PR? My gut says break the build—this is automated code, after all.
* **Where else?** Should I also be linting the *prompt* or the agent's *instructions* somehow, or is post-generation scanning sufficient?
Here's my Actions snippet so far. Where would you slot the linter?
```yaml
- name: Lint with Black
run: black --check ./generated_code/
# New step here?
- name: Test
run: pytest ./generated_code/tests/
```
Share your battle-tested configs. My on-call rotation thanks you.
NightOps
I'd definitely go with bandit as your hard gate, and I run it in a similar setup. For the config, skip trying to tune it too much at first - just run with `-ll` for low/medium confidence issues to catch the real troublemakers like `eval()` and `os.system` calls. That's been enough to flag the dangerous patterns without too much noise from generated code.
You'll want to break the build, absolutely. I made the mistake of allowing warnings on PR comments and my team started ignoring them within a week. Make it a required status check in GitHub so the PR can't merge.
Quick bandit step I use:
```yaml
- name: Run bandit
run: |
pip install bandit
bandit -r . -ll
```
If you start getting false positives, you can add a `.bandit.yml` to exclude specific test directories or suppress certain test IDs. But start simple - let it block anything that could cause that 3 AM pager again.