@securityreviewai/securityreview-kit 0.1.42 → 0.1.44

package/src/utils/constants.js

@@ -83,12 +83,12 @@ export const THREAT_MODELLING_SKILL_REL_DIR = {
     codex: '.codex/skills/threat-modelling',
 };
 
-/** Relative workspace paths for the CTM sync agent/workflow (per IDE / CLI). */
-export const CTM_SYNC_AGENT_REL_PATH = {
-    cursor: '.cursor/agents/ctm_sync.md',
-    claude: '.claude/agents/ctm_sync.md',
-    vscode: '.github/agents/ctm_sync.agent.md',
-    codex: '.codex/agents/ctm_sync.toml',
+/** Relative workspace dirs for the VibeReview markdown sync skill (per IDE / CLI). */
+export const VIBEREVIEW_SYNC_SKILL_REL_DIR = {
+    cursor: '.cursor/skills/vibereview-sync',
+    claude: '.claude/skills/vibereview-sync',
+    vscode: '.github/skills/vibereview-sync',
+    codex: '.codex/skills/vibereview-sync',
 };
 
 export const SENTINEL_START = '<!-- securityreview-kit:start -->';

package/src/generators/rules/create-ide-workflow.md

@@ -1,34 +0,0 @@
----
-name: create-ide-workflow
-description: Create an AI IDE workflow in SRAI via security-review-mcp.
----
-
-# Create IDE Workflow
-
-Use `security-review-mcp` to create a workflow by calling:
-
-- `create_ai_ide_workflow`
-
-Required payload fields:
-
-- `project_id`
-- `name`
-- `description`
-
-## Steps
-
-1. Resolve `project_id`.
-   - Use configured project name `<SRAI_PROJECT_NAME>` by default.
-   - Call `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"`.
-   - If not found, call `list_projects` and select the right project.
-2. Build `name` and `description` from the user request.
-   - Keep `name` short and action-oriented.
-   - Keep `description` specific about trigger and output.
-3. Call `create_ai_ide_workflow` with:
-   - `project_id`
-   - `name`
-   - `description`
-4. Return a concise confirmation including:
-   - project id
-   - workflow name
-   - workflow id from MCP response (if returned)

package/src/generators/rules/ctm_sync.md

@@ -1,215 +0,0 @@
----
-name: ctm_sync
-description: Command/workflow triggered whenever a threat model is generated or updated, or guardrails are proposed/modified. Writes a grounded AI IDE sync markdown file and uploads it through security-review-mcp.
----
-
-# CTM Sync Workflow
-
-Configured SRAI project name: `<SRAI_PROJECT_NAME>`
-
-When invoked:
-
-0. Verify `sync_ai_ide_markdown` exists in `security-review-mcp`.
-1. Read the parent agent context and extract the latest threat model details, guardrail outcomes, and grounded code snippets from the actual work completed in this session.
-2. **Chat session identity (required)** — The markdown MUST include a stable `chat_session_id` for the current IDE chat session:
-   - Use a session identifier supplied by the host environment when one exists (for example, the IDE conversation or session id).
-   - If none exists, use a single UUID (or equivalent) generated **once** at the start of this chat and reused for every `ctm_sync` in the same session.
-   - Put `chat_session_id` in frontmatter whenever possible. The value must exist somewhere in the markdown even if frontmatter is unavailable.
-3. **Create a structured markdown artifact** — `ctm_sync` is now a thin sync shim. Do not build a JSON payload and do not perform workflow lookup or creation client-side. Instead, write a `.md` file under `vibereview/` so all sync artifacts stay in one predictable place. Create the directory if it does not already exist. The markdown file should give the server everything it needs to extract the structured event.
-4. **Populate the markdown with grounded content**:
-   - Include the exact shortlisted existing guardrails selected earlier plus any `ide_generated` guardrails created during the session.
-   - Use real code snippets from the files changed or inspected in this session. Never invent code or mitigation text.
-   - Keep threat names, severities, PWNISMS categories, guardrail satisfaction, and OWASP mappings aligned with the actual work performed.
-5. **Upload the markdown**:
-   - Call `sync_ai_ide_markdown` with the markdown artifact.
-   - The server is responsible for normalizing author identity, deriving a workflow name from the title when needed, and extracting structured output from the markdown.
-6. **Stop there** — Do not call `create_ai_ide_event`, `create_ai_ide_workflow`, or client-side user identity tools from `ctm_sync`.
-
----
-
-## Markdown Contract
-
-The markdown file must be a `.md` document written under `vibereview/`, with frontmatter when available and clear, structured sections underneath. Keep the structure deterministic so the server can parse it reliably.
-
-Recommended path pattern:
-
-```text
-vibereview/<chat_session_id>-<slugified-title-or-event-name>.md
-```
-
-If a safe filename cannot be derived, use any stable `.md` filename inside `vibereview/`.
-
-### Frontmatter
-
-Use YAML frontmatter at the top of the file whenever possible:
-
-```yaml
----
-chat_session_id: "<required stable session id>"
-workflow_name: "<optional short workflow name>"
-workflow_description: "<optional workflow description>"
-title: "<required event title if event_name is omitted>"
-event_name: "<required event name if title is omitted>"
-summary: "<required concise summary>"
----
-```
-
-Rules:
-
-- `chat_session_id` must exist somewhere in the markdown, but frontmatter is preferred.
-- `workflow_name` is optional. If omitted, the server derives it from the title.
-- `workflow_description` is optional.
-- Either `event_name` or `title` must exist. Including both is allowed.
-- `summary` must exist.
-- `developer_name` and `developer_email` in the markdown are ignored. The server always uses the authenticated API user.
-
-### Body sections
-
-Use clear Markdown headings. The exact wording below is preferred because it keeps parsing simple and consistent.
-
-#### Best Practices Achieved
-
-Use plain bullet strings:
-
-```md
-## Best Practices Achieved
-
-- Enforced server-side authorization before updating workflow state.
-- Used parameterized queries for threat-model persistence.
-```
-
-Internally the server accepts both `best_practises_achieved` and `best_practices_achieved`, but authored markdown should prefer a normal `Best Practices Achieved` section with bullets.
-
-#### Threats Mitigated
-
-Each threat entry should include all of the following:
-
-- `threat_name`
-- `pwnisms_category`
-- `severity`
-- `mitigation_applied`
-- grounded code snippet info if available
-
-Preferred structure:
-
-```md
-## Threats Mitigated
-
-### Threat 1
-- threat_name: Missing authorization check on workflow sync endpoint
-- pwnisms_category: IAM
-- severity: High
-- mitigation_applied: Added server-side authorization before allowing markdown sync writes.
-- file_path: src/routes/sync.js
-- language: javascript
-- snippet: |
-    if (!user || !user.canSyncWorkflows) {
-      throw new ForbiddenError('Not allowed to sync workflow markdown');
-    }
-- explanation: Prevents unauthorized users from creating or updating AI IDE sync events.
-```
-
-Notes:
-
-- Snippets must be real code from the repo or actual generated output, not invented text.
-- If no code snippet exists for a threat, omit the snippet block and explain the mitigation in prose.
-
-#### Secure Code Snippets
-
-Include security-relevant snippets that may or may not map 1:1 with a threat:
-
-```md
-## Secure Code Snippets
-
-### Snippet 1
-- file_path: src/server/markdown-sync.ts
-- language: typescript
-- snippet: |
-    const markdown = await fs.readFile(inputPath, 'utf8');
-    await securityReview.syncAiIdeMarkdown({ markdown });
-- explanation: Sends the structured markdown artifact directly to the server-side sync pipeline.
-```
-
-#### Guardrails Applied
-
-Each guardrail should include:
-
-- `title`
-- `rule_type` as `must` or `must_not`
-- `source` as `existing` or `ide_generated`
-- `satisfied` as `true` or `false`
-
-Preferred structure:
-
-```md
-## Guardrails Applied
-
-### Guardrail 1
-- title: Enforce authorization on workflow updates
-- rule_type: must
-- category: authorization
-- instruction: Require an authenticated, authorized user before mutating workflow records.
-- source: existing
-- satisfied: true
-- notes: Applied in the server-side markdown sync handler.
-```
-
-The exact shortlist from earlier in the session must be carried forward. Do not call `get_guardrails` or `get_guardrail_by_id` inside `ctm_sync`.
-
-#### OWASP Top 10 2025 Mappings
-
-Use exact IDs and names:
-
-```md
-## OWASP Top 10 2025 Mappings
-
-- A01: Broken Access Control
-- A04: Cryptographic Failures
-```
-
-Allowed values:
-
-| ID | Name |
-|---|---|
-| `A01` | Broken Access Control |
-| `A02` | Security Misconfiguration |
-| `A03` | Software Supply Chain Failures |
-| `A04` | Cryptographic Failures |
-| `A05` | Injection |
-| `A06` | Insecure Design |
-| `A07` | Authentication Failures |
-| `A08` | Software or Data Integrity Failures |
-| `A09` | Security Logging and Alerting Failures |
-| `A10` | Mishandling of Exceptional Conditions |
-
----
-
-## Constraints
-
-- The artifact written by `ctm_sync` must be a `.md` file under `vibereview/`.
-- `chat_session_id` must never be omitted.
-- `summary` must never be omitted.
-- `event_name` or `title` must exist.
-- `workflow_name` and `workflow_description` are optional.
-- `developer_name` and `developer_email` should not influence sync behavior; the server ignores them.
-- Every threat entry must include `threat_name`, `pwnisms_category`, `severity`, and `mitigation_applied`.
-- PWNISMS categories must match the supported set: `Product`, `Workload`, `Network`, `IAM`, `Secrets`, `Monitoring`, `Supply Chain`.
-- `severity` should be one of `Critical`, `High`, `Medium`, or `Low`.
-- Guardrails must include `title`, `rule_type`, `source`, and `satisfied`.
-- `rule_type` must be `must` or `must_not`.
-- `source` must be `existing` or `ide_generated`.
-- `satisfied` must be `true` or `false`.
-- OWASP mappings must use the exact IDs and names listed above.
-- Snippets must be grounded in real code. Never fabricate examples just to fill the markdown.
-- Do not call client-side workflow creation, event creation, or developer identity tools from `ctm_sync`.
-
----
-
-## Output Contract
-
-- Never skip sync when a threat model or guardrail-compliance update exists.
-- Never invent missing values; omit optional fields or use concise prose when exact structured data is unavailable.
-- Return a compact confirmation after upload including:
-  - the markdown file path used for sync, which should point inside `vibereview/`
-  - whether `workflow_name` was explicit or left for server-side derivation
-  - count of guardrails included (existing vs IDE-generated)

package/src/generators/rules/ctm_sync_rule.md

@@ -1,88 +0,0 @@
----
-description: ctm_sync agent trigger rule
-alwaysApply: true
----
-# Continuous Threat Modeling Sync (`ctm_sync`)
-
-**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), 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 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.
-
-If in doubt — **assume this rule applies**.
-
----
-
-## When this rule applies
-
-This rule is **triggered** whenever the assistant:
-
-- **Produces a threat model** in any form, such as:
-  - Threat scenarios (even a short list)
-  - Data flow diagrams or component diagrams described in text
-  - Security objectives or misuse cases
-  - 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"
-- **Enforces guardrails** during code generation and has compliance data:
-  - 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
-
-This includes both:
-- Threat modeling done **directly in this conversation**, and  
-- Threat modeling done by calling **MCP tools or skills** that output threat scenarios, countermeasures, data dictionaries, or other CTM artifacts.
-
----
-
-## Required behavior
-
-**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**
-
-   - The assistant should finish producing the current threat modeling content (threat scenarios, components, data dictionaries, etc.) in the user-visible message or via tools.
-   - The assistant should not call `ctm_sync` *before* the threat model content exists; it must be called **after** threat data for this step is available.
-
-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.
-   - 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")
-     - The `chat_session_id` value to use for this sync
-     - Whether guardrails were applied (existing and/or IDE-generated)
-     - That `ctm_sync` should write a structured `.md` artifact and upload it via `sync_ai_ide_markdown`
-   - **Do NOT include developer name or email in the handoff prompt.** Any identity fields in the markdown are ignored server-side; the authenticated API user is authoritative.
-
-   **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, guardrails applied/proposed, etc.), and that the agent should write the sync markdown and upload it 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.
-
-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).