proofline
TR

exploit-proof

Purpose

Defensive security review of a change in the user's own repository (working tree, branch or pull request) before merge.

Source Skill purpose

When to use it

Use exploit-proof for a defensive security review of changes in the user's own repository before merge. It follows untrusted input from changed entry points to sensitive sinks such as queries, shell calls, paths, HTML, outbound requests, deserialization and authorization. A candidate becomes a finding only after a concrete trace or a safe reproduction and an independent attempt to refute it. Dependency review compares the diff with the plan and uses the project's own audit output. Suspicions remain separate from confirmed vulnerabilities.

Source Skill purpose

How it works

Steps of the skill, in source orderEach numbered step follows the skill definition and links to its source.1. Resolve the targetFlow2. List entry pointsFlow3. Follow sensitive sinksFlow4. Trace candidatesFlow5. Reproduce safelyFlow6. Try to refuteFlow7. Report validated findingsFlow
Steps of the skill, in source order

Source Flow

  1. Resolve the target Record base and head revisions, changed lines and the working-tree state before reviewing.

    Source Flow

  2. List entry points Identify changed places that receive untrusted data and functions reachable from them.

    Source Flow

  3. Follow sensitive sinks Track each entry point to altered sensitive operations, checking safe forms before raising a candidate.

    Source Flow

  4. Trace candidates Follow a concrete input through each guard and source location; uncertainty makes it a suspicion.

    Source Flow

  5. Reproduce safely Use the project's tests in a throwaway worktree when a traced candidate can be exercised safely.

    Source Flow

  6. Try to refute Independently check guards, reachability and the reproduction before accepting a finding.

    Source Flow

  7. Report validated findings Validate the findings document and report confirmed vulnerabilities separately from suspicions.

    Source Flow

Key rules

  • Review only the named repository and target commits; never probe a deployed or third-party system.

    Source Safety rules (absolute; stricter than the shared rules)

  • Do not read or use real credentials; make fake values for evidence that needs them.

    Source Safety rules (absolute; stricter than the shared rules)

  • Keep the minimum evidence locally and never send reviewed data outside the machine.

    Source Safety rules (absolute; stricter than the shared rules)

  • Require a concrete trace or reproduction that survives refutation before reporting a finding.

    Source Evidence rules

  • Give every confirmed finding a severity and a concrete sentence about who can affect whose data.

    Source Evidence rules

Output and gate

Output

  • Write validated findings, a report, ledger and minimal evidence under the review output folder.

    Source Output

Gate

  • Any validated open security finding makes the review fail.

    Source Gate rule (SECURITY)

  • With no open finding, the validated security review passes; suspicions do not change the verdict.

    Source Gate rule (SECURITY)

  • An unresolved target, invalid report or missing required capability blocks the review.

    Source Gate rule (SECURITY)

Source

Source Skill definition

← All skills