Skip to main content

Overview & Core Concepts

VibeReview shifts security left of the keystroke. Instead of finding vulnerabilities after code is committed, it shapes the code while your AI assistant is generating it. This page defines the concepts you will see throughout the product.

The core idea: secure by design + secure by code​

Every feature VibeReview helps build is produced in two reinforcing passes:

  1. Secure by design — threat modeling. When you write a prompt in your AI IDE, VibeReview threat-models that prompt across a structured set of categories (the PWNISMS model). It identifies what could go wrong with the feature before a line is written.
  2. Secure by code — deterministic guardrails. VibeReview then pulls the repository's guardrails — deterministic, repository-specific do's and don'ts — and uses them to implement the feature. Because guardrails are deterministic rather than advisory, the same secure pattern is applied every time.

The result is a feature whose design risks were reasoned about up front and whose implementation follows pre-approved secure patterns.

Key concepts​

Project​

A project maps one repository to VibeReview. It holds the repository's generated guardrails, its code and architecture profiles, scan history, PR-review configuration, compliance frameworks, and settings. Projects live under Vibe Reviews in the web app.

Guardrail​

A guardrail is a single, deterministic security rule expressed as a DO or a DON'T, tagged with a category (authentication, authorization, validation, config, data exposure, data integrity, persistence), and mapped to CWE and OWASP Top 10 references. Guardrails come from three origins:

  • Default Pack — baseline rules for the detected stack.
  • AI Generated — rules synthesized by profiling your repository.
  • Manual — rules your security team adds or edits.

Code profile & architecture profile​

  • The code profile is the LLM's scan of the repository that detects the stack and seeds guardrails.
  • The architecture profile maps services, trust boundaries, and sensitive data flows. It is required to generate grounded guardrails and to give PR review architectural context.

Scan, event, and threat​

  • A scan is a unit of work reported from the IDE (one coding task / workflow).
  • An event is a structured record inside a scan describing what was built and what security was applied.
  • A threat mitigated is a specific risk the threat model surfaced and the implementation addressed, each with a severity (Critical / High / Medium / Low).

Best practices & secure code snippets​

Each event records best practices achieved (e.g. "least-privilege file permissions") and the secure code snippets that were applied, so the security work is auditable down to the line.

PR review​

A post-commit, trust-but-verify check. When a pull request violates a guardrail, VibeReview writes the violation back into the PR as a review comment.

Where threats come from: the PWNISMS model​

Threat models in VibeReview are organized across the seven PWNISMS categories. You will see the PWNISMS tag on every mitigated threat in an event:

Example threats from a real event: Path traversal via report id (HIGH), World-readable export files / CWE-276 (HIGH), Unauthorized export creation (MEDIUM), Unsafe export root configuration (MEDIUM), Information disclosure via errors (LOW).

Compliance mapping​

Because each guardrail maps to CWE and OWASP references — and projects can declare frameworks such as OWASP ASVS, PCI DSS, ISO 27001, NIST SP 800-53/CSF/SSDF, HIPAA, GDPR, and more — the security work done during coding rolls up into compliance-aware reporting. See Reports.

Next​