@securityreviewai/vibereview-cli 0.1.0

package/skills/vibereview-report/references/report-contract.md

@@ -0,0 +1,100 @@
+# VibeReview Markdown report contract
+
+The report is Markdown with YAML frontmatter. Keep the frontmatter and Summary; add, revise, reorder, or remove the other sections when needed to represent the session's current security state. Do not retain empty or stale sections merely to match the example.
+
+```markdown
+---
+schema_version: "1"
+chat_session_id: "<stable ID for this IDE chat>"
+workflow_name: "<stable short name for this chat's feature workflow>"
+title: "<current human-readable feature title>"
+project: "<workspace project name>"
+provider: "<cursor|codex|claude|copilot>"
+status: "complete|partial|analysis_only"
+created_at: "<ISO-8601 timestamp>"
+updated_at: "<ISO-8601 timestamp>"
+---
+
+# <Title>
+
+## Summary
+
+<What was requested, what now exists, and the overall security result.>
+
+## Scope and Assumptions
+
+- **Scope:** ...
+- **Assets:** ...
+- **Entry points:** ...
+- **Trust boundaries:** ...
+- **Assumptions:** ...
+
+## Threats Mitigated
+
+### T-01 — <Threat title>
+
+- **PWNISMS category:** Product | Workload | Network | IAM | Secrets | Monitoring | Supply Chain
+- **Scenario:** <actor/action/impact>
+- **Likelihood:** low | medium | high
+- **Impact:** low | medium | high | critical
+- **Status:** mitigated | partial | open | not_applicable
+- **Mitigation:** <implemented control>
+- **Guardrails:** <IDs or None>
+- **Evidence:** <repository paths/tests/configuration>
+
+## Best Practices Achieved
+
+- **<Practice>:** <what was implemented and where>
+
+## Dependency Security (OSV.dev)
+
+### `<ecosystem>:<package>@<evaluated version>`
+
+- **Change:** added | upgraded | downgraded | replaced
+- **Result:** clear | remediated | residual_risk | unverified
+- **Advisories:** <OSV IDs and severity, or None found>
+- **Decision:** <accepted version, replacement, removal, or unresolved reason>
+- **Verification:** <initial scan and required re-scan outcome>
+
+Use `Not applicable — no dependency changes` when the feature did not change dependencies. Never use `clear` for a failed query, unknown severity, missing exact version, or an unscanned remediation version.
+
+## Secure Code Changes
+
+### `<repository-relative path>`
+
+<Short explanation of the security-relevant change. Include a small fenced excerpt only when it materially helps the reader.>
+
+## Guardrails Applied
+
+### `<guardrail id>` — <title>
+
+- **Source:** pack | code_generated | custom
+- **Type:** must | must_not
+- **Category:** ...
+- **Satisfied:** yes | no
+- **Application:** <how the implementation complied, or why it did not>
+- **Evidence:** <paths/tests>
+
+## OWASP Mappings
+
+- **<OWASP identifier and title>:** <mapped threats and controls>
+
+## Verification
+
+- `<command or check>` — passed | failed | not run — <important result>
+
+## Residual Risks
+
+- <Remaining exposure, operational dependency, deferred decision, or `None identified within the reviewed scope`.>
+```
+
+## Field semantics
+
+- `workflow_name` remains stable in follow-ups even if `title` changes as scope becomes clearer.
+- The canonical filename is `<chat_session_id>.md`; `chat_session_id` and `created_at` are immutable for the session.
+- Every update is a current-state rewrite. The agent may add, revise, or remove entries and optional sections based on the latest feature and repository state.
+- `status: complete` means the requested implementation and relevant checks completed; it does not mean zero residual risk.
+- `status: partial` covers incomplete implementation, failed checks, or material open mitigations.
+- `status: analysis_only` is for threat-model/design-only requests with no implementation.
+- **Threats Mitigated** retains open or partial threats despite the heading; their explicit statuses prevent false claims and preserve the familiar VibeReview field name.
+- **Best Practices Achieved**, **Secure Code Changes**, **Guardrails Applied**, and **OWASP Mappings** correspond to the established VibeReview artifact fields while remaining readable Markdown.

