Build a Local Vulnerability Helper with AI
Something you can use today.
Build a Local Vulnerability Helper with AI
The Weekly Build
Security reviews are tedious. You read code, trace execution paths, write tests, apply patches, and repeat. This week we are building a workflow that uses AI to accelerate the process without surrendering control.
The core approach is straightforward: isolate the suspicious code, bundle it with evidence, and direct the model toward concrete actions rather than generic advice.
Step 1: Pick a small target
Choose a repository you can run locally. Ideally under 5,000 lines or with clear setup steps. If you do not have one, use your own codebase and focus on a single file where security would matter. A contained target produces better results than a sprawling codebase.
Step 2: Create an evidence bundle
Create a folder called `vuln_bundle`. Inside it, place the file you suspect, any error logs or stack traces, and a short description of what you expected to happen. This bundle keeps the model grounded in facts rather than speculation.
Step 3: Prompt with a fix orientation
Open your AI tool and paste the suspected code, the evidence from `vuln_bundle`, and this prompt:
You are a security reviewer. Do not suggest vague advice.
Step 1: Identify the most likely vulnerability class.
Step 2: Point to exact lines in the code that cause it.
Step 3: Propose a minimal proof test I can run locally.
Step 4: Provide a patch that fixes the issue without changing unrelated behaviour.
Step 5: Add regression test cases.
Constraints:
- Prefer tests I can run with existing commands in the repo.
- If you need assumptions, ask.Step 4: Request exact commands
When you receive a patch, ask specifically:
What exact commands should I run to verify the patch? Include any env vars or config files needed.Vague instructions produce vague results. Demand specificity.
Step 5: Validate with your existing toolchain
Run the tests or linters the repo already uses. If there is no test suite, run the closest available check first, then create a minimal test based on the AI guidance.
Step 6: Iterate once, then lock
If the first patch fails, provide the failing output and ask for a revision. After one pass, freeze the change, review it manually, and commit. Do not keep prompting indefinitely.
Step 7: Write a one-page fix summary
Document what the issue was, what changed, what tests you added, and any follow-up work such as input validation coverage. This becomes a reusable reference for future reviews.
This Week's Challenge
Take a repository you own or a small open-source project. Identify one file with potential security implications. Create a `vuln_bundle` folder and populate it with the suspicious code, any error logs, and a description of expected behaviour. Apply the fix-oriented prompt above and document the response. At the end you should have a clear understanding of the vulnerability and a concrete patch to apply.
Try it and reply with what happened.
Forward this to one person who should be using AI better than they are. Reply with what you built, tried or broke this week. I read every one.
Gareth, founder of The Anthropic Stack (theanthropicstack.com)
