VibeSec

vibesec · untamed-theory/vibesec · ★ 46 · last commit 2025-08-07

Primitive shape

No installable primitives

Summary

VibeSec — Summary

VibeSec is a security rules bundle for Cursor and Windsurf AI coding assistants that installs OWASP-aligned security guidelines directly into the IDE's rule system (.cursor/rules/*.mdc or Windsurf's .windsurf/rules/*.md) via a single bash install script.

Problem it solves: Developers using AI vibe-coding tools (Cursor, Windsurf) lack security context by default — the AI will happily generate SQL-injectable queries, weak password hashing, or prompt-injection-vulnerable LLM integrations unless the IDE's rule layer injects security constraints.

Distinctive trait: The framework maintains canonical rule definitions in a definitions/ directory and uses a build_rules.sh script to generate IDE-specific versions for both Cursor (.mdc with YAML frontmatter and glob matchers) and Windsurf (plain .md) from the same source — a dual-format build system for security rules.

Target audience: Solo developers and small teams using Cursor or Windsurf who want OWASP Top 10 and framework-specific security guidance injected automatically into their AI assistant's context.

Production-readiness: Early-stage community project (46 stars, AGPL-3.0), maintained by Untamed Theory. Last commit August 2025, indicating dormant state.

Differs from seeds: VibeSec is closest to the Archetype 4 (Markdown scaffold, zero primitives) pattern used by agent-os and claude-conductor, but targets Cursor/Windsurf rather than Claude Code, and focuses exclusively on security rules rather than general workflow scaffolding. Unlike spec-kit's command/skill mirror pattern, VibeSec has no commands or skills — purely passive rules injected via IDE-specific file formats. The dual-format build system (definitions → windsurf + cursor) is unique in the corpus.

Overview

VibeSec — Overview

Origin

VibeSec was created by Untamed Theory, described as "Security Rules & Workflows for the new wave of AI Development." It targets the wave of AI pair-programmers (Cursor, Windsurf) that emerged with "vibe coding" culture.

Philosophy

The core philosophy is that AI coding assistants generate insecure code by default unless security rules are injected into their context at the rule/configuration layer. VibeSec treats OWASP Top 10 categories as the baseline security vocabulary and distributes them as IDE-native rules rather than training the AI differently.

From the README:

"Downloads security rules for Windsurf and Cursor development workspaces. Pretty Simple."

"Consistent security guidelines that work seamlessly across both Windsurf and Cursor AI assistants."

Security Categories Covered

frontend: CORS, NextJS best practices, Supabase authentication, UI security
backend: Rate limiting, API security, server-side validation
database: SQL injection prevention, Supabase hardening, data access controls
infrastructure: Secrets management, configuration security, deployment safety
ai: LLM prompt injection prevention, model security
supply-chain: Dependency management, secure package selection, SBOM
general: OWASP Top 10, cross-cutting security concerns

Target Tools

Primary: Cursor (.cursor/rules/*.mdc) and Windsurf (.windsurf/rules/*.md). The .windsurf directory structure is detected automatically by the install script. No Claude Code, Codex, or other tools supported.

Contribution Model

Rules follow a naming convention: all security rules start with prefix security-. Contributors create canonical rules in definitions/, run ./scripts/build_rules.sh to generate IDE-specific versions, then submit a PR.

Architecture

VibeSec — Architecture

Distribution

Type: bash-script-bundle (install script + pre-built rule files)
No npm/pip package — raw file installation via curl + bash
License: AGPL-3.0

Install Methods

# Auto-detect environment (defaults to Windsurf)
curl -sL https://raw.githubusercontent.com/untamed-theory/vibesec/main/scripts/install.sh | bash

# Force Cursor
curl -sL https://raw.githubusercontent.com/untamed-theory/vibesec/main/scripts/install.sh | bash -s -- --cursor

# Force Windsurf
curl -sL https://raw.githubusercontent.com/untamed-theory/vibesec/main/scripts/install.sh | bash -s -- --windsurf

Required Runtime

bash
curl
The target IDE (Cursor or Windsurf) installed

Directory Structure

vibesec/
├── definitions/          # Canonical security rule source (IDE-agnostic)
│   ├── ai/               # LLM security rules
│   ├── backend/          # API and server-side rules
│   ├── database/         # Database security rules
│   ├── frontend/         # UI and client-side rules
│   ├── general/          # OWASP Top 10 and cross-cutting
│   └── infrastructure/   # Secrets and deployment rules
├── rules/                # Built IDE-specific rules (generated by build_rules.sh)
│   ├── cursor/           # .mdc format (with YAML frontmatter + globs)
│   │   ├── ai/
│   │   ├── backend/
│   │   ├── database/
│   │   ├── frontend/
│   │   ├── general/
│   │   └── infrastructure/
│   └── windsurf/         # .md format (plain markdown)
│       ├── ai/
│       ├── backend/
│       ├── database/
│       ├── frontend/
│       ├── general/
│       └── infrastructure/
├── scripts/
│   ├── install.sh        # Detects IDE, copies rules to .cursor/rules/ or .windsurf/rules/
│   └── build_rules.sh    # Builds IDE-specific rules from definitions/
└── static/               # Banner image

Target AI Tools

Cursor (.cursor/rules/*.mdc)
Windsurf (.windsurf/rules/*.md)

Not supported: Claude Code, GitHub Copilot, Codex, Gemini CLI.

Cursor Rule Format

---
description: Security rule for security-owasp-top10
globs: ["**/*"]
alwaysApply: false
---
# OWASP Top 10 Security Guidelines
...

