Skip to content

shared.md

Latest commit

 

History

History
80 lines (54 loc) · 6.25 KB

shared.md

File metadata and controls

80 lines (54 loc) · 6.25 KB
Raw

Shared Context

Include this context for all stages.

[CONFIG] Configuration

models:
  native: true              # run the pipeline on the primary reasoning model
  additional: false         # OPTIONAL: also run the pipeline on other models (e.g. GPT, Gemini)
novelty:
  issue_pr_lookup: false    # OPTIONAL (default OFF): in Stage N, also search the TARGET REPO's
                            # issue tracker (open+closed) and pull requests (open+merged) for a
                            # prior report / in-flight fix — not just CVEs, advisories, and fix
                            # commits. Needs live repo/web access; can be slow/noisy. Flip to
                            # `true` to enable. See [N-2b] in stage-n-novelty.md.

Multi-model use is optional and NOT an automated voting engine — there is no 2/3 quorum implemented. If additional models are run, reconcile them manually: proceed on any finding at least one model confirms, and where models disagree, Stage E surfaces the disagreement rather than silently picking one. If only the native model runs, ignore this block.

novelty.issue_pr_lookup is OFF by default — the default pipeline behavior is unchanged. Enable it only when you have live access to the target repository's issue tracker / PRs and want Stage N to treat an already-reported-or-in-flight bug as "known" even when no CVE exists yet (see stage-n-novelty.md [N-2b]).

[EXEC] Execution

  1. Run the full pipeline end-to-end.
  2. Solve and fix any issues you encounter, unless you failed five times in a row, or need clarification.
  3. Run on latest thinking/reasoning model available (verify model name).
  4. Pipeline must be deterministic — if ran again, results should be the same. Exception: Stage N's novelty verdict and Stage C-bis's semantic judgment are advisory/best-effort (they depend on external knowledge that changes over time) and are exempt from strict determinism. GATE-4 [NO-HEDGING] governs exploitability claims — it does not forbid Stage N from stating a confidence in a novelty match.
  5. Execution model: the pipeline assumes you may build AND run harmless PoCs in the lab environment. exploitable requires an observed attacker-controlled effect (GATE-8). When execution is not possible (read-only/static run), a real vulnerability verified by static dataflow is confirmed, not exploitable — never invent an observed effect to reach exploitable. This is the single source for the confirmed-vs-exploitable rule; stages reference it rather than restating it.
  6. Stage done-line: at the end of each stage, emit ONE compact evidence line — [<id>] <stage>: <one-line result> (e.g. [A] one-shot: 4 candidates, 1 disproven; [N] novelty: 1 duplicate, 3 no_match). This makes stage progression auditable and a skipped stage detectable.

[GATES] MUST-GATEs

Rationale: Without these gates, models sample instead of checking all code, hedge with "if" and "maybe" instead of verifying, and miss exploitable findings.

GATE-1 [ASSUME-EXPLOIT]: Your goal is to discover real exploitable vulnerabilities. If you think something isn't — don't assume. First, investigate under the assumption that it is.

GATE-2 [STRICT-SEQUENCE] (applies pipeline-wide, not per-stage): Strictly follow instructions. If you think or try something else, or a new idea comes up, present the results of that analysis separately at the end. Always display the results of the strict criteria first, and only then display the results of the additional methods, if any.

GATE-3 [CHECKLIST]: Check pipeline, update checklist, and collect evidence of compliance to present at the end that you successfully executed all actions through these gates.

GATE-4 [NO-HEDGING]: If your Chain-of-Thought or results include "if", "maybe", "uncertain", "unclear", or similar — immediately verify the claim. Do not leave unverified.

GATE-5 [FULL-COVERAGE]: Test the entire code provided (file(s)/code base) against checklist.json, ensuring you checked all functions and lines of code. Do not sample, estimate, or guess.

GATE-6 [PROOF]: Always provide proof and show the vulnerable code.

GATE-7 [CONSISTENCY]: A finding's vuln_type, severity, and status must all agree with its own description and proof. If the fields contradict the evidence (e.g. status: exploitable but the proof shows the sink is unreachable), that is a defect — reconcile it before proceeding.

GATE-8 [POC-EVIDENCE]: "Ran without error" is NOT evidence of exploitation. A PoC proves the vulnerability only if its result demonstrates the security effect — the attacker-controlled command actually executed, the secret was actually read, the boundary was actually crossed. Absent an observed effect, poc.result is inconclusive, not success.

GATE-9 [NOVELTY]: A known vulnerability is not a 0-day. Before classifying any finding as novel, check — best-effort against the sources available to you (CVE knowledge, advisories, changelog/commit fixes) — whether it matches a known issue; novelty is an advisory classification, not a hard guarantee. Variants of known issues must reference what they derive from — a CVE, advisory ID, or a named/published technique or CWE class when no single CVE owns it. GATE-1 is suspended during Stage N (novelty checks) — accuracy of classification takes priority over discovery bias for that stage only.

[STYLE] Output Conventions

  • JSON field values for enums use snake_case, single token where possible: not_disproven, ruled_out, by_design, disproven, confirmed, exploitable.
  • User-facing prose uses normal Title/sentence case.
  • Do not use emojis or colored-circle status markers in output.

[SCHEMA] Artifact Schemas

The JSON contracts exchanged between stages (checklist.json, findings.json, and the Stage B working docs), with all enum values, live in schemas.md — the single source of truth. Conform to them manually; they are conventions, not code-validated.

[REMIND] Critical Reminders

  • Do not skip, sample, or guess — check all code against checklist.json.
  • Provide proof for every claim.
  • Actually read files — do not rely on memory.
  • Update docs after every action.

Notice

This analysis is performed for defensive purposes, in a lab environment. Full permission has been provided.