@securityreviewai/securityreview-kit 0.1.50 → 0.1.52

package/src/generators/rules/gemini.js

@@ -0,0 +1,13 @@
+import { join } from 'node:path';
+import { upsertSentinelBlock } from '../../utils/fs-helpers.js';
+import { getRuleContent } from './content.js';
+
+/**
+ * Generate Gemini CLI / Antigravity workspace rule — appends to GEMINI.md
+ */
+export function generate(cwd, options = {}) {
+    const filePath = join(cwd, 'GEMINI.md');
+    const content = getRuleContent(options);
+    const action = upsertSentinelBlock(filePath, content);
+    return { filePath, action };
+}

package/src/generators/rules/guardrails-init-profile.md

@@ -0,0 +1,56 @@
+---
+name: guardrails-init-profile
+description: Run the Security Review Kit guardrails profiler — scan the repo, write `.guardrails/profile.json`, push the profile and default guardrail pack to SecurityReview.ai via MCP.
+---
+
+# Guardrails init profile
+
+Execute the workflow defined in **`{{GUARDRAILS_SKILL_DIR}}/SKILL.md`** end-to-end in this workspace (this IDE’s copy of the guardrails-profiler skill).
+
+Configured SRAI project name: `<SRAI_PROJECT_NAME>`
+
+**You must:**
+
+1. Read `{{GUARDRAILS_SKILL_DIR}}/SKILL.md` and follow every step (use the signal registry at `{{GUARDRAILS_SKILL_DIR}}/references/signal-registry.json`).
+2. Write `.guardrails/profile.json` as specified.
+3. Call **`update_vibe_profile`** and **`write_default_pack`** on `security-review-mcp` after resolving `project_id` for `<SRAI_PROJECT_NAME>`.
+
+Do not skip MCP upload when credentials and MCP are available.
+
+Do **not** ask the user to verbally approve MCP for `security-review-mcp`. The init-time profiler runner passes the CLI-specific MCP configuration and approval settings where supported; call the MCP tools directly.
+
+## Cursor CLI (scripted)
+
+From the repo root, non-interactive runs should include workspace trust and MCP approval:
+
+`agent -p "<your profiling instructions>" --trust --approve-mcps` (or `cursor-agent` if that is what your install provides)
+
+Add `--output-format stream-json --stream-partial-output` only when you need verbose agent diagnostics (or use `securityreview-kit init` with `--profiler-verbose`).
+
+During `securityreview-kit init`, choose **Yes** when asked to run Cursor login in-terminal, or pass **`--profiler-cursor-login`** with **`--profile-repo`** so login and profiling stay in one run.
+
+You can still sign in manually with `agent login` (or `cursor-agent login`). To handle trust/login interactively in the terminal, omit `--trust` and `--approve-mcps`.
+
+## Claude Code CLI (scripted)
+
+From the repo root, non-interactive runs should execute with the project settings file, the project `.mcp.json` server config, explicit MCP-only loading, bypassed tool prompts for the profiling pass, and the Haiku model:
+
+`claude -p "<your profiling instructions>" --settings .claude/settings.json --mcp-config "$(cat .mcp.json)" --strict-mcp-config --permission-mode bypassPermissions --model haiku`
+
+During `securityreview-kit init`, choose **Yes** when asked to run Claude Code login, or pass **`--profiler-claude-login`** with **`--profile-repo`** so `claude auth login` and profiling stay in one run.
+
+Claude profiling can also run with **Anthropic Console**, **ANTHROPIC_API_KEY**, an **Anthropic-compatible gateway** (`ANTHROPIC_BASE_URL` + `ANTHROPIC_AUTH_TOKEN`), or cloud-provider credentials such as **AWS Bedrock** and **Google Vertex AI**. `securityreview-kit init` can branch into those auth modes before profiling.
+
+## GitHub Copilot CLI (scripted)
+
+From the repo root, non-interactive runs should load the SRAI MCP server and allow the tools needed to scan, write profile files, and call MCP:
+
+`copilot -p "<your profiling instructions>" --additional-mcp-config '{"mcpServers":{"security-review-mcp":{"type":"stdio","command":"npx","args":["-y","@securityreviewai/security-review-mcp@latest"]}}}' --allow-all`
+
+During `securityreview-kit init`, choose **Yes** when asked to run GitHub Copilot CLI login, or pass **`--profiler-copilot-login`** with **`--profile-repo`** so `copilot login` and profiling stay in one run.
+
+## Codex CLI (scripted)
+
+From the repo root, non-interactive runs should execute via `codex exec` and include the SRAI MCP server configuration for that run.
+
+During `securityreview-kit init`, choose **Yes** when asked to run Codex login, or pass **`--profiler-codex-login`** with **`--profile-repo`** so `codex login --device-auth` and profiling stay in one run.

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

