@securityreviewai/securityreview-kit 0.1.48 → 0.1.49

package/src/generators/rules/guardrails-selection/SKILL.md

@@ -1,187 +0,0 @@
----
-name: guardrails-selection
-description: Analyze the developer request, infer the security categories and likely threats involved, shortlist the most relevant project guardrails, then hydrate the exact guardrails with get_guardrail_by_id before implementation. Use for every security-relevant code task before code is written and preserve the shortlist for the final VibeReview sync.
----
-
-# Guardrails Selection
-
-Configured SRAI project name: `<SRAI_PROJECT_NAME>`
-
-Use this skill whenever code will be created or modified and the task has any security surface.
-
-This skill exists to stop the IDE from treating the full `get_guardrails` result as an unstructured blob. The workflow is:
-
-1. Understand the request deeply.
-2. Infer which security categories are in play.
-3. Predict the threats that might occur for this exact task.
-4. Shortlist only the guardrails that mitigate those threats.
-5. Fetch the exact shortlisted guardrails with `get_guardrail_by_id`.
-6. Carry that same shortlist forward into implementation and the final VibeReview markdown sync.
-
-Do not skip the analysis step. Do not rely on title-matching alone. Do not dump every guardrail into the final answer.
-
-## Inputs You Must Analyze First
-
-Before calling `get_guardrails`, extract the actual development intent from the prompt and surrounding code:
-
-- What is being built, changed, fixed, or refactored?
-- Which components are affected: API, UI, background jobs, auth flow, webhook, file upload, admin tooling, AI agent flow, infra code, data pipeline?
-- Which trust boundaries are crossed?
-- Which sensitive assets are touched: tokens, credentials, sessions, PII, tenancy boundaries, audit logs, secrets, internal APIs, signed URLs, payment state, workflow approvals?
-- Which technologies and patterns are involved in the existing code?
-- What abuse cases are plausible if this change is implemented poorly?
-
-You are not only selecting guardrails for the obvious functionality. You are selecting guardrails for the threats that might materialize around that functionality.
-
-## Category Inference Workflow
-
-Derive a category set for the task before shortlisting guardrails. Common categories include:
-
-- `authentication`
-- `authorization`
-- `session_management`
-- `input_validation`
-- `output_encoding`
-- `secrets`
-- `cryptography`
-- `logging`
-- `monitoring`
-- `file_uploads`
-- `deserialization`
-- `data_access`
-- `rate_limiting`
-- `network`
-- `client_side`
-- `business_logic`
-- `tenant_isolation`
-- `admin_workflows`
-
-Use both the user request and the codebase patterns to infer the category set. A task can involve multiple categories even if the prompt mentions only one feature.
-
-Examples:
-
-- “Add magic-link login” likely involves `authentication`, `session_management`, `cryptography`, `logging`, `rate_limiting`, and `client_side`.
-- “Add org admin API to update member roles” likely involves `authorization`, `tenant_isolation`, `logging`, `business_logic`, and `data_access`.
-- “Add CSV import” likely involves `input_validation`, `file_uploads`, `data_access`, `deserialization`, `logging`, and denial-of-service protections.
-- “Add client-side token refresh” likely involves `authentication`, `session_management`, `client_side`, `logging`, and `cryptography`.
-
-## Threat Mapping Requirement
-
-After identifying categories, infer the threat families that might occur. Use the reference file at `{{GUARDRAILS_SELECTION_SKILL_DIR}}/references/category-threat-map.md` every time you need to reason about category-to-threat mapping.
-
-Your goal is not to enumerate every possible weakness. Your goal is to pick the threats that should influence guardrail selection for this task.
-
-At minimum, consider whether the task can create:
-
-- authentication bypass
-- authorization bypass
-- privilege escalation
-- information disclosure
-- repudiation gaps
-- denial of service
-- unsafe client-side trust
-- insecure logging or audit gaps
-- injection-triggered security failures
-- serialization-triggered security failures
-- business-logic-triggered bypasses
-
-The shortlist should be threat-led, not catalog-led.
-
-## Guardrail Selection Procedure
-
-### Step 1: Resolve the project and load the catalog
-
-1. Call `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"` to obtain `project_id`.
-2. Call `get_guardrails` with `project_id`.
-
-Treat `get_guardrails` as the broad catalog. Do not treat it as the final set of instructions.
-
-Assume each returned guardrail includes the fields needed for selection, including a stable identifier for follow-up retrieval, plus:
-
-- `title`
-- `rule_type`
-- `category`
-- `instruction`
-
-If an identifier is absent, fall back to the best available stable reference exposed by the tool, but prefer the real guardrail id whenever available.
-
-### Step 2: Build a shortlist
-
-Shortlist guardrails using all of the following:
-
-- direct category match with the task
-- mitigation value against the likely threats you inferred
-- relevance to the technologies and code paths being touched
-- support for adjacent controls that prevent bypass chains
-- duplication removal
-
-Do not select a guardrail only because it sounds generally useful. Select it because it materially constrains the risky part of the current task.
-
-Examples:
-
-- If the task touches login, token issuance, password reset, session refresh, or identity proofing, prioritize authentication, session, crypto, logging, and brute-force defense guardrails.
-- If the task changes role checks, tenant scoping, admin APIs, resource ownership, or query filters, prioritize authorization, tenant isolation, data access, business-logic, and audit guardrails.
-- If the task introduces parsing, uploads, template expansion, or object hydration, prioritize input validation, file handling, deserialization, and denial-of-service guardrails.
-- If the task moves security decisions into the browser or mobile client, prioritize client-side trust, token storage, server-side revalidation, and privilege-boundary guardrails.
-
-### Step 3: Hydrate exact shortlisted guardrails
-
-For every shortlisted existing guardrail, call `get_guardrail_by_id` to retrieve the exact guardrail that will govern implementation.
-
-- Use `get_guardrail_by_id` for the shortlisted ids only.
-- If the tool supports batching, batch the shortlisted ids.
-- If the tool only supports one id at a time, call it once per shortlisted id.
-
-Implementation must be driven by the hydrated shortlist from `get_guardrail_by_id`, not by vague memory from the broad catalog listing.
-
-### Step 4: Track the active shortlist in context
-
-Maintain an explicit in-context list of the shortlisted existing guardrails that will govern the task. For each shortlisted existing guardrail, keep:
-
-- `id`
-- `title`
-- `rule_type`
-- `category`
-- `instruction`
-- `why_selected`
-
-Also track any new guardrails created during the task as `ide_generated`.
-
-This shortlist is the source of truth for the rest of the session.
-
-## Implementation Rules
-
-Once the shortlist is hydrated:
-
-- Every applicable `must` guardrail is mandatory.
-- Every applicable `must_not` guardrail is a hard prohibition.
-- If two shortlisted guardrails appear to conflict, explain the conflict and resolve it before coding.
-- If the task reveals a real gap not covered by the shortlisted existing guardrails, create an `ide_generated` guardrail and apply it immediately.
-
-When deciding whether a guardrail applies, prefer security-preserving inclusion over risky omission. If it plausibly mitigates a realistic path to abuse for the current task, keep it in scope.
-
-## VibeReview Sync Contract
-
-The final sync step must reuse the shortlist from this skill. It must not call `get_guardrails` or `get_guardrail_by_id` again.
-
-Before `sync_ai_ide_markdown` is called, ensure the main agent context clearly contains:
-
-- the exact existing guardrails shortlisted earlier
-- which of them were applied
-- whether each one was satisfied
-- any notes about partial compliance, conflicts, or rationale
-- every `ide_generated` guardrail created during the task
-
-If a guardrail was shortlisted but not fully satisfied, still include it in the handoff with `satisfied: false` and a note. Do not silently drop it.
-
-## Selection Quality Bar
-
-A good selection does all of the following:
-
-- covers the feature’s real threat surface, not just its visible functionality
-- captures adjacent controls that stop bypass chains
-- avoids irrelevant noise
-- produces a small, defensible set of guardrails that can actually guide implementation
-- leaves the final VibeReview markdown with an exact list of what the IDE selected and enforced
-
-If your shortlist feels generic, it is probably incomplete or over-broad. Re-check the prompt, the code patterns, and the threat map.

