Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Reporting and Disclosure

Author: Ryan Basden

Research decision and learning outcome

  • Decide whether the evidence supports a private report, requires more work or refutes the claim.
  • Produce a useful draft only when justified. A supported hold or rejection is a successful outcome.
  • Help a maintainer reproduce behavior, understand demonstrated impact and assess a fix.
  • An agent drafts; a human judges and sends. No exercise sends or publishes anything.

Credible baseline and controlled change

  • Baseline: an ordinary agent assessment and draft from the same complete fieldwork notes and source records.
  • Add the explicit readiness, verification and channel workflow—not extra evidence or withheld caveats.
  • Keep model, task, evidence access, permissions and budget the same. Submission tools remain unavailable in both conditions.
  • Use synthetic or reviewed public material, separate expected decisions, and fresh sessions. Do not use confidential client findings.

Demonstration outline

  • Predict report, hold or refute. Preserve the baseline decision and its evidence.
  • Repeat through the workflow below; inspect factual support rather than polish or length.
  • Change one material fact, then reassess whether a report is still justified.
  • This comparison is planned; no controlled workflow-benefit result is claimed.

1. Decide whether the evidence is ready

  • Confidence means how well the claim survives questions; severity means demonstrated impact.
  • High: mechanism/callers, reproduction/control, reachability and impact established.
  • Medium: solid reproduction with only a nonmaterial inference, stated clearly.
  • Blocked: a missing answer could change the claim; save the question and next step instead of a report.
  • Read full functions/callers; test a one-variable control. Record actual outcomes and attacker capabilities.
  • Name the expected objection and weakest link. Holds and refuted results are useful too.

2. Verify the current project and private route

  • Authorized live checks immediately before drafting: supported release, exact source, reproduction and realistic configuration.
  • Distinguish fork from upstream; do not invent affected ranges or patched versions.
  • Check duplicates, severity and proposed remediation.
  • Use upstream’s policy/required fields and confirmed private channel; a fork’s policy or signed-out redirect is insufficient.
  • No route/network access: hold and ask, not a public fallback or policy bypass.
  • Save dates/sources; completed checkboxes do not prove work occurred.

3. Collect the inputs

  • One target/finding, tested version, evidence, limits and observed impact.
  • Separate observed facts, inferences and unanswered questions.
  • Severity/vector or unscored reason; applicable CWE or a reason why none fits.
  • Operator-supplied identity/contact, policy, coordination window, credit and CVE stance; ask rather than invent.
  • Keep raw sensitive evidence private and review anything shared.

4. Draft for the actual channel

  • For an advisory form: separate local fenced fields for title, severity, weaknesses, affected versions, confirmed fixes/unknown and description.
  • Fences must contain any inner reproduction fences safely.
  • Description outline:
    • Affected version; who can do what to whom and under which conditions.
    • Source/callers and the failed boundary.
    • Reproduction, expected/actual outcomes and control.
    • Observed impact, preconditions, limits and weakest link.
    • Recovery if applicable; remediation options and what was actually tested.
    • Post-fix attack/control/legitimate-use checks.
    • Related advisory distinction if needed.
    • Supplied coordination, credit and CVE agreements.
  • Preserve material caveats and a protected limitation sentence.
  • No bundled independent findings; no renderer/submission tool supplied here.

5. Review, then let the human send

  • Removable sender notes: route/policy/date, evidence/release/lines, confidence, objections and severity alternatives.
  • Review actual evidence, attribution, impact, redaction and policy—not only a checklist or hash.
  • Human approval is not automatic submission; drafting agents get no send/publication tools.

Counterexamples and evaluation

  • Missing control: a plausible mechanism is not a complete reproduction.
  • Fixed current release: an old observation does not establish a current affected version.
  • Fork policy, unknown route, missing values or changed evidence: stop rather than invent support or use a public fallback.
  • Score readiness decisions, affected-version accuracy, reproduction/control detail, supported impact, redaction and a usable maintainer handoff.
  • Count unsupported claims and invented agreements as errors; do not reward a polished but unjustified report.
  • Record calls, elapsed time, available token/cache usage and human review effort. A short direct draft may be enough for a complete, simple case.
  • A larger workflow adds maintenance and can still miss a material assumption. Check actual evidence, not only its checklist.

Learner checkpoint and evidence still needed

  • Give an unfamiliar case a report/hold/refute decision, supporting evidence, a limitation and one next action.
  • Draft only if the case supports it. Explain which new fact would change a hold or rejection.
  • Further tests need authorization. Synthetic material is training-only / do not submit; offline examples are not live verification.
  • Verify expected decisions independently and preserve paired runs before claiming workflow or learner benefit.

Real follow-up stays human-owned

  • After an actual human send, record the supplied date/channel, agreed window, replies and next action privately.
  • Keep prior agreements. Draft creation starts no clock; window expiry does not trigger publication.