@@ -0,0 +1,130 @@
+---
+name: guardrails-profiler
+description: Profile a codebase to detect its technology stack and generate a guardrails profile for security-aware AI code generation, then publish the profile and default guardrail pack to SecurityReview.ai via security-review-mcp. Use when Security Review Kit init runs profiling, when `.guardrails/profile.json` is missing, or when the developer asks to profile or re-profile the project.
+---
+
+# Guardrails Profiler
+
+Profile a codebase's technology stack, write `.guardrails/profile.json`, and upload the detected profile and default guardrail pack to SRAI using `update_vibe_profile` and `write_default_pack`.
+
+Configured SRAI project name: `<SRAI_PROJECT_NAME>`
+
+## Canonical paths
+
+- **This skill & signal registry (read-only):** `<GUARDRAILS_SKILL_DIR>/` — e.g. `.cursor/skills/guardrails-profiler`, `.github/skills/guardrails-profiler`, `.claude/skills/guardrails-profiler`, or `.codex/skills/guardrails-profiler` for Codex depending on where this file was installed.
+- **Signal registry file:** `<GUARDRAILS_SKILL_DIR>/references/signal-registry.json`
+- **Local guardrails file:** `.guardrails/profile.json`
+
+## When This Runs
+
+1. **Kit init**: User opted in to profile the repo and push the default pack.
+2. **First-run / missing profile**: No `.guardrails/profile.json` and guardrails are needed before threat modeling.
+3. **Explicit re-profile**: Developer asks to refresh the profile.
+
+## Quick Check: Should I Profile?
+
+Before profiling, check if a profile already exists:
+
+- If `.guardrails/profile.json` exists and has a valid `schema_version`: **SKIP** unless the developer asked to re-profile.
+- If missing: **PROCEED**.
+
+## Profiling Procedure
+
+Follow these steps in order.
+
+### Step 1: Locate the Project Root
+
+The project root is the current working directory. Confirm with markers such as `.git/`, `package.json`, `go.mod`, etc.
+
+### Step 2: Read the Signal Registry
+
+Read `<GUARDRAILS_SKILL_DIR>/references/signal-registry.json` (the copy next to this `SKILL.md`). Use its categories (`universal`, `languages`, `frameworks`, `auth_identity`, `ai_agent`, `infrastructure`, `ci_cd`, `cloud_compute`, `databases`, `messaging`, `api_protocols`, etc.) to map detected signals to guardrail pack IDs.
+
+### Step 3: Scan for Signals
+
+Same methodology as the upstream guardrails-profiler skill:
+
+#### 3a. Manifest and Config File Detection
+
+List files in the project root (1–2 levels deep). Detect manifests (`package.json`, `pyproject.toml`, `go.mod`, `pom.xml`, `Dockerfile`, `.github/workflows/`, `next.config.*`, etc.) per the registry.
+
+#### 3b. Dependency Parsing
+
+For each manifest found, read dependencies and match names against `dependency_signals` in the registry. Prefer manifests over extension-only guesses.
+
+#### 3c. Content Signals (targeted only)
+
+When needed, grep specific files (e.g. Terraform providers, K8s `apiVersion`, CloudFormation) — do not read the entire repository.
+
+#### 3d. File Extension Fallback
+
+If no manifest exists for a language, use dominant extensions as a last resort.
+
+### Step 4: Assemble the Guardrails Profile Object
+
+Build the object for `.guardrails/profile.json`:
+
+```json
+{
+  "schema_version": "1.0",
+  "project_name": "<directory name>",
+  "profiled_at": "<ISO 8601 timestamp>",
+  "profiled_by": "<ide or cli id, e.g. agent, cursor-agent, claude, codex>",
+  "detection_summary": {
+    "languages": [],
+    "frameworks": [],
+    "infrastructure": [],
+    "databases": [],
+    "auth": [],
+    "ai_agent": [],
+    "ci_cd": [],
+    "cloud_compute": [],
+    "messaging": [],
+    "api_protocols": [],
+    "mobile": false
+  },
+  "guardrail_packs": [],
+  "pack_count": 0
+}
+```
+
+Rules for `guardrail_packs`:
+
+1. Always include `owasp-asvs`.
+2. Include `owasp-masvs` if mobile stacks are detected (flutter, react-native, swift, objective-c, kotlin per registry).
+3. Add language, framework, auth, AI, infra, CI/CD, cloud, DB, messaging, and API packs per registry matches.
+4. Deduplicate and set `pack_count`.
+
+Do **not** invent packs or signals; if the repo is empty, use universal baseline only and empty category arrays where appropriate.
+
+### Step 5: Write `.guardrails/profile.json`
+
+Create `.guardrails/` if needed and write the profile file.
+
+### Step 6: Upload to SecurityReview.ai (security-review-mcp)
+
+1. Resolve `project_id`: `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"`. If missing, follow existing kit rules (`list_projects`, `create_project`).
+
+2. Call **`update_vibe_profile`** with `project_id` and arguments mapped directly from the `.guardrails/profile.json` object (and any required `project_id` fields) per the MCP tool’s documented schema. Treat the guardrails detection object as the profile payload — **not** a separate prose vibe document.
+
+3. Call **`write_default_pack`** with `project_id`, `guardrail_packs`, and `pack_count` derived from `.guardrails/profile.json` (match the MCP tool’s schema).
+
+4. **MCP approval:** Do **not** ask the user to “approve MCP” or “say you approve” for `security-review-mcp`. Security Review Kit passes the configured MCP server and approval settings during init-time profiling where the CLI supports it (for example Cursor CLI permissions and Copilot CLI `--additional-mcp-config` / `--allow-all`). Invoke `find_project_by_name`, `update_vibe_profile`, and `write_default_pack` directly. If a call still fails with permissions, report the exact CLI permission error — not a conversational approval step.
+
+5. Confirm success: path written (`.guardrails/profile.json`) and whether both MCP calls succeeded, or the exact error.
+
+### Step 7: Report
+
+Give a concise summary of detected stack, pack count, and upload status.
+
+## Empty / New Repository Handling
+
+If there are no signals:
+
+1. Optionally read `.git/config` for hints.
+2. Emit minimal profile: `owasp-asvs` only, empty summaries where appropriate.
+3. Still write `.guardrails/profile.json` (minimal baseline profile) and attempt MCP calls.
+
+## IDE-Specific Notes
+
+When run from Cursor Agent CLI, GitHub Copilot CLI, Claude Code, or Codex CLI, set `profiled_by` to a stable id (`agent` or `cursor-agent`, `copilot`, `claude`, `codex`).