package/src/generators/rules/guardrails-selection/references/category-threat-map.md

@@ -1,232 +0,0 @@
-# Guardrail Selection Threat Map
-
-Use this file when deciding which guardrail categories apply to the current task and which threat families should influence the shortlist.
-
-The intent is not to produce a full threat model here. The intent is to make sure likely exploit paths influence which guardrails are fetched by id and enforced during implementation.
-
-## How to use this map
-
-1. Start from the feature or code change.
-2. Infer the categories involved in the implementation.
-3. Use the mappings below to identify likely threat families.
-4. Shortlist guardrails that directly or adjacently mitigate those threats.
-5. Fetch those guardrails with `get_guardrail_by_id`.
-
-## STRIDE-style mappings for guardrail selection
-
-### Spoofing
-
-Usually maps to authentication and session-related controls.
-
-Threat patterns to consider:
-
-- identity-related attacks
-- session and token attacks
-- business-logic attacks leading to authentication bypass
-- injection attacks leading to authentication bypass
-- serialization attacks leading to authentication bypass
-- cryptographic attacks leading to authentication bypass
-- lapses in logging leading to authentication bypass
-- client-side trust leading to authentication bypass
-
-Categories commonly shortlisted:
-
-- `authentication`
-- `session_management`
-- `cryptography`
-- `logging`
-- `client_side`
-- `business_logic`
-- `input_validation`
-- `deserialization`
-
-### Tampering
-
-Usually maps to authorization, integrity, and unsafe state change controls.
-
-Threat patterns to consider:
-
-- broken object level access control patterns
-- broken functional level access control patterns
-- injection-driven authorization bypass
-- serialization-driven authorization bypass
-- business-logic-driven authorization bypass
-- client-side trust leading to unauthorized state changes
-
-Categories commonly shortlisted:
-
-- `authorization`
-- `tenant_isolation`
-- `data_access`
-- `business_logic`
-- `logging`
-- `input_validation`
-- `deserialization`
-- `client_side`
-
-### Repudiation
-
-Usually appears when spoofing and tampering are possible but the system cannot prove what happened.
-
-Threat patterns to consider:
-
-- weak or missing audit trails for auth and authorization decisions
-- missing actor attribution on sensitive state changes
-- mutable or incomplete event records
-- inability to correlate session, actor, and resource changes
-
-Categories commonly shortlisted:
-
-- `logging`
-- `monitoring`
-- `authentication`
-- `authorization`
-- `admin_workflows`
-
-### Information Disclosure
-
-Usually maps to authorization, data exposure, logging, and unsafe client-side trust.
-
-Threat patterns to consider:
-
-- broken object level access control patterns
-- broken functional level access control patterns
-- injection-driven information disclosure
-- serialization-driven information disclosure
-- business-logic-driven information disclosure
-- lapses in logging leading to disclosure
-- client-side trust causing exposure of protected data
-
-Categories commonly shortlisted:
-
-- `authorization`
-- `tenant_isolation`
-- `data_access`
-- `logging`
-- `input_validation`
-- `deserialization`
-- `client_side`
-- `output_encoding`
-
-### Denial of Service
-
-Usually maps to workload protection, parsing safety, quota controls, and expensive query behavior.
-
-Threat patterns to consider:
-
-- broken access control patterns that expose heavy operations
-- injection or data-access paths that amplify resource consumption
-- serialization-driven memory or parser exhaustion
-- business-logic-driven abuse of expensive workflows
-- logging lapses that hide repeated abuse
-
-Categories commonly shortlisted:
-
-- `rate_limiting`
-- `input_validation`
-- `file_uploads`
-- `deserialization`
-- `data_access`
-- `network`
-- `monitoring`
-- `logging`
-- `business_logic`
-
-### Elevation of Privilege
-
-Usually maps to authorization, role boundaries, trust decisions, and privileged workflow controls.
-
-Threat patterns to consider:
-
-- access control bypasses from broken object or function level access
-- injection-based privilege escalation
-- client-side induced privilege escalation
-- serialization-induced privilege escalation
-- business-logic-triggered privilege escalation
-- logging lapses that conceal privilege abuse
-
-Categories commonly shortlisted:
-
-- `authorization`
-- `tenant_isolation`
-- `admin_workflows`
-- `business_logic`
-- `client_side`
-- `input_validation`
-- `deserialization`
-- `logging`
-
-## Fast examples
-
-### Add password reset flow
-
-Likely categories:
-
-- `authentication`
-- `session_management`
-- `cryptography`
-- `logging`
-- `rate_limiting`
-
-Likely threat families:
-
-- spoofing
-- repudiation
-- information disclosure
-
-### Add admin endpoint to change user role
-
-Likely categories:
-
-- `authorization`
-- `tenant_isolation`
-- `admin_workflows`
-- `logging`
-- `business_logic`
-
-Likely threat families:
-
-- tampering
-- repudiation
-- elevation of privilege
-- information disclosure
-
-### Add bulk import endpoint
-
-Likely categories:
-
-- `input_validation`
-- `file_uploads`
-- `deserialization`
-- `data_access`
-- `logging`
-- `rate_limiting`
-
-Likely threat families:
-
-- tampering
-- information disclosure
-- denial of service
-
-### Move entitlement checks to the frontend
-
-Likely categories:
-
-- `authorization`
-- `client_side`
-- `tenant_isolation`
-- `logging`
-
-Likely threat families:
-
-- tampering
-- information disclosure
-- elevation of privilege
-
-## Selection reminders
-
-- A feature can require guardrails from multiple categories.
-- Shortlist for exploit chains, not isolated weaknesses.
-- Logging often matters because poor auditability can turn spoofing, tampering, or privilege abuse into repudiation.
-- Client-side logic often needs server-side guardrails even if the visible change is in the UI.
-- If no existing guardrail covers a realistic recurring threat, create an `ide_generated` guardrail and carry it into the final VibeReview markdown sync.

