@securityreviewai/securityreview-kit 0.1.13 → 0.1.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -100,3 +100,4 @@ When running `ctm_sync` (dedicated agent/command where available, or the same st
|
|
|
100
100
|
| **Analysis** | `get_threat_scenarios`, `get_countermeasures`, `get_components`, `get_data_dictionaries`, `get_security_objectives`, `get_findings`, `get_security_test_cases` |
|
|
101
101
|
| **Integrations** | `fetch_jira_issue`, `fetch_confluence_page`, `search_confluence_pages`, `fetch_and_link_to_srai` |
|
|
102
102
|
| **AI IDE CTM** | `create_ai_ide_workflow`, `create_ai_ide_event` (and any `list_*` AI IDE workflow tools exposed by the server) |
|
|
103
|
+
| **Profile Update** | `update_vibe_project_profile` |
|
|
@@ -35,10 +35,19 @@ When invoked:
|
|
|
35
35
|
- `secure_code_snippets`
|
|
36
36
|
5. Upload the payload using `security-review-mcp`:
|
|
37
37
|
- Use the tool `create_ai_ide_event`
|
|
38
|
+
6. **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:
|
|
39
|
+
- `description`: a concise summary of the system/project derived from the threat model context (what it does, what data it handles, its overall purpose)
|
|
40
|
+
- `architecture_notes`: a list of architecture observations extracted from the threat model — deployment topology, trust boundaries, data flows, integration points
|
|
41
|
+
- `tech_categories`: a list of technology category labels identified during threat modeling (e.g. `"backend"`, `"frontend"`, `"database"`, `"cloud"`, `"mobile"`)
|
|
42
|
+
- `user_groups`: a list of user roles and groups surfaced in the threat model (e.g. `"admin"`, `"end user"`, `"service account"`)
|
|
43
|
+
- `compliance_requirements`: a list of compliance requirements or standards referenced in the threat model or conversation (e.g. `"PCI-DSS"`, `"HIPAA"`, `"SOC 2"`)
|
|
44
|
+
- `language_stacks`: a list of programming languages, runtimes, and major frameworks identified in the codebase or threat model context (e.g. `"Python/FastAPI"`, `"TypeScript/React"`, `"Java/Spring"`)
|
|
45
|
+
- Omit any field for which no data is available in context — do **not** invent values. Pass an empty list `[]` only if the field is reasonably expected but simply unpopulated.
|
|
38
46
|
|
|
39
47
|
## Output Contract
|
|
40
48
|
|
|
41
49
|
- Never skip upload when a threat model exists.
|
|
42
50
|
- Never invent missing values; use empty strings/arrays if data is unavailable.
|
|
43
51
|
- Never omit `chat_session_id` from the payload.
|
|
44
|
-
-
|
|
52
|
+
- Never skip the `update_vibe_project_profile` call when profile-relevant data (architecture, tech, users, compliance, languages, or description) can be derived from context.
|
|
53
|
+
- Return a compact confirmation after upload (including whether an existing workflow was reused or a new `sessionN` workflow was created, and confirmation that the project profile was updated).
|