@securityreviewai/securityreview-kit 0.1.31 → 0.1.32

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securityreviewai/securityreview-kit",
-  "version": "0.1.31",
+  "version": "0.1.32",
   "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.md

@@ -4,7 +4,7 @@
 
 > **Skill Reference:** Read and apply `.cursor/skills/threat-modelling/SKILL.md` for the full PWNISMS framework — the 7 threat categories, code generation rules, and post-generation checklist. You MUST walk through all 7 categories for every code task that seems security relevant.
 >
-> **Guardrail Selection Skill:** In IDEs that support workspace skills, read and apply `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md` when fetching guardrails. In other IDEs, follow that same workflow explicitly: analyze the task, shortlist relevant guardrails, and hydrate the exact shortlist with `get_guardrails_by_id`.
+> **Guardrail Selection Skill:** In IDEs that support workspace skills, read and apply `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md` when fetching guardrails. In other IDEs, follow that same workflow explicitly: analyze the task, shortlist relevant guardrails, and hydrate the exact shortlist with `get_guardrail_by_id`.
 
 ### When NOT to apply
 
@@ -28,7 +28,7 @@ If in doubt, do a quick mental scan: *does this change touch auth, input handlin
 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`, shortlisted intentionally, and then hydrated via `get_guardrails_by_id`. Enforces concrete implementation rules derived from prior threat reviews, compliance requirements, and team decisions.
+2. **Secure by Code (Vibe Guardrails)** — Project-specific coding dos and don'ts fetched from SRAI via `get_guardrails`, shortlisted intentionally, and then hydrated via `get_guardrail_by_id`. 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.
 
@@ -83,7 +83,7 @@ Rather than fetching the entire profile at once, walk through each reasoning blo
 10. **Fetch Vibe Guardrails** — Follow `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
     - Call `get_guardrails` with `project_id` to load the broad catalog.
     - Analyze the task and infer the relevant security categories and likely threats first.
-    - Shortlist only the guardrails relevant to the task and fetch the exact shortlist with `get_guardrails_by_id`.
+    - Shortlist only the guardrails relevant to the task and fetch the exact shortlist with `get_guardrail_by_id`.
     - Separate the shortlisted guardrails into `must` (mandatory requirements) and `must_not` (hard prohibitions).
     - Keep the shortlisted exact guardrails in context for the entire code-generation task and for later `ctm_sync`.
     - Cross-reference with PWNISMS findings: if a threat has no corresponding guardrail, flag it as a candidate for a new guardrail.
@@ -116,7 +116,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`, `get_guardrails_by_id` |
+| **Guardrails** | `get_guardrails`, `get_guardrail_by_id` |
 | **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

@@ -27,8 +27,8 @@ When invoked:
    - **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` or `get_guardrails_by_id` here. Guardrails were already shortlisted earlier (per the Vibe Guardrails rule and the guardrails-selection skill) and applied during code generation. From the parent agent context, identify:
-   - Which **existing** guardrails were shortlisted earlier from `get_guardrails` and then hydrated via `get_guardrails_by_id`.
+5. **Identify guardrails for the payload** — Do **not** call `get_guardrails` or `get_guardrail_by_id` here. Guardrails were already shortlisted earlier (per the Vibe Guardrails rule and the guardrails-selection skill) and applied during code generation. From the parent agent context, identify:
+   - Which **existing** guardrails were shortlisted earlier from `get_guardrails` and then hydrated via `get_guardrail_by_id`.
    - Which of those shortlisted existing 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. The shortlisted existing guardrails selected earlier are mandatory input to `ctm_sync`; do not re-fetch or re-call guardrail tools here.
@@ -134,7 +134,7 @@ Use the following IDs and names exactly when populating `owasp_top_10_2025_mappi
 - Every `threats_mitigated` entry must map to one of the 7 PWNISMS categories.
 - 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` or `get_guardrails_by_id` during CTM sync. Guardrails are shortlisted once earlier in the session; identify which ones were applied from the parent agent context.
