THREAT MODEL
Repo-specific. Refreshed per commit.
VibeReview reads the FastAPI router, identifies the JWT middleware, traces the SQL driver. The threats it generates are the ones in your code, not a catalogue dump.
FOR APPSEC TEAMS ADOPTING AI
Threat-informed guardrails. Real coverage. Fewer false positives.
Your SAST tool fires on patterns. VibeReview fires on paths. It reads the repo, builds a threat model of the actual risks, generates guardrails per risk, and routes only the relevant ones into PR review.
14-day free trial · No card required
You prompting Cursor · app/api/orders.py
"Add an endpoint to fetch user orders by ID."
VibeReview matched 3 guardrails · invisibly - ✓ Parameterize SQL queries
- ✓ Require an authenticated user
- ✓ Filter rows by tenant
@app.get("/orders/{order_id}")
def get_order(
order_id: int,
user = Depends(auth),
):
return db.execute(
"SELECT * FROM orders "
"WHERE id = ? AND user_id = ?",
(order_id, user.id),
)✓ Built secure on the first prompt — no review needed.
GUARDRAILS
Policy as code, not SAST rules.
Custom rules per repo, per stack, per risk. Versioned. Diffable. Tightened over time without a vendor update cycle. Your team owns them.
COVERAGE
OWASP, CWE, and your taxonomy.
Each guardrail maps to OWASP Top 10, CWE entries, and the framework taxonomy your team uses. Coverage reports tell you what's in scope and what needs another rule.
CONNECT
Point VibeReview at the repo.
Install the GitHub or GitLab App. Read-only OAuth scope. Code is profiled in ephemeral compute and never persisted.
REVIEW
Read the generated threat model.
Trust boundaries, entry points, sensitive data flows, AI failure modes. Edit assumptions where you disagree. Approve.
TIGHTEN
Edit guardrails as code.
Each rule is a YAML file in a repo your team controls. Add bank-specific tokenization checks. Tighten the auth pattern. Diff and review.
ENFORCE
MCP plus PR review.
Guardrails load in the IDE at prompt time and run again on the PR. Two enforcement surfaces for one set of rules.
APPSEC QUESTIONS
What AppSec engineers ask first.
Do you store my source code?
No. We read it to build a profile, then we keep only the profile metadata (languages, frameworks, etc.) — not your source.
Can I write my own guardrails?
Yes, on Team and above. Add them in the dashboard or via the vibereview-kit CLI; they'll show up in your IDE on the next sync.
How does VibeReview decide which guardrails apply to my repo?
We threat-model your repo first. We read it for entry points, trust boundaries, where user input lands, where secrets live, and the moves an AI coding agent is most likely to mis-handle. The code profile — languages, frameworks, drivers, CI — is built against that threat model: stack facts in service of the threats they introduce. Guardrails are then generated as direct responses to each threat, mapped onto the OWASP Top 10 and Cisco AI Security Taxonomy. Nothing in the rule set is generic. Every rule traces back to a real threat your repo has.
How is VibeReview different from SAST tools like Snyk Code, Semgrep, or SonarQube?
SAST is reactive: scan after the fact, return a triage queue of findings. VibeReview is proactive: we threat-model the repo first, generate guardrails for those specific threats, then feed the rules to the IDE while the code is being written. The threats often never make it into the PR. When a PR does land, we comment only on the diff lines that crossed a rule — not the whole file. Run SAST for periodic audits; run VibeReview for the prompt-to-PR loop.
Isn't this just another SCA or dependency scanner?
Different layer. SCA flags known CVEs in your package manifest. VibeReview flags hazards in the code your team — or your AI — just wrote, against a threat model of your repo: SQL string interpolation on a user-input path, secret logging, missing webhook signature checks, tool-output trust in MCP clients. Run both.
How is this different from running OWASP Top 10 checklists?
OWASP is a catalog of categories. A threat model is the list of categories that actually apply to your repo and how they show up in your stack. VibeReview builds the threat model first — entry points, trust boundaries, AI failure modes — then maps it onto OWASP and the Cisco AI Security Taxonomy. The result is a set of rules that name a real threat in your code, not a generic checkbox. Each rule is editable, versioned, and toggleable.
Bring your hardest repo. We threat-model it on a call.
30-minute walkthrough on a shared screen. You see the threat model. You see the guardrails. You decide.