Run a security review on a pull request with Apex Flash
A pull request touches a login route and nobody on the team has time for a careful security read. Apex Flash can review the diff first, flag likely issues and suggest fixes, so a human reviewer can focus on the judgement calls.
Set it up
- Generate the diff for the pull request, including a few lines of context.
- Add one paragraph on what the service does and who can call the changed route.
- Send the diff and context to apex-flash with the review prompt.
- Triage the findings by confidence and severity.
- Reproduce each real issue in a test against your own dev environment.
- Post confirmed findings as review comments and add regression tests.
Authorisation boundary
Review code you own or are paid to review. Test any suspected issue only against your own development or staging environment, never someone else's deployed system.
Sanitised sample input
A small diff with two real problems, a string-built SQL query and a missing ownership check:
+@app.route("/api/invoices/<invoice_id>")
+@login_required
+def get_invoice(invoice_id):
+ row = db.execute(
+ "SELECT * FROM invoices WHERE id = '" + invoice_id + "'"
+ ).fetchone()
+ return jsonify(dict(row))The prompt and the call
Anchor the model to a known taxonomy. The 2021 OWASP Top 10 lists A01 Broken Access Control and A03 Injection, which map directly to this diff.
Review this diff for security problems only. Context: Flask API, users log in with sessions, invoices belong to one customer.
For each finding give: file and line, OWASP Top 10 2021 category, severity, a short explanation, a concrete fix as a diff, and your confidence (low/medium/high).
Skip style comments. If you see nothing, say so; do not invent findings.
<diff>
...git diff output...
</diff>With a real repository, build the request with jq so the diff is JSON-escaped for you:
git diff main...HEAD | jq -Rs '{
model: "apex-flash",
temperature: 0.2,
messages: [{role: "user", content: ("Review this diff for security problems only. Give file and line, OWASP category, severity, fix, confidence.\n\n" + .)}]
}' | curl -s https://wildwestapi.com/v1/chat/completions \
-H "Authorization: Bearer $WILDWEST_API_KEY" \
-H "Content-Type: application/json" -d @-Keys look like sk-ww-...; keep yours in the WILDWEST_API_KEY environment variable, never in the script. Calls to /v1/chat/completions use the OpenAI format, billing is pay-as-you-go, and prompts are not retained on /v1.
What to check in the output
- It should flag the SQL injection (A03) and the missing check that the invoice belongs to the caller, an insecure direct object reference (A01). If it misses either, run it again with more context.
- Open each cited line. Wrong line numbers are common when the diff is long; split it by file.
- Read the proposed fix. Parameterised queries are the right answer for the injection, but make sure the fix does not break the data layer.
- It cannot see code outside the diff. Auth middleware, config and framework defaults can make a finding wrong either way.
Both apex-flash and glm-5.3-flash-cyber are security-tuned models with a 1M-token context window, tool calling and vision. They are not uncensored models, and they are meant for defensive and authorised work like this. Treat it as an extra reviewer, not a gate. Keep your SAST and human review.
Where this fits
Use STRIDE threat modelling before code is written and scanner triage for tool output. See penetration testing use cases and red team tools.
FAQ
Can it review a whole repository?
The 1M context window allows large inputs, but results are better when you review per pull request or per module.
Will it replace SAST?
No. Use it alongside static analysis and human review. It reads intent and context that rules miss, and misses things rules catch.
Does my code get stored?
Prompts are not retained on /v1. Check your company policy before sending proprietary code to any outside service.