+- Do not call `get_guardrails` or `get_guardrail_by_id` during CTM sync. Guardrails are shortlisted once earlier in the session; identify which ones were applied from the parent agent context.
 - Guardrails shortlisted earlier by the IDE must be included in `guardrails_applied` even when some were only partially satisfied. Use `satisfied: false` plus `notes` instead of silently dropping them.
 - `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.

package/src/generators/rules/ctm_sync_rule.md

@@ -38,7 +38,7 @@ This rule is **triggered** whenever the assistant:
   - "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 shortlisted via the guardrails-selection workflow (`get_guardrails` + `get_guardrails_by_id`) and applied to generated code
+  - Guardrails were shortlisted via the guardrails-selection workflow (`get_guardrails` + `get_guardrail_by_id`) 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
 

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

@@ -1,6 +1,6 @@
 ---
 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_guardrails_by_id before implementation. Use for every security-relevant code task before code is written and preserve the shortlist for CTM sync.
+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 CTM sync.
 ---
 
 # Guardrails Selection
@@ -15,7 +15,7 @@ This skill exists to stop the IDE from treating the full `get_guardrails` result
 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_guardrails_by_id`.
+5. Fetch the exact shortlisted guardrails with `get_guardrail_by_id`.
 6. Carry that same shortlist forward into implementation and `ctm_sync`.
 
 Do not skip the analysis step. Do not rely on title-matching alone. Do not dump every guardrail into the final answer.
@@ -126,13 +126,13 @@ Examples:
 
 ### Step 3: Hydrate exact shortlisted guardrails
 
-For every shortlisted existing guardrail, call `get_guardrails_by_id` to retrieve the exact guardrail that will govern implementation.
+For every shortlisted existing guardrail, call `get_guardrail_by_id` to retrieve the exact guardrail that will govern implementation.
 
-- Use `get_guardrails_by_id` for the shortlisted ids only.
+- 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_guardrails_by_id`, not by vague memory from the broad catalog listing.
+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
 
@@ -162,7 +162,7 @@ When deciding whether a guardrail applies, prefer security-preserving inclusion
 
 ## CTM Sync Handoff Contract
 
-`ctm_sync` must reuse the shortlist from this skill. It must not call `get_guardrails` or `get_guardrails_by_id` again.
+`ctm_sync` must reuse the shortlist from this skill. It must not call `get_guardrails` or `get_guardrail_by_id` again.
 
 Before `ctm_sync` is invoked, ensure the parent context clearly contains:
 

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

@@ -10,7 +10,7 @@ The intent is not to produce a full threat model here. The intent is to make sur
 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_guardrails_by_id`.
+5. Fetch those guardrails with `get_guardrail_by_id`.
 
 ## STRIDE-style mappings for guardrail selection
 

package/src/generators/rules/guardrails_rule.md

@@ -33,16 +33,16 @@ That skill is mandatory because the IDE must not leave guardrail selection to ch
 - **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_guardrails_by_id` for the shortlisted guardrail ids so implementation uses the exact selected guardrails, not a vague reading of the full catalog.
+- **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 `ctm_sync` 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_guardrails_by_id` result.
+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_guardrails_by_id` |
+| `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` |
@@ -90,5 +90,5 @@ Guardrails are living artifacts. The IDE agent can create, apply, and update the
 | Tool | Purpose |
 |---|---|
 | `get_guardrails` | Fetch the broad project guardrails catalog (requires `project_id`) |
-| `get_guardrails_by_id` | Fetch the exact shortlisted guardrails that will govern implementation |
+| `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

@@ -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. **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_guardrails_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. **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 the exact shortlisted guardrails from earlier plus any IDE-generated guardrails in the guardrails_applied payload field; do not query again during ctm_sync. 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.\"}'",
+        "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. **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 the exact shortlisted guardrails from earlier plus any IDE-generated guardrails in the guardrails_applied payload field; do not query again during ctm_sync. 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

@@ -33,7 +33,7 @@ Before deep analysis, pull project context from `security-review-mcp` (if availa
    - `get_data_dictionaries` — sensitive data assets
    - `get_security_objectives` — compliance targets
    - `get_findings` — aggregated insights
-10. **Vibe Guardrails** — Use `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md` with `project_id` to load the guardrail catalog, shortlist the relevant guardrails, and hydrate the exact implementation set with `get_guardrails_by_id`.
+10. **Vibe Guardrails** — Use `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md` with `project_id` to load the guardrail catalog, shortlist the relevant guardrails, and hydrate the exact implementation set with `get_guardrail_by_id`.
 
 If SRAI is not available, proceed with whatever context the user provides — files, diffs, PRs, architecture docs.
 
@@ -224,7 +224,7 @@ 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 shortlisted earlier via `get_guardrails` + `get_guardrails_by_id` (`source: "existing"`) and new ones the IDE agent created on the fly (`source: "ide_generated"`), each with satisfaction status
+- **Guardrails applied**: all guardrails enforced during this session — both existing ones shortlisted earlier via `get_guardrails` + `get_guardrail_by_id` (`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