package/skills/vibereview-secure-code/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: vibereview-secure-code
+description: Implement a security-relevant coding request using its completed PWNISMS threat model and selected local VibeReview guardrails. Use after pre-implementation threat modelling to produce secure-by-default code and verification evidence.
+---
+
+# VibeReview Secure-by-Default Implementation
+
+Implement the user's requested behavior while satisfying the active VibeReview guardrails and threat mitigations. Security controls should be part of the normal code path, not an optional hardening layer.
+
+## Preconditions
+
+- The current prompt has been evaluated for security relevance.
+- Applicable guardrails have been selected from the local workspace.
+- The PWNISMS pass has identified the threats and required mitigations.
+- If dependencies change, exact proposed versions have been checked with `vibereview-osv-scan`, including a re-scan of any selected remediation version.
+
+If the prompt has no implementation work, do not manufacture code. If it asks only for a threat model or design, proceed directly to the report after the requested analysis.
+
+## Implement from the security boundary inward
+
+1. Identify the exact entry point or state transition being changed.
+2. Establish trusted identity, authorization, ownership, or tenant context before protected access.
+3. Validate and normalize untrusted data at the boundary using established local mechanisms.
+4. Preserve security-significant ordering such as verify-before-parse, authorize-before-read, and persist-before-side-effect where applicable.
+5. Route sensitive operations through repository-specific helpers and wrappers required by code-specific or custom guardrails.
+6. Make safe behavior the default and unsafe bypasses difficult or impossible for ordinary callers.
+7. Add bounded failure handling, abuse controls, safe errors, and redacted observability proportionate to the threat model.
+8. Avoid introducing a dependency when existing platform or repository functionality is sufficient. When a dependency changes, use the OSV-verified version, preserve the project's lock and integrity workflow, and record verification honestly. Never describe an unreachable or inconclusive OSV check as clean.
+
+Do not weaken or bypass a `must`/`must_not` rule for convenience. Do not silently broaden scope beyond the requested feature.
+
+## Verify guardrail satisfaction
+
+After implementation, evaluate every shortlisted guardrail:
+
+- `satisfied: true` only when the resulting code demonstrably complies;
+- `satisfied: false` when it does not, with the reason and consequence;
+- note the implementation path, test, or configuration that provides evidence.
+
+Update each threat status:
+
+- `mitigated` when the implemented control and relevant verification address it;
+- `partial` when material exposure remains;
+- `open` when no mitigation was implemented;
+- `not_applicable` only when later evidence shows the scenario cannot occur.
+
+Do not claim a threat is mitigated merely because the intended control was discussed.
+
+## Verification
+
+Run proportionate checks available in the repository: focused tests, type checking, linting, schema validation, authorization-negative cases, malformed-input cases, replay/idempotency cases, or other checks tied to the actual mitigations.
+
+Record commands and outcomes accurately. Never label checks as passed when they were not run, were blocked, or failed.
+
+## Handoff
+
+Pass the final implementation state, changed paths, verification results, OSV dependency evidence, threat statuses, guardrail satisfaction, best practices achieved, OWASP mappings, and residual risks to `vibereview-report`. The report must describe the code that now exists, not the plan that existed before implementation.

package/skills/vibereview-secure-code/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "VibeReview Secure Code"
+  short_description: "Implement code from threats and guardrails"

