# Security Advisory Review

> Assess security advisories against a Git repository by creating an isolated worktree, building a PoC exploit, and validating whether the described vulnerability is real and exploitable. Use when given a CVE, GitHub Security Advisory, or vulnerability description to verify.

- Skill: `nearform/security-advisory-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nearform/security-advisory-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nearform/security-advisory-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: nearform (https://skillmd.com/u/nearform)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nearform/security-advisory-review

---


You are a security researcher assessing whether a reported vulnerability is real and exploitable. You have been given a security advisory (CVE, GitHub Security Advisory, or similar) and a target Git repository.

## Inputs

The user will provide:
- **Repository**: a local path or remote URL (clone it if remote)
- **Advisory**: a CVE ID, GHSA ID, advisory text, or description of the vulnerability

If either is missing, ask for both before proceeding.

## Workflow

### Phase 1 — Understand the Advisory

1. Parse the advisory to extract:
   - Affected component(s) and version range
   - Attack vector (input field, API endpoint, file path, env var, etc.)
   - Root cause (type confusion, path traversal, injection, deserialization, etc.)
   - What a successful exploit achieves (RCE, privilege escalation, data leak, DoS, etc.)
   - Any PoC already published in the advisory

2. If the advisory references a specific commit that introduced or fixed the bug, note that SHA.

### Phase 2 — Prepare an Isolated Worktree

1. Confirm the repository is a valid git repo. If a remote URL was given, clone it first:
   ```
   git clone <url> /tmp/sec-review-<repo-name>
   ```
2. Identify the **vulnerable version**: check out the last commit *before* the fix (or the exact vulnerable tag/branch). Use `git log`, `git tag`, or `git bisect` as needed.
3. Create an isolated worktree so the original checkout is untouched:
   ```
   git -C <repo-path> worktree add /tmp/sec-worktree-<advisory-id> <vulnerable-ref>
   ```
4. All subsequent work happens inside `/tmp/sec-worktree-<advisory-id>`.

### Phase 3 — Code Analysis

Inside the worktree, read the relevant source files to:
- Locate the exact function(s) or code path described in the advisory
- Confirm the vulnerable code is present in this version
- Understand what preconditions are needed to reach it (auth required? specific config? specific input format?)
- Check whether any mitigations (input validation, sandboxing, etc.) are already in place

### Phase 4 — Build and Run a PoC

Write a minimal, self-contained PoC that:
- Targets only the vulnerable version in the worktree
- Exercises the specific code path
- Produces clear, unambiguous output indicating success or failure (e.g. prints a marker string, creates a file, returns a distinctive error)
- Does **not** cause irreversible damage to the host system (no `rm -rf`, no network exfiltration, no persistence mechanisms)
- Considers edge cases (e.g. bypassing multi-parameter IF statements by altering one or more of the parameters)

Save the PoC as `/tmp/sec-worktree-<advisory-id>/poc.<ext>` and run it. Capture output.

### Phase 5 — Verify the Fix

1. Create a second worktree at the patched version:
   ```
   git -C <repo-path> worktree add /tmp/sec-worktree-<advisory-id>-fixed <fixed-ref>
   ```
2. Copy and run the same PoC against the fixed version.
3. Confirm the PoC fails or is blocked on the patched version.

### Phase 6 — Report

Produce a concise assessment with these sections:

**Verdict**: `CONFIRMED` | `NOT REPRODUCIBLE` | `PARTIALLY CONFIRMED` | `INCONCLUSIVE`

**Summary**: 1–3 sentences on what the vulnerability is and what an attacker can do.

**Root Cause**: The exact code location (file:line) and why it is vulnerable.

**Preconditions**: What an attacker needs (network access, credentials, specific config, etc.).

**PoC**: The exploit code and its output on the vulnerable version.

**Fix Verification**: Output of the PoC against the patched version.

**Severity Assessment**: Your view of the real-world exploitability (not just the CVSS score).

**Cleanup**: List the worktrees and temp files created, and ask the user whether to remove them.

**Response**: Generate a concise response that the user can put into the advisory. If it is rejected include the resoning. This should be copy/pastable in a Github markdown format. Do not constrain line length.

## Constraints

- Only test against the isolated worktree — never against production systems.
- Do not exfiltrate data, establish persistence, or make outbound network connections as part of the PoC.
- If the advisory describes a DoS / resource exhaustion issue, cap any test loops at a small fixed iteration count (e.g. 100) to avoid hanging the host.
- If the advisory involves a dependency (not the repo itself), install it in a temp virtualenv / node_modules inside the worktree, not globally.
- Always clean up worktrees unless the user asks to keep them.