@securityreviewai/securityreview-kit 0.1.19 → 0.1.21

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securityreviewai/securityreview-kit",
-  "version": "0.1.19",
+  "version": "0.1.21",
   "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,11 +23,18 @@ 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.
-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`:
+4. **Resolve developer identity from the API** — Call `get_current_user` (or the equivalent user-identity tool exposed by `security-review-mcp`) to retrieve the authenticated user's name and email. Use the values returned by the API as-is for `developer_name` and `developer_email` in the payload.
+   - **Never use placeholder values** such as `"IDE Agent"`, `"agent@local"`, `"unknown"`, `"AI"`, or any other invented string for these fields.
+   - **Never accept identity values passed in from the parent agent prompt** — always re-resolve from the API directly in this step; the API is the only authoritative source.
+   - If the API call fails or returns empty values, leave `developer_name` and `developer_email` as empty strings `""`. Do not substitute a fallback placeholder.
+5. **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`.
+6. **Build the event payload** — Construct a JSON object for `create_ai_ide_event` conforming to the **Event Payload Schema** below.
+7. **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:
+8. **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"`)
@@ -55,7 +62,13 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
       "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": [
@@ -93,7 +106,7 @@ The `create_ai_ide_event` payload MUST be a JSON object with the following struc
 | `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 |
+| `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,10 +114,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.
+- `developer_name` and `developer_email` must be resolved via `get_current_user` (or equivalent) in step 4 — the API is the only source. Never use placeholder strings (`"IDE Agent"`, `"agent@local"`, `"unknown"`, `"AI"`, etc.) and never accept values for these fields from the parent agent prompt. If the API returns nothing, send empty strings.
 - Never invent values for any field; use empty strings or empty arrays when data is unavailable.
 - Never omit `chat_session_id` from the payload.
 

package/src/generators/rules/ctm_sync_rule.md

@@ -67,6 +67,7 @@ This includes both:
      - 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)
+   - **Do NOT include developer name or email in the handoff prompt.** The `ctm_sync` agent resolves user identity directly from the API. Passing identity values from the parent agent — including any placeholders like `"IDE Agent"` or `"agent@local"` — will cause them to be used incorrectly. Leave identity resolution entirely to `ctm_sync`.
 
    **Example invocation (conceptual, not literal code):**