@securityreviewai/securityreview-kit 0.1.17 → 0.1.19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securityreviewai/securityreview-kit",
-  "version": "0.1.17",
+  "version": "0.1.19",
   "description": "Bootstrap security-review-mcp for AI IDEs and CLI tools",
   "author": "Debarshi Das <debarshi.das@we45.com>",
   "license": "UNLICENSED",

package/src/generators/rules/content.js

@@ -64,6 +64,13 @@ export function getThreatModellingSkillContent(options = {}) {
     return readTemplate('skill.md', options);
 }
 
+/**
+ * Returns the vibe guardrails always-applied rule markdown.
+ */
+export function getGuardrailsRuleContent(options = {}) {
+    return readTemplate('guardrails_rule.md', options);
+}
+
 /**
  * Returns the hooks.json content for Cursor session hooks.
  */

package/src/generators/rules/content.md

@@ -6,7 +6,7 @@
 
 ### When NOT to apply
 
-Skip PWNISMS and the MCP flow entirely for tasks that have **no security surface**:
+Skip PWNISMS, guardrails, and the MCP flow entirely for tasks that have **no security surface**:
 
 - Documentation-only changes (README, comments, changelogs)
 - Code formatting, linting, or style fixes
@@ -18,6 +18,18 @@ Skip PWNISMS and the MCP flow entirely for tasks that have **no security surface
 If in doubt, do a quick mental scan: *does this change touch auth, input handling, secrets, network, data storage, or dependencies?* If **no**, skip. If **yes** or **maybe**, apply.
 
 **MANDATORY POST THREAT MODELLING** ALWAYS invoke `ctm_sync` immediately after threat modelling is generated or updated. This is required on every threat-model run.
+
+---
+
+## Two pillars of security enforcement
+
+This workflow enforces security through two complementary pillars:
+
+1. **Secure by Design (PWNISMS)** — Universal threat-category analysis applied to every security-relevant task. Identifies risks and drives architectural/design-level mitigations.
+2. **Secure by Code (Vibe Guardrails)** — Project-specific coding dos and don'ts fetched from SRAI via `get_guardrails`. Enforces concrete implementation rules derived from prior threat reviews, compliance requirements, and team decisions.
+
+Both pillars are **mandatory** for any code-generation task with a security surface. PWNISMS catches broad threats; guardrails enforce project-specific coding standards.
+
 ---
 
 ## MCP Enhancement — `security-review-mcp`
@@ -66,7 +78,13 @@ Rather than fetching the entire profile at once, walk through each reasoning blo
    - For each requirement relevant to the task, call `get_profile_compliance_requirement` for full details.
    - Map these to security objectives and ensure your implementation meets them.
 