Cursor rules use alwaysApply: false and glob patterns. LLM-specific rules use narrower globs: ["**/*.py", "**/*.ipynb", "**/prompt*", "**/*llm*", "**/*ai*"].

Components

VibeSec — Components

Scripts (2)

Name	Purpose
`scripts/install.sh`	Detects Cursor vs Windsurf environment, copies appropriate rules from `rules/cursor/` or `rules/windsurf/` into project's `.cursor/rules/` or `.windsurf/rules/`
`scripts/build_rules.sh`	Generates IDE-specific rule files from canonical `definitions/` sources; run by contributors before PRs

Rule Categories (7 definition categories × 2 IDE formats = 14+ rule files)

General (Cross-cutting)

Rule	Globs	Coverage
`security-owasp-top10`	`["*/"]`	OWASP Top 10 2021 (A01-A10)
`security-nodejs-best-practices`	`["*/.js", "*/.ts"]`	Node.js security hardening

AI / LLM

Rule	Globs	Coverage
`security-llm-prompt-injection`	`["*/.py", "*/.ipynb", "*/prompt", "*/llm", "/ai*"]`	Prompt injection prevention, data exfiltration, output validation

Backend

(directory exists — specific file names not enumerated in public API)

Database

(directory exists — SQL injection, access controls)

Frontend

(directory exists — CORS, Supabase, UI security)

Infrastructure

(directory exists — secrets management, deployment)

No Commands, Skills, Hooks, or MCP Servers

VibeSec has zero agentic primitives. It is purely passive rule injection — the rules are read by the IDE's rule system and presented to the AI at relevant moments based on glob matching.

Total Rule Files

Approximately 12-14 rule files (2 general + 1 AI + backend/database/frontend/infrastructure categories × 2 IDE formats). Exact count depends on category expansion.

Prompts

VibeSec — Prompts

Prompt 1: OWASP Top 10 Rule (`rules/cursor/general/security-owasp-top10.mdc`)

Technique: Guideline enumeration with code examples showing "AVOID" vs "RECOMMENDED" patterns. No role assignment, no Iron Laws — passive reference material.

---
description: Security rule for security-owasp-top10
globs: ["**/*"]
alwaysApply: false
---

# OWASP Top 10 Security Guidelines

## Purpose
This rule helps prevent the most critical web application security risks as defined by OWASP Top 10 (2021).

## Guidelines

### A01:2021 - Broken Access Control
- Always implement proper authorization checks before allowing access to resources
- Use principle of least privilege for all accounts and services
- Deny access by default unless explicitly granted

