domains / security / security-review / security-review

security-review

Skill card

combined

The two skills share the name 'security-review' but perform fundamentally different tasks. The microsoft/power-platform-skills copy is a guided, multi-phase orchestration skill for Power Pages that runs sub-skills (scan-code, scan-site, manage-firewall, etc.) and produces a consolidated HTML report. The getsentry/skills copy is a direct code-analysis skill that applies OWASP-based heuristics to source code to identify exploitable vulnerabilities with confidence-based reporting. They do not reproduce, shorten, or wrap each other; they are distinct procedures for different targets (Power Pages platform vs. general source code).

Repositories

RepositoryPath
microsoft/power-platform-skillsplugins/power-pages/skills/security-review/SKILL.md
getsentry/skillsskills/security-review/SKILL.md

Other copies

RoleRepositoryPath
peermicrosoft/power-platform-skillsplugins/power-pages/skills/security-review/SKILL.md
peergetsentry/skillsskills/security-review/SKILL.md

Combined skill

---
name: security-review
description: >-
  Performs a security review. For Power Pages sites, runs a guided, end-to-end
  review covering source code, dependencies, live site, browser headers,
  firewall, authentication, and role-based permissions, consolidating findings
  into an HTML report. For general source code, applies OWASP-based heuristics
  to identify exploitable vulnerabilities with confidence-based reporting.
user-invocable: true
argument-hint: "[optional natural-language hint about the goal]"
allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Skill, Agent
model: opus
---

# Security Review

This skill handles two distinct review modes. Determine the mode based on the target.

## Mode 1: Power Pages Site Review

Use when the user references a Power Pages site, asks for a release-readiness check, or wants a full platform security review.

### Workflow

The skill has six phases. Phases 2–5 each map to one conversation beat with the user; phases 1 and 6 are silent setup and cleanup.

| Phase | What happens | User-facing beat |
|-------|--------------|------------------|
| 1 — Prerequisites | Locate project, set up working folders | (silent setup) |
| 2 — Scope | Capture goal — one question, three answers, plain language | Ask the goal |
| 3 — Skills | Run the matching skills, surface progress | Scan in progress |
| 4 — Report | Build the consolidated report — totals + per-section findings | Results summary + Findings |
| 5 — Present | Present results, offer remediation follow-ups | Next steps and guidance |
| 6 — Cleanup | Remove temporary files | (silent cleanup) |

### 1. Prerequisites

1. Use `Glob` to find `**/powerpages.config.json`. If none is found, tell the user the site needs to be created first with `/create-site`, then stop.
2. For `monitor` and `release` goals, confirm that `.powerpages-site/website.yml` exists. If it does not, tell the user the site needs to be deployed once before a live security review can run, recommend `/deploy-site`, then stop.
3. Create a fresh working directory: `<SYSTEM_TEMP>/security-review/`. If the folder already exists from a previous interrupted run, delete its contents before continuing.
4. Determine the docs output path: `<PROJECT_ROOT>/docs/security-review-<YYYY-MM-DD-HHMMSS>.html` using the local timestamp at the start of the run.

### 2. Capture Goal

Ask the user with a single `AskUserQuestion` call. If the user's initial request already answers it, skip and continue.

| Label | Description |
|-------|-------------|
| Code & config | Check source code, dependencies, authentication, web roles, and table permissions. Works on local files only. |
| Release readiness | Full review before publishing — checks everything. (Recommended) |
| Deployed site | Check the live site for issues. Requires deployment. |

Goal mapping:

| Label | Goal id | Skills |
|-------|---------|------------|
| Code & config | `code-config` | scan-code, audit-permissions, setup-auth (read-only) |
| Release readiness | `release` | scan-code, scan-site, manage-headers, manage-firewall, audit-permissions, setup-auth (read-only) |
| Deployed site | `monitor` | scan-site |

### 3. Run Skills

Run the matching skills based on the selected goal. Surface progress to the user.

### 4. Build Report

