Systematic Attacking

Systematic Attacking

Overview

Offensive work fails in two characteristic ways: it strays outside authorized scope (the act of testing is itself potentially harmful), and it submits claims that were never really proven — reachability dressed as impact, a pile of lows dressed as a high, a known composite dressed as novel. This skill is the one method that blocks both failures.

This is the only offensive lifecycle skill. It alone owns scope, severity, lead→finding promotion, and submission authority. systematic-bug-hunting is a subordinate, zero-authority bench-craft layer nested inside Phases 2–5: it generates candidates, holds no scope or severity, and refuses to start without a Phase 0 scope lock. Experimental / novel-vector work is a phase inside it (Phase 3b), not a sibling skill — a second file would duplicate this safety lifecycle, and the looser copy would become the bypass path. systematic-debugging guards the fix; this skill guards the claim — and adds a scope law because attacking, unlike debugging, can hurt a real system.

Violating the letter of this process is violating the spirit of it. An empty gate is a skipped gate; a skipped gate is lab noise, not a finding.

When a packet contradicts this skill

Say so; do not resolve it silently. The dispatching packet still wins — that is the design. But if a packet instruction contradicts this skill, emit a ## PACKET OVERRODE SKILL section in your response naming both sides.

This is not hypothetical. H2 below states that a primitive carries capability, not severity, and that an inert primitive is labelled, never deleted. For five consecutive audits Chrono's Phase-3 packets instead demanded an impact-bar verdict per idea. Lanes obeyed the packet, killed their own primitives, and the Chaining phase starved for want of a pool — silently, because nothing made the contradiction visible.

No gate is added here. A reporting duty is enough: the failure was invisibility, not permissiveness.

The Two Iron Laws

Two co-equal laws. Neither is negotiable, and neither substitutes for the other.

IRON LAW 1 (safety): NO OFFENSIVE ACTION OUTSIDE AUTHORIZED, VERIFIED SCOPE.
IRON LAW 2 (rigor):  NO FINDING WITHOUT A REPRODUCED, NEGATIVE-CONTROLLED,
                     INTRINSIC-IMPACT PROOF.

• Law 1 is enforced at Phase 0 and is cross-cutting: an ambiguous scope STOPS; every hop stays inside the in-scope allowlist; a genuine refusal is terminal and is never re-shopped to a looser lane. Any live / mutating / credential-using action waits for the operator gate.
• Law 2 is enforced at Phases 5–6: a runnable PoC against the real oracle, causal negative controls at link and chain level, the G1–G4 impact bar, and a different-family reproduction — before anything is called a finding or scored.

Vocabulary — one definition, never redefined downstream

Every reference doc and specialist uses these words. Do not redefine "finding" anywhere.

Promotion points have one home: shared/modes/bounty.md § "Evidence vocabulary — the pipeline's type system". That mode is the promotion home — it owns when each token is promoted and what proof each transition demands (its state-token table and the Law 2 gate), and it already names this section as naming "the same offensive tokens." So the glosses below are denotational only; for a token's promotion point read the mode, not here — exactly as this skill already defers the phase list one section down. A restated criterion is what split candidate two ways; one home ends it.

• primitive — a bounded attacker capability or environmental fact (from a lead, a validated finding used as an inner link, public/known behavior, or config). Carries capability, not severity.
• lead — "there may be exploitable impact here." No CVSS, never submitted.
• candidate — a composed attempt under evaluation; the mode owns the bar it must clear.
• finding — the verified type. Only findings carry CVSS and may be submitted (this skill owns severity and submission authority; the mode owns the candidate→finding gate).

Finding definition (offensive-impact only, per operator): a proven, reproducible claim of intrinsic impact — loss of user/platform funds · RCE / attacker-controlled execution · direct damage to users or services · cross-tenant data compromise at material scale · privileged / control-plane takeover · a realized malicious capability. Reachability, disclosure, "could-lead-to" are NOT findings. They are, at most, leads.

The lifecycle — owned by the MODE, not by this skill

shared/modes/bounty.md owns the phase list. This skill previously restated Phases 0-8 verbatim, which made three documents claim authority over one process — and a restated process loses to whichever copy is most recent, which is always the packet. What follows is what this skill uniquely owns; for phase definitions, gates and owners, read the mode.

This skill's job is METHOD: how to discover primitives, how to compose them, and what evidence survives review. It is target-agnostic. Target-class specifics live in their own checklists (cross-chain-bridge-audit, cosmos-sdk-audit-checklist, solana-anchor-audit-checklist, known-advisory-backport-check); campaign process lives in the mode; this lane's task lives in the packet.

Phase numbering — read campaign phases from the mode; two other numberings are different objects

shared/modes/bounty.md owns the campaign phase list and is its only authority. Do not read a campaign phase number from this skill or from a specialist brief — read it from the mode. As of this writing the mode defines eight campaign phases, 0 through 7 (verify: grep -cE "^## Phase [0-9]" shared/modes/bounty.md returns 8). Phase 0 is ADMISSION — the campaign's entry gate and its stop condition. A mapping that starts the campaign at Phase 1 silently deletes ADMISSION, and that omission once let a campaign run 38 lanes. The eight headers, by name — for what each one does (its gate, owner, and procedure) read the mode; this is a locator, not a copy:

S0–S7 are NOT a parallel numbering of these campaign phases. They are a different object: a single lane's internal verification-contract stages (required_phase_ids in a task packet, enforced by scripts/python/verification_contract.py) — one lane proving its own claim, not the cross-lane campaign. The mode says so directly, in Phase 5:

"A lane's own S5. The verification contract makes every lane run an internal S0-S7 and owes poc_reproduction before it may report a finding at all. That is the lane proving its own claim, and it is required. It is not campaign Phase 5, which is a cross-lane re-verification of whatever survived Phases 3 and 4."

So a lane's S5 and campaign Phase 5 are not the same event. Lining S0–S7 up in a column beside the campaign phases is exactly what made "Phase 5" ambiguous; keep them apart.

This skill numbers its own method sections separately, and that numbering is not the campaign's. The Quick checklist, the safety-rail table, and the verification-contract binding below refer to Phases 0–8 — a finer-grained view of the method than the mode's eight campaign phases (for instance it splits the mode's single VERIFY phase into separate PoC, impact-bar, and skeptic stages). When this skill says "Phase 3" it means its own hunting stage; when the mode says "Phase 3" it means campaign HUNT. They are close but not guaranteed identical, so resolve any specific number against the mode rather than assuming a bare "Phase N" means the same stage in both.

When a packet and a document disagree on a phase number, the packet wins and you report the conflict. Do not silently renumber, and do not assume "Phase 3" in a brief means the same stage as "Phase 3" in the mode.