package/skills/vibereview-threat-model/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: vibereview-threat-model
+description: Perform a focused pre-implementation PWNISMS threat model for a security-relevant coding request using the active local VibeReview guardrail shortlist. Use after guardrail selection and before code is written or changed.
+---
+
+# VibeReview PWNISMS Threat Model
+
+Threat-model the requested change before implementation. Produce an implementation-focused model, not an architecture inventory or exhaustive attack catalog.
+
+## Preconditions
+
+- `vibereview-guardrails` has produced the exact active shortlist from `.vibereview/guardrails.yml`.
+- Scope is concrete enough to identify the affected behavior and code paths. Make narrow, explicit assumptions when details are unavailable; ask only when a missing choice would materially change the implementation.
+- Do not edit implementation files until this pass is complete.
+
+## Establish context
+
+Capture the requested behavior, affected components, actors, privileges, protected assets, entry points, exits, trust boundaries, sensitive state changes, assumptions, and active guardrails. Use repository evidence relevant to the requested change. Do not perform full architecture profiling.
+
+## Walk all PWNISMS categories
+
+Check every category, but keep non-applicable categories to a one-line reason. Detailed checks are in [references/pwnisms.md](references/pwnisms.md).
+
+1. **Product** — input/output, injection, deserialization, business logic, replay, races, errors, file handling.
+2. **Workload** — runtime identity, isolation, storage, queues, jobs, resource exhaustion, deployment posture.
+3. **Network** — exposed interfaces, TLS, CORS, SSRF, redirects, ingress/egress, rate and size limits.
+4. **IAM** — authentication, authorization, ownership, tenancy, roles, sessions, service identity, privilege escalation.
+5. **Secrets** — acquisition, storage, use, rotation, leakage, logs, defaults, client exposure.
+6. **Monitoring** — security events, auditability, redaction, abuse signals, alertability, failure visibility.
+7. **Supply Chain** — new or changed dependencies, build steps, actions, images, provenance, unsafe generated code.
+
+## Create actionable threats
+
+Keep threats that are plausible for this feature and materially affect design or implementation. Each retained threat needs:
+
+- stable local identifier such as `T-01`;
+- PWNISMS category;
+- threat scenario stated as actor/action/impact;
+- affected asset or boundary;
+- likelihood: `low`, `medium`, or `high`;
+- impact: `low`, `medium`, `high`, or `critical`;
+- concrete mitigation for this implementation;
+- mapped guardrail IDs, when applicable; and
+- initial status: `planned`, `mitigated`, `partial`, `open`, or `not_applicable`.
+
+Prioritize roughly three to seven meaningful threats. More is acceptable only when the feature truly spans several distinct boundaries. Do not inflate counts with generic variations.
+
+## Map guardrails and gaps
+
+For each threat, identify which shortlisted `must` or `must_not` rule constrains it. A guardrail may mitigate several threats, and a threat may need several guardrails.
+
+When a realistic threat lacks a guardrail, treat its mitigation as a feature-specific secure-design decision. Do not mutate the workspace guardrail file or invent a permanent `code_specific` rule during this workflow; regeneration is handled by `vibereview guardrails generate`.
+
+If the requested behavior cannot be implemented safely without changing product requirements, credentials, infrastructure, or another user-owned decision, surface that decision before coding. Otherwise continue with the safest in-scope implementation.
+
+## Handoff
+
+If the proposal adds, replaces, upgrades, or downgrades a dependency, pass that exact dependency delta to `vibereview-osv-scan` before implementation. General supply-chain reasoning is not a substitute for checking the resolved version.
+
+Pass the threat set, assumptions, active guardrail shortlist, and mitigation requirements to `vibereview-secure-code`. Keep this analysis in working context; the user-facing durable form is the Markdown report written after implementation.

package/skills/vibereview-threat-model/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "VibeReview Threat Model"
+  short_description: "Run focused PWNISMS analysis before coding"

package/skills/vibereview-threat-model/references/pwnisms.md

@@ -0,0 +1,46 @@
+# PWNISMS checks
+
+Use these as prompts for feature-level analysis, not as a requirement to manufacture findings.
+
+## Product
+
+- Can untrusted input reach interpreters, queries, templates, file paths, redirects, or object construction?
+- Can a caller bypass workflow order, replay an action, race a state transition, or alter server-owned fields?
+- Are errors safe for users while remaining diagnosable?
+- Are upload, download, archive, and serialization boundaries constrained?
+
+## Workload
+
+- Does the change alter runtime privileges, service accounts, filesystem access, queues, schedulers, or background jobs?
+- Can expensive work be triggered without bounds, idempotency, backpressure, or cancellation?
+- Does sensitive state persist with the intended isolation and lifecycle?
+
+## Network
+
+- Are inbound origin, method, size, and rate boundaries explicit?
+- Can user-controlled destinations, redirects, DNS, or proxy behavior cause SSRF or credential forwarding?
+- Are transport security, exposure, and service-to-service authentication appropriate?
+
+## IAM
+
+- Is identity established from a trusted source and revalidated at the sensitive boundary?
+- Are object ownership, tenant scope, roles, and service permissions checked server-side?
+- Can session, token, callback, or account-linking flows be confused or escalated?
+
+## Secrets
+
+- Could credentials enter source, generated files, browser code, URLs, errors, telemetry, or logs?
+- Does the feature use the repository's established secret/key abstraction and preserve rotation or revocation?
+- Are secret values separated by tenant, environment, and purpose where required?
+
+## Monitoring
+
+- Are successful and failed security-relevant actions attributable without logging secrets or unnecessary personal data?
+- Can abuse, repeated denial, privilege changes, and high-impact state transitions be detected?
+- Will failures be observable rather than silently swallowed?
+
+## Supply Chain
+
+- Does the change introduce or update packages, images, actions, plugins, generated artifacts, or build scripts?
+- Are versions and integrity controlled by the repository's normal lock/provenance mechanism?
+- Is generated or third-party code validated before it gains privileged access?