Build the consolidated HTML report with totals and per-section findings.

### 5. Present Findings

Present results to the user and offer remediation follow-ups.

### 6. Cleanup

Remove temporary files from the working directory.

## Mode 2: Source Code Vulnerability Review

Use when the user provides source code, a diff, or asks to find vulnerabilities, check for security issues, or perform an OWASP review.

### Scope: Research vs. Reporting

- **Report on**: Only the specific file, diff, or code provided by the user
- **Research**: The ENTIRE codebase to build confidence before reporting

Before flagging any issue, research the codebase to understand:
- Where does this input actually come from? (Trace data flow)
- Is there validation/sanitization elsewhere?
- How is this configured? (Check settings, config files, middleware)
- What framework protections exist?

Do NOT report issues based solely on pattern matching. Investigate first, then report only what you're confident is exploitable.

### Confidence Levels

| Level | Criteria | Action |
|-------|----------|--------|
| **HIGH** | Vulnerable pattern + attacker-controlled input confirmed | **Report** with severity |
| **MEDIUM** | Vulnerable pattern, input source unclear | **Note** as "Needs verification" |
| **LOW** | Theoretical, best practice, defense-in-depth | **Do not report** |

### Do Not Flag

- Test files (unless explicitly reviewing test security)
- Dead code, commented code, documentation strings
- Patterns using constants or server-controlled configuration
- Code paths that require prior authentication to reach (note the auth requirement instead)

### Server-Controlled Values (NOT Attacker-Controlled)

These are configured by operators, not controlled by attackers:

| Source | Example | Why It's Safe |
|--------|---------|---------------|
| Django settings | `settings.API_URL`, `settings.ALLOWED_HOSTS` | Set via config/env at deployment |
| Environment variables | `os.environ.get('DATABASE_URL')` | Deployment configuration |
| Config files | `config.yaml`, `app.config['KEY']` | Server-side files |
| Framework constants | `django.conf.settings.*` | Not user-modifiable |
| Hardcoded values | `BASE_URL = "https://api.internal"` | Compile-time constants |

### Framework-Mitigated Patterns

Check language guides before flagging. Common false positives:

| Pattern | Why It's Usually Safe |
|---------|----------------------|
| Django `{{ variable }}` | Auto-escaped by default |
| React `{variable}` | Auto-escaped by default |
| Vue `{{ variable }}` | Auto-escaped by default |
| `User.objects.filter(id=input)` | ORM parameterizes queries |
| `cursor.execute("...%s", (input,))` | Parameterized query |
| `innerHTML = "<b>Loading...</b>"` | Constant string, no user input |

Only flag these when:
- Django: `{{ var|safe }}`, `{% autoescape off %}`, `mark_safe(user_input)`
- React: `dangerouslySetInnerHTML={{__html: userInput}}`
- Vue: `v-html="userInput"`
- ORM: `.raw()`, `.extra()`, `RawSQL()` with string interpolation

### Review Process

1. **Detect Context**: Determine what type of code is being reviewed (API endpoints, frontend, file handling, crypto, etc.) and load the appropriate reference material.
2. **Load Language Guide**: Based on file extension or imports, load the relevant language-specific guide.
3. **Load Infrastructure Guide** (if applicable): For Docker, Kubernetes, Terraform, CI/CD, or cloud configs.
4. **Research Before Flagging**: For each potential issue, research the codebase to build confidence. Trace data flow, check for validation/sanitization, and identify framework protections.
5. **Verify Exploitability**: Confirm the input is attacker-controlled. Only report issues where you have HIGH confidence after understanding the broader context.

### Conflicts

- **microsoft/power-platform-skills** defines a multi-phase, sub-skill orchestration workflow for Power Pages sites that produces an HTML report.
- **getsentry/skills** defines a direct code-analysis workflow that applies OWASP heuristics to source code and reports findings with confidence levels.
- These are mutually exclusive procedures for different targets. The combined skill routes to the appropriate mode based on the user's target.