```javascript
// AVOID: Direct object reference without access control
app.get('/users/:id', (req, res) => {
  const user = db.getUser(req.params.id); // Missing access check!
  res.json(user);
});

// RECOMMENDED: Proper access control check
app.get('/users/:id', (req, res) => {
  const currentUser = getCurrentUser(req);
  if (!currentUser || (currentUser.id !== req.params.id && !currentUser.isAdmin)) {
    return res.status(403).json({ error: 'Access denied' });
  }
  const user = db.getUser(req.params.id);
  res.json(user);
});


## Prompt 2: LLM Prompt Injection Rule (`rules/cursor/ai/security-llm-prompt-injection.mdc`)

**Technique:** Threat-specific guidelines with narrow glob patterns (`**/prompt*`, `**/*llm*`, `**/*ai*`), code examples for input sanitization, defense-in-depth strategies.

```markdown
---
description: Security rule for security-llm-prompt-injection
globs: ["**/*.py", "**/*.ipynb", "**/prompt*", "**/*llm*", "**/*ai*"]
alwaysApply: false
---

# LLM Prompt Injection Security Guidelines

## Guidelines

### Prompt Injection Prevention

#### Input Sanitization and Validation
- Always validate and sanitize user inputs that will be used in prompts
- Implement a clear separator between system instructions and user inputs
- Use techniques like input templating and escaping special characters

