owasp-top10-2025-cwe-reviewer

Use this skill to review a real repository for likely application-security issues using the local OWASP Top 10:2025 and MITRE CWE knowledge pack in this package.

Purpose

Produce evidence-based repository findings that:

• map each issue to a primary cwe_id
• map that CWE to an OWASP Top 10:2025 category
• cite concrete repository evidence
• distinguish confirmed-likely issues from suspicious-needs-verification items
• aggressively avoid speculative or generic claims

This is a repository review skill, not a generic security education skill.

Required Local Inputs

Use these local files first. Do not browse the web during a repository review if these files exist.

• knowledge/owasp_2025_categories.json
• knowledge/cwe_catalog.json
• knowledge/owasp_to_cwe_index.json
• knowledge/detection_playbook.md
• schemas/finding.schema.json when the user explicitly asks for machine-readable JSON output or validation

If the knowledge pack is missing or the user explicitly asks to refresh it, stop the review workflow and use builder.md instead.

Review Workflow

1. Detect Project Context

Inspect the repository structure before forming conclusions.

• identify primary languages, frameworks, build systems, package managers, and deployment targets
• determine whether the repository contains APIs, backends, frontends, mobile code, CLIs, libraries, IaC, and CI/CD automation
• identify whether auth, admin, payment, file handling, or privileged workflows exist

2. Build an Attack-Surface Inventory

Look for concrete implementation surfaces, especially:

• routes, controllers, RPC handlers, resolvers, webhooks, jobs, and workers
• auth and authorization boundaries
• session, token, password reset, MFA, and logout flows
• input parsing, validation, deserialization, templating, and rendering
• DB access patterns, raw queries, ORMs, search filters, and report builders
• file upload, download, extraction, and path handling
• command execution and subprocess use
• outbound HTTP requests, internal service calls, queues, and callback URLs
• cryptography, hashing, RNG, TLS, certificates, keys, and secret loading
• dependency manifests, lockfiles, registries, package scripts, and updater logic
• CI/CD workflows, artifact publishing, provenance, signing, and release controls
• logging, audit events, alert generation, and telemetry configuration
• exception handling, fallback behavior, retries, rollbacks, and fail-open paths
• debug, test-only, admin, or support-only surfaces

3. Generate Candidate Weaknesses From Evidence

For each suspicious pattern:

• tie it to specific files and lines whenever available
• identify the narrowest accurate cwe_id you can support from knowledge/cwe_catalog.json
• prefer specific mapped CWEs over umbrella class/category entries
• if the best fit is broad, say so in the assumptions or reasoning

Use these status rules:

• confirmed-likely: the repository contains a concrete insecure implementation or configuration pattern with a plausible abuse path
• suspicious-needs-verification: the repository contains a real signal, but exploitability depends on an upstream control, runtime condition, deployment setting, or missing context
• if evidence is too weak, do not emit a finding

4. Map Each Finding to OWASP Top 10:2025

For every primary CWE:

• resolve the OWASP category through knowledge/owasp_to_cwe_index.json
• copy the exact OWASP category id and name from knowledge/owasp_2025_categories.json
• copy the exact CWE title from knowledge/cwe_catalog.json

Never confuse the weakness with the category:

• CWE = weakness mapping
• OWASP = higher-level risk category

5. Enforce Precision Controls

Do not report a finding unless all of these are true:

• there is a concrete code, config, manifest, workflow, or infrastructure signal in the repository
• the signal maps cleanly to a plausible CWE using the local catalog
• the abuse path is explained without hand-waving

Apply these guardrails on every finding:

• generated code, fixtures, mocks, examples, demo apps, or docs are not production findings unless they are wired into shipped behavior
• dangerous API presence alone is insufficient without insecure usage context
• framework middleware, route decorators, cloud controls, or centralized wrappers may enforce a control upstream; state uncertainty instead of asserting bypass
• suspicious config in a template may be overridden safely elsewhere
• dependency risk alone is insufficient unless you explain the concrete trust, integrity, or execution impact in this repository
• never claim the repository is secure
• always separate observed evidence from inferred risk

6. Prioritize Findings

Start broad, then go deep where the evidence is strongest.

Prioritize:

• externally reachable request handlers
• privilege-bearing code paths
• auth/authz boundaries
• injection and interpreter boundaries
• cryptographic and key-handling logic
• integrity and supply-chain controls
• error handling and exceptional-condition boundaries

Report the most defensible findings first. Avoid flooding the user with low-confidence noise.

Severity And Confidence

Use practical engineering judgment.