-10. **Check for existing reviews** — Call `list_reviews`. If a completed review exists, pull context:
+10. **Fetch Vibe Guardrails** — Call `get_guardrails` with `project_id`.
+    - Load all project-specific coding guardrails (dos and don'ts).
+    - Separate into `must` (mandatory requirements) and `must_not` (hard prohibitions).
+    - Keep these in context for the entire code-generation task.
+    - Cross-reference with PWNISMS findings: if a threat has no corresponding guardrail, flag it as a candidate for a new guardrail.
+
+11. **Check for existing reviews** — Call `list_reviews`. If a completed review exists, pull context:
     - `get_threat_scenarios` — Cross-reference with your PWNISMS findings
     - `get_countermeasures` — Apply recommended mitigations
     - `get_components` — Understand the system architecture
@@ -74,11 +92,11 @@ Rather than fetching the entire profile at once, walk through each reasoning blo
     - `get_security_objectives` — Understand compliance requirements
     - `get_findings` — Review aggregated security insights
 
-11. **No review exists?** Create one:
+12. **No review exists?** Create one:
     - Upload context via `create_document_from_content`
     - `create_review` → `start_workflow` → poll `get_workflow_status`
 
-12. **After threat modeling (ALWAYS / POST threat modelling)** — Invoke `ctm_sync` agent and upload the required CTM data.
+13. **After threat modeling (ALWAYS / POST threat modelling)** — Invoke `ctm_sync` agent and upload the required CTM data (including guardrail compliance and proposed guardrails).
 
 ### CTM sync — chat session and workflows (all IDEs)
 
@@ -94,6 +112,7 @@ When running `ctm_sync` (dedicated agent/command where available, or the same st
 |---|---|
 | **Projects** | `list_projects`, `find_project_by_name`, `create_project`, `get_project` |
 | **Profile Exploration** | `get_project_profile_description`, `list_profile_technology_categories`, `get_project_profile_technology_category`, `list_project_profile_architecture_notes`, `list_project_profile_user_groups`, `list_project_profile_language_stacks`, `list_project_profile_security_controls`, `get_project_profile_security_control`, `list_profile_compliance_requirements`, `get_profile_compliance_requirement` |
+| **Guardrails** | `get_guardrails` |
 | **Documents** | `list_documents`, `create_document_from_content`, `upload_document`, `link_external_document` |
 | **Reviews** | `create_review`, `list_reviews`, `get_review`, `get_review_overview` |
 | **Workflow** | `start_workflow`, `get_workflow_status`, `start_next_workflow_job`, `start_workflow_job`, `retry_workflow_job` |

package/src/generators/rules/ctm_sync.md

@@ -1,6 +1,6 @@
 ---
 name: ctm_sync
-description: Command/workflow triggered whenever a threat model is generated or updated. Builds and uploads CTM sync details through security-review-mcp.
+description: Command/workflow triggered whenever a threat model is generated or updated, or guardrails are proposed/modified. Builds and uploads CTM sync details and guardrail updates through security-review-mcp.
 ---
 
 # CTM Sync Workflow
@@ -21,21 +21,13 @@ When invoked:
    - **If none exists:** call `create_ai_ide_workflow` with:
      - `project_id`
      - `name`: a short, meaningful heading derived from the **high-level feature or topic** being worked on in this session (e.g. `"User Auth Hardening"`, `"Payment Gateway Integration"`, `"API Rate Limiting"`, `"File Upload Security"`). Use 2–5 words, title-case. Do **not** use sequential labels like `session1/session2`. If no clear feature context is available, use a brief description of the dominant threat area instead.
-     - `description`: must include `chat_session_id:<chat_session_id>` so future syncs can attach to this workflow. Add a brief human-readable note if helpful.do not add the word ctm anywhere
+     - `description`: must include `chat_session_id:<chat_session_id>` so future syncs can attach to this workflow. Add a brief human-readable note if helpful. Do not add the word ctm anywhere.
    - Store the returned `workflow_id` for the upload step.
-4. Build a JSON payload for `create_ai_ide_event` with these exact keys:
-   - `workflow_id`
-   - `chat_session_id` (same value used for routing above)
-   - `title`
-   - `summary`
-   - `developer_name` = fetch from git config unless explicitly specified by user
-   - `developer_email` = fetch from git config unless explicitly specified by user
-   - `threats_mitigated`
-   - `best_practises_achieved`
-   - `secure_code_snippets`
-5. Upload the payload using `security-review-mcp`:
-   - Use the tool `create_ai_ide_event`
-6. **Push a project profile update** — After the event is created, derive project profile data from the current threat model context and call `update_vibe_project_profile` with `project_id` and the following fields:
+4. **Fetch current guardrails** — Call `get_guardrails` with `project_id` to retrieve the project's current vibe guardrails. These inform the `guardrails_applied` field in the event payload.
+5. **Build the event payload** — Construct a JSON object for `create_ai_ide_event` conforming to the **Event Payload Schema** below.
+6. **Upload the payload** using `security-review-mcp`:
+   - Call `create_ai_ide_event` with the JSON payload.
+7. **Push a project profile update** — After the event is created, derive project profile data from the current threat model context and call `update_vibe_project_profile` with `project_id` and the following fields:
    - `description`: a concise summary of the system/project derived from the threat model context (what it does, what data it handles, its overall purpose)
    - `architecture_notes`: a list of architecture observations extracted from the threat model — deployment topology, trust boundaries, data flows, integration points
    - `tech_categories`: a list of technology category labels identified during threat modeling (e.g. `"backend"`, `"frontend"`, `"database"`, `"cloud"`, `"mobile"`)
@@ -44,10 +36,87 @@ When invoked:
    - `language_stacks`: a list of programming languages, runtimes, and major frameworks identified in the codebase or threat model context (e.g. `"Python/FastAPI"`, `"TypeScript/React"`, `"Java/Spring"`)
    - Omit any field for which no data is available in context — do **not** invent values. Pass an empty list `[]` only if the field is reasonably expected but simply unpopulated.
 
+---
+
+## Event Payload Schema
+
+The `create_ai_ide_event` payload MUST be a JSON object with the following structure. Use this exact schema — do not add, rename, or omit required keys.
+
+```json
+{
+  "workflow_id": "<string — resolved or newly created AI IDE workflow id>",
+  "chat_session_id": "<string — stable session identifier, same for all events in this chat>",
+  "title": "<string — concise title describing what was threat-modeled or implemented, 5-15 words>",
+  "summary": "<string — 2-5 sentence summary of the threat model findings, key risks identified, mitigations applied, and any guardrails enforced>",
+  "developer_name": "<string — from API/user context provided by MCP or host runtime>",
+  "developer_email": "<string — from API/user context provided by MCP or host runtime>",
+  "threats_mitigated": [
+    {
+      "threat_name": "<string — short threat title>",
+      "pwnisms_category": "<string — one of: Product, Workload, Network, IAM, Secrets, Monitoring, Supply Chain>",
+      "severity": "<string — Critical | High | Medium | Low>",
+      "mitigation_applied": "<string — what was done to address the threat>"
+    }
+  ],
+  "best_practises_achieved": [
+    "<string — each entry is a concise statement of a security best practice that was followed during implementation>"
+  ],
+  "secure_code_snippets": [
+    {
+      "file_path": "<string — relative path to the file>",
+      "language": "<string — programming language>",
+      "snippet": "<string — the security-relevant code snippet, max 50 lines>",
+      "explanation": "<string — why this snippet is security-relevant and what it protects against>"
+    }
+  ],
+  "guardrails_applied": [
+    {
+      "title": "<string — guardrail title>",
+      "rule_type": "<string — must | must_not>",
+      "category": "<string | null — grouping label>",
+      "instruction": "<string — the actionable coding directive>",
+      "source": "<string — 'existing' if fetched from get_guardrails, 'ide_generated' if newly created by the IDE agent>",
+      "satisfied": "<boolean — true if the guardrail was fully satisfied, false if partially or not satisfied>",
+      "notes": "<string — optional: how it was applied, why it could not be fully satisfied, or rationale for a new guardrail>"
+    }
+  ]
+}
+```
+
+### Field rules
+
+| Field | Required | Notes |
+|---|---|---|
+| `workflow_id` | Yes | From step 3 |
+| `chat_session_id` | Yes | From step 2 |
+| `title` | Yes | 5-15 words, descriptive |
+| `summary` | Yes | 2-5 sentences |
+| `developer_name` | Yes | From API/user context (never read from git config) |
+| `developer_email` | Yes | From API/user context (never read from git config) |
+| `threats_mitigated` | Yes | Array, may be empty `[]` if no threats were identified |
+| `best_practises_achieved` | Yes | Array of strings, may be empty `[]` |
+| `secure_code_snippets` | Yes | Array, may be empty `[]` |
+| `guardrails_applied` | Yes | Array of all guardrails enforced during this session — both existing ones from `get_guardrails` and new ones the IDE agent created. Use `source` to distinguish origin. Empty `[]` if none |
+
+### Constraints
+
+- Every `threats_mitigated` entry must map to one of the 7 PWNISMS categories.
+- `secure_code_snippets` must not exceed 50 lines per snippet; truncate with a comment if needed.
+- `guardrails_applied` entries with `source: "existing"` should reference guardrails fetched in step 4 by their exact `title`.
+- `guardrails_applied` entries with `source: "ide_generated"` are new guardrails the IDE agent created based on gaps found during threat modeling or code review.
+- `developer_name` and `developer_email` must come from API/runtime user context only; do not derive them from git config.
+- Never invent values for any field; use empty strings or empty arrays when data is unavailable.
+- Never omit `chat_session_id` from the payload.
+
+---
+
 ## Output Contract
 
 - Never skip upload when a threat model exists.
 - Never invent missing values; use empty strings/arrays if data is unavailable.
 - Never omit `chat_session_id` from the payload.
 - Never skip the `update_vibe_project_profile` call when profile-relevant data (architecture, tech, users, compliance, languages, or description) can be derived from context.
-- Return a compact confirmation after upload (including whether an existing workflow was reused or a new named workflow was created, and confirmation that the project profile was updated).
+- Return a compact confirmation after upload including:
+  - Whether an existing workflow was reused or a new named workflow was created
+  - Confirmation that the project profile was updated
+  - Count of guardrails applied (existing vs IDE-generated)

package/src/generators/rules/ctm_sync_rule.md

@@ -4,19 +4,20 @@ alwaysApply: true
 ---
 # Continuous Threat Modeling Sync (`ctm_sync`)
 
-**Always synchronize threat models after they are (re)generated.**
+**Always synchronize threat models and guardrail compliance after they are (re)generated.**
 
 Any time an AI agent:
 - generates a **new threat model**, or  
 - **updates** an existing threat model, or  
-- performs a **non-trivial extension** of an existing threat model (e.g., adds new threat scenarios, countermeasures, data flows, or components),
+- performs a **non-trivial extension** of an existing threat model (e.g., adds new threat scenarios, countermeasures, data flows, or components), or
+- **applies vibe guardrails** during a code-generation task (existing or IDE-generated) and has guardrail compliance data to report,
 
-it **must immediately call** the `ctm_sync` agent to synchronize the latest threat modeling state.
+it **must immediately call** the `ctm_sync` agent to synchronize the latest threat modeling state and guardrail data.
 
 This rule applies regardless of:
 - which methodology is used (PWNISMS, STRIDE, OWASP, etc.),
 - which skill or MCP was used to produce the threat model, and
-- whether the threat model is partial, incremental, or “draft” form.
+- whether the threat model is partial, incremental, or "draft" form.
 
 If in doubt — **assume this rule applies**.
 
@@ -33,9 +34,13 @@ This rule is **triggered** whenever the assistant:
   - Attack trees or abuse cases
   - Structured PWNISMS analysis
 - **Extends or refines** an earlier threat model, e.g.:
-  - “Add more threats for the Payments service”
-  - “Update the data flow for the auth system”
-  - “Refine the mitigations for threat X”
+  - "Add more threats for the Payments service"
+  - "Update the data flow for the auth system"
+  - "Refine the mitigations for threat X"
+- **Enforces guardrails** during code generation and has compliance data:
+  - Guardrails were fetched via `get_guardrails` and applied to generated code
+  - New guardrails were created by the IDE agent based on gaps found
+  - Existing guardrails were flagged as unsatisfiable or conflicting
 
 This includes both:
 - Threat modeling done **directly in this conversation**, and  
@@ -45,7 +50,7 @@ This includes both:
 
 ## Required behavior
 
-**After completing any threat modeling step that produces or modifies threat content, the assistant must:**
+**After completing any threat modeling step that produces or modifies threat content, or any code-generation step where guardrails were enforced, the assistant must:**
 
 1. **Ensure threat modeling output is finalized for this step**
 
@@ -55,26 +60,27 @@ This includes both:
 2. **Immediately call the `ctm_sync` agent**
 
    - Use the `Task` tool (or equivalent agent launcher) with `subagent_type="ctm_sync"`.
-   - **Session routing:** In the prompt (or structured handoff), always include the **current chat’s stable `chat_session_id`** — the same id for every `ctm_sync` in this conversation, and a new id for a different chat. Use the IDE/session id when exposed; otherwise generate one UUID at the start of the chat and reuse it. This ensures SRAI attaches events to the correct per-session workflow (`session1`, `session2`, … for new sessions).
+   - **Session routing:** In the prompt (or structured handoff), always include the **current chat's stable `chat_session_id`** — the same id for every `ctm_sync` in this conversation, and a new id for a different chat. Use the IDE/session id when exposed; otherwise generate one UUID at the start of the chat and reuse it. This ensures SRAI attaches events to the correct per-session workflow.
    - Provide a clear, concise description in the `description`/`prompt` fields explaining:
      - What system or component the threat model covers
      - Whether this is a new threat model or an update
-     - Where the latest threat content can be found (e.g., “from this conversation” or “from the last threat modeling step”)
+     - Where the latest threat content can be found (e.g., "from this conversation" or "from the last threat modeling step")
      - The `chat_session_id` value to use for this sync
+     - Whether guardrails were applied (existing and/or IDE-generated)
 
    **Example invocation (conceptual, not literal code):**
 
    Use Task tool with:
    - subagent_type: "ctm_sync"
    - description: "Sync latest threat model for <system/component>"
-   - prompt: Brief summary of what was threat-modeled, what artifacts were produced (threat scenarios, countermeasures, components, data dictionary, etc.), and that the agent should upload/update CTM data accordingly.
+   - prompt: Brief summary of what was threat-modeled, what artifacts were produced (threat scenarios, countermeasures, components, data dictionary, guardrails applied/proposed, etc.), and that the agent should upload/update CTM data accordingly.
    - readonly: false (it must be allowed to write/update CTM data)
 
 3. Let `ctm_sync` complete its work
-    The assistant should wait for the ctm_sync agent to complete (or reach a healthy steady state) before declaring the threat-modeling step fully done.
-    If ctm_sync returns errors that can be reasonably fixed (e.g., missing project name), the assistant should fix the issue and retry once, if possible.
+   The assistant should wait for the ctm_sync agent to complete (or reach a healthy steady state) before declaring the threat-modeling step fully done.
+   If ctm_sync returns errors that can be reasonably fixed (e.g., missing project name), the assistant should fix the issue and retry once, if possible.
 
 Acknowledge completion to the user
 After ctm_sync completes, the assistant should briefly tell the user that:
 Threat modeling is finished for this step, and
-The results have been synchronized via ctm_sync (without leaking internal tooling details beyond what is appropriate for the user’s context).
+The results have been synchronized via ctm_sync (without leaking internal tooling details beyond what is appropriate for the user's context).

package/src/generators/rules/cursor.js

@@ -8,6 +8,7 @@ import {
     getCtmSyncTriggerRuleContent,
     getCreateIdeWorkflowCommandContent,
     getThreatModellingSkillContent,
+    getGuardrailsRuleContent,
     getHooksContent,
 } from './content.js';
 
@@ -38,6 +39,7 @@ function writeCursorCommand(filePath, content) {
 export function generate(cwd, options = {}) {
     const baseRulePath = join(cwd, '.cursor', 'rules', 'srai-security-review.mdc');
     const ctmSyncTriggerRulePath = join(cwd, '.cursor', 'rules', 'ctm_sync_rule.mdc');
+    const guardrailsRulePath = join(cwd, '.cursor', 'rules', 'guardrails_rule.mdc');
     const ctmSyncWorkflowPath = join(cwd, '.cursor', 'commands', 'ctm_sync.md');
     const ctmSyncAgentPath = join(cwd, '.cursor', 'agents', 'ctm_sync.md');
     const createIdeWorkflowCommandPath = join(cwd, '.cursor', 'commands', 'create-ide-workflow.md');
@@ -47,6 +49,7 @@ export function generate(cwd, options = {}) {
 
     const baseRuleContent = getRuleContent(options);
     const ctmSyncTriggerRuleContent = getCtmSyncTriggerRuleContent(options);
+    const guardrailsRuleContent = getGuardrailsRuleContent(options);
     const ctmSyncWorkflowContent = getCtmSyncWorkflowContent(options);
     const createIdeWorkflowCommandContent = getCreateIdeWorkflowCommandContent(options);
     const profileCommandContent = getProfileCommandContent(options);
@@ -59,6 +62,11 @@ export function generate(cwd, options = {}) {
     );
 
     const ctmSyncTriggerRule = writeCursorCommand(ctmSyncTriggerRulePath, ctmSyncTriggerRuleContent);
+    const guardrailsRule = writeCursorRule(
+        guardrailsRulePath,
+        'Vibe Guardrails — fetch and enforce project-specific secure coding guardrails from SRAI',
+        guardrailsRuleContent,
+    );
     const ctmSyncWorkflow = writeCursorCommand(ctmSyncWorkflowPath, ctmSyncWorkflowContent);
     const ctmSyncAgent = writeCursorCommand(ctmSyncAgentPath, ctmSyncWorkflowContent);
     const createIdeWorkflowCommand = writeCursorCommand(createIdeWorkflowCommandPath, createIdeWorkflowCommandContent);
@@ -74,6 +82,7 @@ export function generate(cwd, options = {}) {
     return [
         { ...baseRule, kind: 'rule' },
         { ...ctmSyncTriggerRule, kind: 'rule' },
+        { ...guardrailsRule, kind: 'rule' },
         { ...ctmSyncWorkflow, kind: 'command' },
         { ...ctmSyncAgent, kind: 'agent' },
         { ...createIdeWorkflowCommand, kind: 'command' },

package/src/generators/rules/guardrails_rule.md

@@ -0,0 +1,86 @@
+---
+description: Vibe Guardrails — fetch and enforce project-specific secure coding guardrails from SRAI
+alwaysApply: true
+---
+
+# 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 the `security-review-mcp` MCP tool `get_guardrails`.
+
+---
+
+## 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. Fetch guardrails at the start of every code task
+
+Before writing or modifying code, call `get_guardrails` from `security-review-mcp`:
+
+- **Resolve the project** — Use `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"` to obtain `project_id`.
+- **Fetch guardrails** — Call `get_guardrails` with `project_id`.
+- Each guardrail returned has:
+
+| Field | Description |
+|---|---|
+| `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 |
+| `source_ref` | List of reference links (threat scenarios, compliance docs, etc.) |
+
+### 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 CTM sync).
+
+### 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.
+
+---
+
+## 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 via CTM sync 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 — flow into the single `guardrails_applied` array in the CTM sync payload.
+
+---
+
+## Tool Reference
+
+| Tool | Purpose |
+|---|---|
+| `get_guardrails` | Fetch project guardrails (requires `project_id`) |
+| `find_project_by_name` | Resolve project by name to get `project_id` |

package/src/generators/rules/hooks.json

@@ -3,7 +3,7 @@
   "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. **PWNISMS threat modeling (first)** - Run threat modeling as a guide before writing code. Use .cursor/skills/threat-modelling/SKILL.md. Document findings to inform secure implementation.\\n2. **Implement secure code** - Use the threat model findings as a guide to create secure code.\\n3. **ctm_sync (last)** - Push payload to SRAI only after implementation is done. Invoke ctm_sync agent (Task tool, subagent_type=ctm_sync) as the final step. See .cursor/commands/ctm_sync.md and .cursor/rules/ctm-trigger-rule.mdc.\\n\\nNo blocking. No deferral. Threat modeling guides the code; ctm_sync runs last to push to SRAI. the ctm_sync is mandatory , should be a part of your to-do.\"}'",
+        "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)** - Call get_guardrails from security-review-mcp to load project-specific coding dos and don\\u0027ts. These are hard constraints on all generated code. Separate into must (mandatory) and must_not (prohibited) rules.\\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 guardrails as guides to create secure code. Every must guardrail must be satisfied; no must_not guardrail may be violated.\\n4. **ctm_sync (last)** - Push payload to SRAI only after implementation is done. Invoke ctm_sync agent (Task tool, subagent_type=ctm_sync) as the final step. Include all guardrails (existing + IDE-generated) in the guardrails_applied payload field. See .cursor/agents/ctm_sync.md and .cursor/rules/ctm_sync_rule.mdc.\\n\\nNo blocking. No deferral. Guardrails enforce secure code; threat modeling guides the design; ctm_sync runs last to push to SRAI. Both ctm_sync and guardrail compliance are mandatory and should be part of your to-do.\"}'",
         "timeout": 5
       }
     ]

package/src/generators/rules/skill.md

@@ -1,11 +1,11 @@
 ---
 name: PWNISMS Threat Modelling
-description: Lightweight, security-first threat modelling workflow for code and architecture tasks. Use it to walk all 7 PWNISMS categories, identify plausible threats, prioritize top risks, and propose concrete mitigations before and during implementation.
+description: Security-first threat modelling workflow for code and architecture tasks. Walks all 7 PWNISMS categories, integrates with SRAI project profiles, enforces vibe guardrails (secure by code), and synchronizes findings via CTM sync. Use before, during, and after implementation.
 ---
 
-# PWNISMS — On-the-Go Threat Modelling
+# PWNISMS — Security-First Threat Modelling
 
-For EVERY security-relevant task (feature, bug fix, refactor, infra change, architecture design), run a lightweight threat model with PWNISMS.
+For EVERY security-relevant task (feature, bug fix, refactor, infra change, architecture design), run a threat model with PWNISMS.
 
 - Walk through all 7 categories explicitly.
 - If a category is not applicable, state it briefly and move on.
@@ -14,7 +14,32 @@ For EVERY security-relevant task (feature, bug fix, refactor, infra change, arch
 
 ---
 
-## Inputs to Gather First
+## Phase 0 — Enrich Context from SRAI
+
+Before deep analysis, pull project context from `security-review-mcp` (if available) to ground your threat model in the actual system profile.
+
+1. **Resolve the project** — `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"`.
+2. **Fetch project description** — `get_project_profile_description` to understand the system's purpose and data flows.
+3. **Technology categories** — `list_profile_technology_categories` → for each, `get_project_profile_technology_category` to understand specific frameworks, libraries, versions.
+4. **Architecture notes** — `list_project_profile_architecture_notes` for deployment topology, trust boundaries, data flow patterns.
+5. **User groups** — `list_project_profile_user_groups` to map roles and privilege levels.
+6. **Language stacks** — `list_project_profile_language_stacks` for language-specific vulnerability patterns.
+7. **Security controls** — `list_project_profile_security_controls` → for relevant controls, `get_project_profile_security_control` for details.
+8. **Compliance requirements** — `list_profile_compliance_requirements` → for relevant ones, `get_profile_compliance_requirement`.
+9. **Existing reviews** — `list_reviews`. If a completed review exists:
+   - `get_threat_scenarios` — prior threats to cross-reference
+   - `get_countermeasures` — existing mitigations to leverage
+   - `get_components` — system architecture context
+   - `get_data_dictionaries` — sensitive data assets
+   - `get_security_objectives` — compliance targets
+   - `get_findings` — aggregated insights
+10. **Vibe Guardrails** — `get_guardrails` with `project_id` to load project-specific coding dos and don'ts.
+
+If SRAI is not available, proceed with whatever context the user provides — files, diffs, PRs, architecture docs.
+
+---
+
+## Phase 1 — Inputs to Gather
 
 Collect these quickly before deep analysis:
 
@@ -22,29 +47,41 @@ Collect these quickly before deep analysis:
 - **Assets**: What must be protected (PII, credentials, tokens, configs, accounts, workflows)?
 - **Entry points**: How data enters/leaves (HTTP, queues, schedulers, CLI, webhooks, integrations)?
 - **Trust boundaries**: Where data crosses users/services/networks/privilege levels?
+- **Existing guardrails**: What project-specific dos and don'ts apply (from Phase 0, step 10)?
 
 If the user provided specific code, diffs, or architecture artifacts, prioritize those as primary evidence.
 
 ---
 
-## Lightweight Workflow (PWNISMS)
+## Phase 2 — Lightweight Workflow (PWNISMS)
 
 1. **Clarify scope and assumptions**
    - Define the exact unit of analysis.
    - State assumptions explicitly (auth model, deployment boundary, tenant model, etc.).
+
 2. **Map assets and flows**
    - List high-value assets and critical data paths.
    - List entry points and exits across trust boundaries.
+   - Note which assets are covered by existing guardrails and which are not.
+
 3. **Walk all 7 PWNISMS categories**
    - Identify plausible threats for each category.
    - Keep findings concrete and contextual.
+   - For each threat, check if an existing guardrail already addresses it.
+
 4. **Prioritize**
    - Select the top 3-7 risks by impact and likelihood.
+   - Factor in existing mitigations from SRAI countermeasures and guardrails.
+
 5. **Mitigate**
    - Propose concrete, implementable controls for each prioritized risk.
+   - Map mitigations to specific guardrails where applicable.
+   - If a mitigation represents a recurring pattern, propose it as a new guardrail candidate.
+
 6. **Summarize residual risk**
    - Call out remaining risk, trade-offs, and follow-up actions.
    - Call out unknowns instead of silently guessing.
+   - Note guardrail gaps — security patterns not yet captured by any guardrail.
 
 ---
 
@@ -58,6 +95,7 @@ Application and business-logic threats:
 - Authorization gaps, privilege escalation, IDOR/BOLA.
 - Business logic abuse, replay/race conditions, unsafe redirects.
 - Error handling that leaks internals.
+- **Guardrail check:** Are there `must` / `must_not` rules for input validation, authorization patterns, error handling?
 
 ### W — Workload
 
@@ -67,6 +105,7 @@ Compute and infrastructure threats:
 - Weak host/orchestrator controls and segmentation.
 - Insecure data storage/backups and DB configuration.
 - Queue/broker abuse and poison-message handling gaps.
+- **Guardrail check:** Are there rules for container security, data-at-rest encryption, workload identity?
 
 ### N — Network
 
@@ -76,6 +115,7 @@ Network and transport threats:
 - Exposed ports/endpoints and permissive ingress/egress.
 - Weak segmentation or lateral movement paths.
 - API-layer abuse controls missing (rate limits, request limits, CORS hardening).
+- **Guardrail check:** Are there rules for TLS enforcement, CORS policy, rate limiting?
 
 ### I — IAM (Identity & Access Management)
 
@@ -85,6 +125,7 @@ Identity and authorization threats:
 - Missing least-privilege RBAC/ABAC.
 - Service-to-service auth gaps.
 - Escalation paths across users, roles, or services.
+- **Guardrail check:** Are there rules for auth mechanisms, session management, privilege boundaries?
 
 ### S — Secrets
 
@@ -94,6 +135,7 @@ Credential and key management threats:
 - Weak rotation, revocation, or token lifetime policies.
 - Over-shared secrets across components.
 - Missing secret manager/KMS controls.
+- **Guardrail check:** Are there `must_not` rules against hardcoded secrets, `must` rules for secret manager usage?
 
 ### M — Monitoring (Logging & Observability)
 
@@ -103,6 +145,7 @@ Detection and auditability threats:
 - Sensitive data leakage in logs.
 - Missing alerts for abuse indicators.
 - Incomplete audit trails or weak log integrity.
+- **Guardrail check:** Are there rules for what must be logged and what must not appear in logs?
 
 ### S — Supply Chain
 
@@ -113,6 +156,37 @@ Dependency and delivery threats:
 - CI/CD pipeline leakage or unreviewed build scripts.
 - Unsigned/unprovenanced artifacts, missing SBOM.
 - Treat AI-generated code as untrusted until validated.
+- **Guardrail check:** Are there rules for dependency pinning, SBOM generation, artifact signing?
+
+---
+
+## Phase 3 — Guardrail Enforcement (Secure by Code)
+
+After completing the PWNISMS analysis and before writing code:
+
+1. **Review all fetched guardrails** from `get_guardrails`.
+2. **Classify applicability** — For each guardrail, determine if it applies to the current task.
+3. **Apply during code generation:**
+   - `must` rules → mandatory implementation requirements. Every applicable `must` guardrail must be satisfied.
+   - `must_not` rules → hard prohibitions. Code must never violate an applicable `must_not` guardrail.
+4. **Flag conflicts** — If a guardrail conflicts with the user's explicit instruction, flag it and ask for confirmation.
+5. **Create new guardrails on the fly** — When PWNISMS analysis or code review reveals a recurring security pattern not captured by existing guardrails, create and apply it as a new guardrail (marked `source: "ide_generated"` in CTM sync). Include `title`, `rule_type` (must/must_not), `category`, `instruction`, and rationale in the notes.
+
+---
+
+## Phase 4 — Security-First Code Generation Rules
+
+When implementing code, enforce these baseline controls alongside project guardrails:
+
+1. Validate and constrain all untrusted input.
+2. Parameterize all queries and command-like invocations.
+3. Enforce least privilege for users, services, and workloads.
+4. Never hardcode secrets; use managed secret stores.
+5. Encrypt sensitive data in transit and at rest.
+6. Log security-relevant actions without leaking secrets/PII.
+7. Pin and verify dependencies and build artifacts.
+8. Return safe user errors; keep sensitive diagnostics internal.
+9. Add abuse protections (rate limits, lockouts, throttling) on exposed interfaces.
 
 ---
 
@@ -129,22 +203,38 @@ When discussing designs before code exists:
   - Centralized authn/authz and role checks.
   - Secrets manager / KMS for credentials and keys.
   - mTLS or signed requests for service-to-service calls.
+- Review existing guardrails for design-level constraints.
 
 ---
 
-## Security-First Code Generation Rules
+## Phase 5 — CTM Sync (Post Threat Modelling)
 
-When implementing code, enforce these baseline controls:
+**MANDATORY:** After every threat modeling step that produces or modifies threat content, synchronize via `ctm_sync`.
 
-1. Validate and constrain all untrusted input.
-2. Parameterize all queries and command-like invocations.
-3. Enforce least privilege for users, services, and workloads.
-4. Never hardcode secrets; use managed secret stores.
-5. Encrypt sensitive data in transit and at rest.
-6. Log security-relevant actions without leaking secrets/PII.
-7. Pin and verify dependencies and build artifacts.
-8. Return safe user errors; keep sensitive diagnostics internal.
-9. Add abuse protections (rate limits, lockouts, throttling) on exposed interfaces.
+### What triggers CTM sync
+
+- New threat model generated (any form: scenarios, data flows, attack trees, PWNISMS analysis)
+- Existing threat model updated or extended (new threats, refined mitigations, additional components)
+- Guardrails applied during a code-generation task (existing or IDE-generated)
+
+### What CTM sync uploads
+
+The `ctm_sync` agent builds and pushes an event payload containing:
+
+- **Threat model findings**: threats mitigated, PWNISMS categories, severities, mitigations applied
+- **Best practices achieved**: security patterns followed during implementation
+- **Secure code snippets**: security-relevant code with explanations
+- **Guardrails applied**: all guardrails enforced during this session — both existing ones fetched from `get_guardrails` (`source: "existing"`) and new ones the IDE agent created on the fly (`source: "ide_generated"`), each with satisfaction status
+- **Project profile updates**: architecture notes, tech categories, user groups, compliance requirements, language stacks
+
+### How to invoke
+
+Use the `ctm_sync` agent (Task tool with `subagent_type="ctm_sync"`) with:
+- A clear description of what was threat-modeled
+- The `chat_session_id` for workflow routing
+- Whether this is a new threat model or an update
+
+See `.cursor/agents/ctm_sync.md` (or `.cursor/commands/ctm_sync.md`) for the full workflow and payload schema.
 
 ---
 
@@ -157,5 +247,8 @@ Before finalizing output, confirm:
 - [ ] Top risks were prioritized by impact and likelihood.
 - [ ] Mitigations are concrete and actionable.
 - [ ] Residual risk and follow-up actions are stated.
+- [ ] Vibe guardrails were fetched and enforced (all applicable `must`/`must_not` rules satisfied).
+- [ ] Guardrail compliance summary is included in the response (existing + IDE-generated).
+- [ ] CTM sync was invoked to upload threat model and guardrail data.
 
 If ANY box cannot be checked, you MUST flag the gap to the user with a specific remediation recommendation before finalizing the code.