```javascript
// AVOID: Direct user input in prompts
async function generateResponse(userInput) {
  const completion = await openai.chat.completions.create({
    messages: [
      { role: "user", content: userInput } // Direct injection risk!
    ],
    model: "gpt-3.5-turbo",
  });
}

// RECOMMENDED: Sanitized and structured prompt
function sanitizeUserInput(input) {
  if (input.length > 1000) input = input.substring(0, 1000) + "...";
  input = input.replace(/system:/gi, "[filtered]")
               .replace(/\n\n/g, " ")
               .replace(/assistant:/gi, "[filtered]")
               .replace(/\{.*?\}/g, "[filtered]");
  return input;
}

Defense-in-Depth Strategies

Implement multiple layers of protection against prompt injection
Monitor and audit LLM inputs and outputs for suspicious patterns
Test your application against known prompt injection techniques

Uniqueness

VibeSec — Uniqueness

Differs from Seeds

VibeSec is closest to agent-os (Archetype 4 — markdown scaffold, zero primitives) in that both provide passive context injection with no commands, skills, or hooks. However, VibeSec targets Cursor and Windsurf rather than Claude Code and focuses exclusively on security rules rather than general development workflow. Unlike claude-conductor's P0/P1 error ledger pattern, VibeSec has no artifacts or state — just static rules. Unlike kiro's IDE-native hook system that enforces governance at spec-task execution time, VibeSec rules are entirely passive guidance with no enforcement mechanism. The closest parallel outside the seeds is the "rules-as-passive-context" pattern used by Cursor's own .cursor/rules/ convention.

Key Differentiators

Dual-format build system: Canonical definitions/ → generated Cursor .mdc + Windsurf .md from a single source.
Security-only focus: Only framework in the corpus with an OWASP-organized security rule catalog.
Non-Claude-Code: Explicitly targets Cursor/Windsurf, not Claude Code.
LLM-aware security rules: The security-llm-prompt-injection rule addresses prompt injection in AI applications being built by the AI — a meta-security use case.
Glob-scoped rules: LLM security rules only fire on **/prompt*, **/*llm*, **/*ai* files, reducing token overhead on non-relevant code.

Positioning

VibeSec occupies a niche: security context injection for Cursor/Windsurf. No other framework in the corpus exclusively targets these two IDEs with security-focused rules. It is simpler and narrower than any seed framework.

Observable Failure Modes

Stale rules: No update mechanism. As OWASP updates or new vulnerabilities emerge, rules must be manually re-installed.
Passive injection doesn't enforce: Rules are guidance, not hooks. A model can generate insecure code and the rule will have no blocking effect.
Cursor alwaysApply: false behavior: Rules only fire when matching globs are active; general rules with **/* globs may still fire too broadly.
No Windsurf detection reliability: Auto-detection may default to Windsurf in non-interactive environments even when Cursor is the actual tool.
AGPL-3.0 license: Commercial products must open-source modified versions — unusual for a rules bundle, may deter enterprise adoption.

Explicit Antipatterns

VibeSec does not enumerate explicit antipatterns beyond the OWASP violations the rules themselves document.

Workflow

VibeSec — Workflow

Overview

VibeSec has a one-time install workflow and no ongoing workflow primitives. After installation, rules are passive — the IDE injects them automatically when relevant files are edited.

Installation Workflow

1. Run install script (curl | bash)
2. Script detects IDE (Cursor presence → .cursor/; Windsurf → .windsurf/)
3. Copies rule files to .cursor/rules/ or .windsurf/rules/
4. Rules become active on next IDE reload

Ongoing Workflow (None)

After installation, no user action is required. The IDE rule system:

For Cursor: reads .mdc files with alwaysApply: false and applies them when glob patterns match
For Windsurf: reads .md rules from the rules directory

Contribution Workflow

1. Create canonical rule in definitions/<category>/security-<name>.md
2. Run ./scripts/build_rules.sh to generate cursor/ and windsurf/ versions
3. Submit PR with changes to all three directories

Phase-to-Artifact Map

Phase	Artifact
Install	`.cursor/rules/` or `.windsurf/rules/` populated with rule files
Build (contributor)	`rules/cursor/` and `rules/windsurf/` updated from `definitions/`

Approval Gates

None — fully automated install, no user approval steps.

No Specs, No Plans, No Tasks

VibeSec does not produce any spec, plan, or task artifacts. It is purely a rule injection system.

Memory Context

VibeSec — Memory & Context

State Storage

None. VibeSec has no state storage, no memory system, and no persistence beyond the installed rule files.

Context Injection

Rules are injected by the IDE rule system:

Cursor: Reads .cursor/rules/*.mdc files; alwaysApply: false means rules are injected only when glob patterns match the current file being edited.
Windsurf: Reads .windsurf/rules/*.md files via Windsurf's native rule mechanism.

No hooks, no SessionStart events, no CLAUDE.md injection — purely IDE-native.

Persistence Model

Install-time only: Rules are copied to the project once at install time.
No updates, no versioning, no cross-session state.
Updates require re-running the install script.

Compaction Handling

Not applicable — no Claude Code session involved.

Cross-Session Handoff

Not applicable — rule files persist on disk, available in every IDE session by default.

Orchestration

VibeSec — Orchestration

Multi-Agent

No — VibeSec has no agentic primitives. It is a passive rule injection system with no orchestration.

Orchestration Pattern

None.

Execution Mode

One-shot (install-time). After installation, rules are loaded passively by the IDE at each relevant editing moment.

Multi-Model

No — VibeSec is model-agnostic. It injects rules into whatever model the IDE (Cursor or Windsurf) uses.

Isolation Mechanism

None.

Consensus Mechanism

None.

Prompt Chaining

No — rules are static markdown files, not chained prompts.

Crash Recovery

Not applicable.

Streaming Output

Not applicable.

Ui Cli Surface

VibeSec — UI / CLI Surface

CLI Binary

None. The install script is a bash one-liner, not a CLI binary with subcommands.

Local Web Dashboard

None.

IDE Integration

Cursor: Rules installed to .cursor/rules/ — Cursor's native rule system reads .mdc files with frontmatter and glob patterns.

Windsurf: Rules installed to .windsurf/rules/ — Windsurf's rule system reads .md files.

Both integrations are passive — the IDE's own rule engine handles injection timing.

Observability

None — VibeSec has no logging, audit trail, or monitoring.

Supported Editors

Cursor
Windsurf

Not supported: Claude Code, VS Code (Copilot), JetBrains, Vim/Neovim.

Related frameworks

same archetype · same primary tool · same memory type

BMAD-METHOD ★ 48k

A4 Markdown scaffold

Provides a full agile delivery lifecycle with named expert-persona AI collaborators that elicit the human's best thinking rather…

Agent OS ★ 4.6k

A4 Markdown scaffold

Extracts implicit codebase conventions into token-efficient markdown standards files and injects them selectively into AI agent…

Claude Conductor ★ 367

A4 Markdown scaffold

Gives Claude Code a persistent, cross-linked, auto-analyzed documentation system so it retains codebase context across sessions.

Spec-Driver (Greenfield Spec-Driven Development) ★ 25

A4 Markdown scaffold

Prevents spec rot in AI-assisted development by making implementation changes flow back into evergreen, authoritative specs via…

Anthropic Knowledge Work Plugins ★ 16k

A4 Markdown scaffold

Role-specialized plugin bundles with live MCP connectors that turn Claude into a domain expert for enterprise knowledge workers.

Codex Integration for Claude Code (skill-codex) ★ 1.3k

A4 Markdown scaffold

Single Claude Code skill that handles Codex CLI invocation correctly (stdin blocking, thinking token suppression, session resume)…

Distribution

Type: bash-script-bundle
License: AGPL-3.0
Install: one-liner

Surfaces

CLI binary: No
CLI subcmds: 0
Local UI: No

Components

Commands: 0
Skills: 0
Subagents: 0
Hooks: 0
MCP servers: 0
MCP tools: 0
Scripts: 2
Templates: 14

Workflow

Phases: 1
Approval gates: 0
Spec format: none
Spec storage: none
Delta or full: none

Orchestration

Multi-agent: No
Pattern: none
Max concurrent: 1
Isolation: none
Consensus: none
Prompt chaining: No

Multi-model

Multi-model: No
BYOK: Yes
Modal: text

Execution

Mode: one-shot
Crash recovery: No
Compaction: No
Session handoff: Yes
Streaming: No

Memory

Type: none
Persistence: none
Search: none

Quality

TDD: No
TDD mechanism: none
Self-review: none

Git / Observability

Auto commit: No
Auto PR: No
Auto merge: No
Worktree/feat: No
Audit log: No
Audit format: none
Replay: No

Tools

Primary: cursor
Targets: 2
Portability: medium

Signals

Stars: 46
Last commit: 2025-08-07
Maintainer: dormant
Quality score: 0.5/10

Summary

VibeSec — Summary

Overview

VibeSec — Overview

Origin

Philosophy

Security Categories Covered

Target Tools

Contribution Model

Architecture

VibeSec — Architecture

Distribution

Install Methods

Required Runtime

Directory Structure

Target AI Tools

Cursor Rule Format

Components

VibeSec — Components

Scripts (2)

Rule Categories (7 definition categories × 2 IDE formats = 14+ rule files)

General (Cross-cutting)

AI / LLM

Backend

Database

Frontend

Infrastructure

No Commands, Skills, Hooks, or MCP Servers

Total Rule Files

Prompts

VibeSec — Prompts

Prompt 1: OWASP Top 10 Rule (rules/cursor/general/security-owasp-top10.mdc)

Defense-in-Depth Strategies

Uniqueness

VibeSec — Uniqueness

Differs from Seeds

Key Differentiators

Positioning

Observable Failure Modes

Explicit Antipatterns

Workflow

VibeSec — Workflow

Overview

Installation Workflow

Ongoing Workflow (None)

Contribution Workflow

Phase-to-Artifact Map

Approval Gates

No Specs, No Plans, No Tasks

Memory Context

VibeSec — Memory & Context

State Storage

Context Injection

Persistence Model

Compaction Handling

Cross-Session Handoff

Orchestration

VibeSec — Orchestration

Multi-Agent

Orchestration Pattern

Execution Mode

Multi-Model

Isolation Mechanism

Consensus Mechanism

Prompt Chaining

Crash Recovery

Streaming Output

Ui Cli Surface

VibeSec — UI / CLI Surface

CLI Binary

Local Web Dashboard

IDE Integration

Observability

Supported Editors

Related frameworks

Prompt 1: OWASP Top 10 Rule (`rules/cursor/general/security-owasp-top10.mdc`)