@securityreviewai/securityreview-kit 0.1.18 → 0.1.20

package/package.json

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

package/src/generators/rules/ctm_sync.md

@@ -23,7 +23,10 @@ When invoked:
      - `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.
    - Store the returned `workflow_id` for the upload step.
-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.
+4. **Identify guardrails for the payload** — Do **not** call `get_guardrails` here. Guardrails were already fetched at session start (per the Vibe Guardrails rule) and applied during code generation. From the parent agent context, identify:
+   - Which **existing** guardrails (originally fetched from `get_guardrails`) were applied to the code in this session.
+   - Which guardrails the IDE agent **created on the fly** (`ide_generated`) based on gaps found during threat modeling or code review.
+   Include all of these in the `guardrails_applied` payload field. Do not re-fetch or re-call `get_guardrails`.
 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.
@@ -48,14 +51,20 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
   "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 git config user.name unless explicitly specified by user>",
-  "developer_email": "<string — from git config user.email unless explicitly specified by user>",
+  "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>"
+      "mitigation_applied": "<string — what was done to address the threat>",
+      "code_snippet": {
+        "file_path": "<string — relative path to the actual source file where mitigation is implemented>",
+        "language": "<string — programming language>",
+        "snippet": "<string — the exact source code lines implementing the mitigation, max 30 lines, must be grounded in the actual codebase not invented>",
+        "explanation": "<string — how this specific code addresses the threat>"
+      }
     }
   ],
   "best_practises_achieved": [
@@ -91,9 +100,9 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
 | `chat_session_id` | Yes | From step 2 |
 | `title` | Yes | 5-15 words, descriptive |
 | `summary` | Yes | 2-5 sentences |
-| `developer_name` | Yes | From `git config user.name` |
-| `developer_email` | Yes | From `git config user.email` |
-| `threats_mitigated` | Yes | Array, may be empty `[]` if no threats were identified |
+| `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. Each entry must include a `code_snippet` grounded in actual source code |
 | `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 |
@@ -101,9 +110,12 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
 ### 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`.
+- Every `threats_mitigated` entry must include a `code_snippet`. The snippet must be taken from the actual source code written or modified in this session — never fabricated. If no code was written for a threat (e.g. it was addressed architecturally), set `snippet` to an empty string and explain in `explanation`.
+- `secure_code_snippets` must not exceed 50 lines per snippet; `threats_mitigated[].code_snippet.snippet` must not exceed 30 lines; truncate with a comment if needed.
+- Do not call `get_guardrails` during CTM sync. Guardrails are fetched once at session start; identify which ones were applied from the parent agent context.
+- `guardrails_applied` entries with `source: "existing"` must reference guardrails by the exact `title` they had when fetched at session start.
 - `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.