package/src/generators/rules/guardrails_rule.md

@@ -1,94 +0,0 @@
-# Vibe Guardrails — Secure by Code
-
-**Enforce project-specific security guardrails during every code-generation task.**
-
-This rule complements the PWNISMS threat model ("secure by design") with concrete, project-level coding dos and don'ts ("secure by code"). Guardrails are maintained in SRAI and fetched via `security-review-mcp`.
-
----
-
-## When this rule applies
-
-This rule is **active for every code-generation or code-modification task** — including:
-
-- Implementing new features or endpoints
-- Fixing bugs that touch security-relevant code
-- Refactoring code that handles auth, input, secrets, data storage, or network
-- Generating boilerplate, scaffolding, or templates that will run in production
-
-### When to skip
-
-Skip guardrail enforcement for tasks with **no code output** (documentation, Q&A, formatting, renaming).
-
----
-
-## Required behavior
-
-### 1. Use the guardrails-selection skill at the start of every code task
-
-Before writing or modifying code, you must read and follow `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
-
-That skill is mandatory because the IDE must not leave guardrail selection to chance. The required workflow is:
-
-- **Analyze the task first** — infer what the user is actually building, what components are touched, what categories are involved, and what threats might occur.
-- **Resolve the project** — use `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"` to obtain `project_id`.
-- **Load the broad catalog** — call `get_guardrails` with `project_id`.
-- **Shortlist intentionally** — choose only the guardrails that mitigate the categories and likely threats for the current task.
-- **Hydrate the exact shortlist** — call `get_guardrail_by_id` for the shortlisted guardrail ids so implementation uses the exact selected guardrails, not a vague reading of the full catalog.
-- **Preserve the shortlist** — keep the selected existing guardrails in context so the final VibeReview markdown can include the same guardrails later without re-querying.
-
-The broad `get_guardrails` result is only the candidate catalog. The active implementation guardrails must come from the shortlisted `get_guardrail_by_id` result.
-
-Each guardrail used for implementation should preserve these fields:
-
-| Field | Description |
-|---|---|
-| `id` | Stable guardrail identifier used with `get_guardrail_by_id` |
-| `title` | Short name of the guardrail |
-| `rule_type` | `must` (mandatory) or `must_not` (prohibition) |
-| `category` | Grouping label (e.g. `authentication`, `input_validation`, `secrets`) or `null` |
-| `instruction` | The actionable coding directive |
-
-If `get_guardrails` returns additional metadata such as `source_ref`, use it as supporting context during selection.
-
-### 2. Apply guardrails during code generation
-
-- **`must` rules (DOs):** Treat as mandatory implementation requirements. Every line of generated code must satisfy all applicable `must` guardrails.
-- **`must_not` rules (DON'Ts):** Treat as hard prohibitions. Generated code must never violate a `must_not` guardrail.
-- If a guardrail conflicts with the user's explicit instruction, **flag the conflict** to the user and ask for confirmation before proceeding.
-- If no guardrails are returned (empty list), proceed normally using baseline PWNISMS controls.
-
-### 3. Cross-reference with PWNISMS
-
-Guardrails and PWNISMS are complementary:
-
-- Guardrails provide **project-specific, concrete rules** derived from prior threat reviews, compliance requirements, and team decisions.
-- PWNISMS provides **universal threat-category coverage** to catch gaps that guardrails may not yet cover.
-- When PWNISMS analysis reveals a gap not covered by any existing guardrail, **create a new guardrail on the fly** and apply it immediately (marked `source: "ide_generated"` in the VibeReview markdown).
-
-### 4. Report guardrail compliance
-
-After code generation, include a brief guardrails compliance summary:
-
-- List which guardrails were applied (by title), distinguishing existing vs IDE-generated.
-- Flag any guardrails that could not be fully satisfied and explain why.
-- Do not drop shortlisted existing guardrails from session context. The final VibeReview markdown must include the same shortlist, including any unsatisfied items with notes.
-
----
-
-## Guardrail lifecycle — updates and new guardrails
-
-Guardrails are living artifacts. The IDE agent can create, apply, and update them:
-
-- **New guardrail**: When threat modeling or code review reveals a recurring security pattern not yet captured, the IDE agent creates and applies a new guardrail on the fly. These are reported to SRAI in the final VibeReview markdown with `source: "ide_generated"`.
-- **Edit suggestion**: When an existing guardrail is too broad, too narrow, or outdated, suggest an update to the user.
-- All guardrails — existing and IDE-generated — must be preserved in the VibeReview markdown under a single `Guardrails Applied` section that the server can normalize into `guardrails_applied`.
-
----
-
-## Tool Reference
-
-| Tool | Purpose |
-|---|---|
-| `get_guardrails` | Fetch the broad project guardrails catalog (requires `project_id`) |
-| `get_guardrail_by_id` | Fetch the exact shortlisted guardrails that will govern implementation |
-| `find_project_by_name` | Resolve project by name to get `project_id` |

package/src/generators/rules/hooks.json

@@ -1,11 +0,0 @@
-{
-  "version": 1,
-  "hooks": {
-    "sessionStart": [
-      {
-        "command": "printf '%s\\n' '{\"additional_context\":\"## MANDATORY SECURITY GATE (Session Policy)\\n\\nFor ANY user request that has security impact (auth, crypto, input handling, secrets, network, data storage, dependencies, new APIs/endpoints, or any code handling untrusted data):\\n\\n**Plan order:**\\n1. **Fetch Vibe Guardrails (first)** - Use .cursor/skills/guardrails-selection/SKILL.md. Analyze the task, call get_guardrails from security-review-mcp to load the broad catalog, shortlist the relevant guardrails, then call get_guardrail_by_id for the shortlist. These exact shortlisted guardrails are the hard constraints on generated code.\\n2. **PWNISMS threat modeling (second)** - Run threat modeling as a guide before writing code. Use .cursor/skills/threat-modelling/SKILL.md. Cross-reference guardrails with PWNISMS findings to identify gaps. Document findings to inform secure implementation.\\n3. **Implement secure code (third)** - Use the threat model findings AND shortlisted guardrails as guides to create secure code. Every must guardrail must be satisfied; no must_not guardrail may be violated.\\n4. **VibeReview sync (last)** - Read .cursor/skills/vibereview-sync/SKILL.md. The main agent must write a structured `.md` artifact under `vibereview/`, must not read sibling markdown files there just to infer format, must validate that all required metadata and sections are present, and must call `sync_ai_ide_markdown` directly after implementation is done. Include the exact shortlisted guardrails from earlier plus any IDE-generated guardrails in the markdown; do not query guardrails again during sync.\\n\\nNo blocking. No deferral. Guardrails enforce secure code; threat modeling guides the design; the main agent owns the final markdown sync to SRAI. Both sync and guardrail compliance are mandatory and should be part of your to-do.\"}'",
-        "timeout": 5
-      }
-    ]
-  }
-}