Skip to main content

Security Review Workflow

Use this workflow when you want an LLM to help summarize, reason about, or challenge a specific security review scope. PastePrompt prepares the context bundle. It does not decide whether a vulnerability exists.

Prepare the review scope​

Start by defining a narrow question. Good scopes include:

  • One module or subsystem.
  • A specific state transition.
  • A recent patch.
  • A set of externally callable entry points.
  • A suspicious integration boundary.
  • A finding candidate that needs focused review.

Avoid asking for a full audit of a large repository in one bundle. Large prompts usually make it harder to verify what the model is using and easier for it to produce speculative issues.

  1. Open the repository in PastePrompt.
  2. Select the primary implementation files for the behavior under review.
  3. Add interfaces, libraries, modifiers, hooks, or adapters that the primary files call.
  4. Add tests that document expected behavior.
  5. Add docs or specs only when they clarify intent.
  6. Add Git metadata when branch, commit, or dirty state matters.
  7. Exclude generated artifacts, vendored dependencies, mocks, fixtures, and unrelated modules unless they are directly relevant.
  8. Preview selected files before export.
  9. Check token estimates and split the bundle if it is too large.
Keep bundles question-shaped

For security work, a smaller bundle with precise instructions is usually more useful than a broad bundle with vague instructions.

Use a template that forces the model to separate evidence from hypotheses:

You are reviewing the selected code for security issues.

Scope:
- Review only the files and instructions in this bundle.
- Focus on concrete root causes visible in the selected code.
- Separate confirmed code facts, assumptions, and hypotheses.

Output:
- List high-confidence candidate issues first.
- For each issue, include affected files/functions, exploit or failure scenario, impact, likelihood, and recommended fix.
- Include "Needs more context" when the selected files are insufficient.
- Do not report generic best-practice comments unless they affect this code path.

Example user instructions​

Use instructions like this when you want severe issues only:

Focus only on high-confidence critical/high severity issues. Ignore style, gas-only comments, and speculative issues. For each candidate, cite the exact code path, explain the violated security property, and describe the minimum realistic preconditions. If the selected context is insufficient, say what file or behavior is missing instead of guessing.

Generate the bundle​

  1. Apply the security review template.
  2. Review the token budget.
  3. Run the secret scanner.
  4. Redact, exclude, or cancel if warnings are relevant.
  5. Copy XML-like context or export Markdown.
  6. Paste or attach the bundle in your chosen LLM tool.

Handle LLM findings​

Treat LLM output as triage material, not a finished finding.

  1. Verify manually: inspect the affected code yourself.
  2. Reproduce: write or run a local test, trace, or manual scenario when practical.
  3. Inspect affected code: include modifiers, inherited functions, external calls, tests, config, and deployment assumptions.
  4. Check exploitability: identify realistic actors, permissions, inputs, ordering, and state.
  5. Avoid speculative issues: do not accept issues that rely on missing code, generic patterns, or unsupported assumptions.
  6. Record gaps: if the bundle omitted required context, build a follow-up bundle instead of stretching the conclusion.
Model output is not evidence by itself

Do not report an issue as confirmed until you have code evidence and a plausible scenario. LLM output can help you find leads, but it cannot replace validation.