• critical: strong evidence of high-impact compromise such as RCE, auth bypass to privileged functions, or clear secret/key exposure in a critical path
• high: strong evidence of serious data access, write access, injection, or auth failure
• medium: meaningful weakness with realistic impact but narrower reach, stronger preconditions, or compensating controls likely
• low: real issue with limited impact or primarily defense-in-depth value

Confidence should reflect evidence quality, not impact:

• high: direct insecure implementation or config is visible in the repository
• medium: evidence is solid but depends on one or two explicit assumptions
• low: there is a real signal, but substantial deployment or runtime uncertainty remains

Output Contract

Return a concise Markdown security-review report suitable for chat.

Do not return raw JSON by default. Only return JSON when the user explicitly asks for a machine-readable export, asks to validate output against schemas/finding.schema.json, or the calling environment requires structured output.

Use this chat report shape:

## Security Review Summary

- Project: <project type>
- Stack: <languages and frameworks>
- Scope reviewed: <short coverage summary>
- Result: <finding count and highest severity, or "no evidence-backed findings">

## Confirmed Likely Findings

### F-001: <title>

- Severity: <low|medium|high|critical>
- Confidence: <low|medium|high>
- Mapping: <OWASP category id and name> / <CWE id and name>
- Evidence: `<path>:<lines>` - <concrete repository evidence>
- Why it matters: <reasoning>
- Exploit path: <plausible abuse path>
- Remediation: <specific fix>
- Assumptions: <explicit assumptions, or "None">

## Suspicious Items Needing Verification

Use the same finding format for `suspicious-needs-verification` items.

## Manual Verification Needed

- <unresolved trust boundary or runtime condition>

## Coverage Gaps

- <source, deployment, SaaS, runtime, or infrastructure area not reviewable from the repository>

If no evidence-backed findings are identified, say so directly and still include manual verification items and coverage gaps. Never state or imply that the repository is secure.

For optional JSON export, use the logical shape defined by schemas/finding.schema.json with scan_summary, findings, manual_verification_needed, and coverage_gaps.

Output Rules

• sort highest-confidence, highest-severity findings first
• separate confirmed-likely findings from suspicious-needs-verification items in the chat report
• keep every finding traceable to the same fields required by schemas/finding.schema.json
• include line references when available; if exact lines are unavailable, say why
• include explicit assumptions whenever exploitability depends on unknown runtime conditions
• include meaningful coverage_gaps whenever infrastructure, runtime policy, SaaS settings, secrets managers, or deploy-time controls were not reviewable from source
• include manual_verification_needed for every suspicious but unresolved trust boundary
• do not include raw JSON in the chat response unless explicitly requested

Category Review Focus

Use knowledge/detection_playbook.md for the detailed repo-review checklist. At minimum, review with these lenses:

• A01:2025 Broken Access Control: missing authorization, IDOR/BOLA, admin surfaces, path traversal, forced browsing, SSRF-related boundary failures
• A02:2025 Security Misconfiguration: debug surfaces, permissive CORS, unsafe parser flags, exposed admin features, insecure defaults, embedded secrets
• A03:2025 Software Supply Chain Failures: untrusted registries, risky install/build hooks, weak CI/CD trust assumptions, unmaintained or pinned-bad components
• A04:2025 Cryptographic Failures: weak algorithms, plaintext handling, key misuse, disabled certificate validation, weak RNG, insecure password hashing
• A05:2025 Injection: raw query construction, shell injection, XSS, template injection, XPath/LDAP/EL injection, unsafe eval paths
• A06:2025 Insecure Design: missing rate limits, dangerous workflow assumptions, client-side enforcement, upload design flaws, anti-abuse gaps
• A07:2025 Authentication Failures: weak auth flows, bad token/session handling, password reset issues, brute-force gaps, MFA weaknesses
• A08:2025 Software or Data Integrity Failures: unsafe deserialization, unsigned updates, untrusted artifacts, mutable trusted state, CI tampering opportunities
• A09:2025 Security Logging and Alerting Failures: missing audit coverage, sensitive data in logs, log injection, no alerting around security events
• A10:2025 Mishandling of Exceptional Conditions: fail-open behavior, swallowed exceptions, partial rollbacks, unsafe fallback logic, abnormal-condition bypasses

Non-Negotiable Runtime Behavior

• do not use live web access for a normal repo review when the local knowledge pack is present
• do not make unsupported exploitability claims
• do not emit generic best-practice advice without repository evidence
• do not emit findings that depend entirely on unknown production configuration unless marked suspicious-needs-verification
• do not broaden a finding from a narrow signal to a vague OWASP umbrella weakness

The best output is short, defensible, specific, and directly traceable to repository evidence plus the local OWASP/CWE pack.