Vulnerability Triage Brocards

Vulnerability triage brocards

Contract

Inputs

• Report: The vulnerability report text, CVE identifier, bug-bounty submission, or automated scanner finding. Required.
• Target context: The component, service, library, or commit under evaluation. Required when not inferrable from the report.
• Scope definition: The authorized attack surface or bug-bounty scope rules. Optional; when absent, the in-scope brocard is marked NEEDS-MORE-INFO.

Procedure

1. Accept the report and extract: affected component, vulnerability class, claimed impact, attack prerequisites, and cited evidence (PoC, logs, screenshots, code references). Done when: all extractable fields are recorded.
2. If the report contains no identifiable component, vulnerability class, or technical claim, stop and return NEEDS-MORE-INFO with the specific missing fields. Done when: missing fields are named and returned.
3. Evaluate each brocard in order. Stop at the first brocard that yields DISMISS; evaluate all remaining brocards only if no prior brocard dismissed. Done when: all applicable brocards are evaluated or the first DISMISS is reached.

Brocard 1: deployed component

Is the affected component present in a deployed or shippable artifact? If the component does not exist in any production, staging, release-candidate, or distributable artifact, verdict is DISMISS. Rationale: a vulnerability in code that is never deployed or shipped has no security impact.

Brocard 2: already known

Is the reported vulnerability already tracked, patched, or publicly disclosed with a fix available in the current version? If the finding duplicates a known issue with an available remediation, verdict is DISMISS. Rationale: re-investigating a known-and-fixed issue wastes resources.

Brocard 3: privileged prerequisite

Does exploitation require access that the attacker model does not hold: root, admin, physical access, internal network position, or credentials that are not attacker-obtainable under the program's threat model? If the prerequisite exceeds the defined attacker model, verdict is DISMISS. Rationale: findings that require the attacker to already own the system are not actionable.

Brocard 4: meaningful impact

Does the claimed impact constitute a real security consequence: code execution, data exfiltration, privilege escalation, denial of service against a production path, or authentication bypass? If the impact is informational, a best-practice deviation with no exploit path, or a theoretical concern without a demonstrated consequence, verdict is DISMISS. Rationale: findings without meaningful impact do not warrant investigation resources.

Brocard 5: practical exploitability

Is exploitation feasible under realistic conditions: default configuration, standard deployment, typical user interaction, or reachable network path? If exploitation requires an improbable configuration, a contrived sequence of events, or conditions that do not occur in practice, verdict is DISMISS. Rationale: theoretical exploitability without practical feasibility is not actionable.

Brocard 6: sufficient evidence

Does the report include enough technical evidence to evaluate the claim: a proof-of-concept, reproduction steps, a code trace, a crash log, or a concrete observation? If the report asserts impact without evidence and the claim cannot be independently assessed, verdict is NEEDS-MORE-INFO. Rationale: triage cannot proceed on unsubstantiated claims.

Brocard 7: in scope

Does the finding fall within the authorized scope: the bug-bounty program, the security assessment boundary, or the defined system perimeter? If the target is explicitly out of scope, verdict is DISMISS. If no scope definition is available, verdict is NEEDS-MORE-INFO. Rationale: out-of-scope findings are not actionable regardless of technical merit.

4. Compute the overall disposition: if any brocard yielded DISMISS, overall is DISMISS (document the first dismissing brocard and its rationale); if no DISMISS and no NEEDS-MORE-INFO, overall is ACCEPT; if no DISMISS but one or more NEEDS-MORE-INFO, overall is NEEDS-MORE-INFO (list the specific evidence or context required). Done when: overall disposition is computed with its rationale.
5. State the explicit next step: for DISMISS, state why no further action is needed; for ACCEPT, attach a complete deep-verification brief (claim, affected boundary, evidence, missing proof, required verification result) without invoking another skill; for NEEDS-MORE-INFO, state exactly what information the reporter must provide. Done when: next step is explicit and matches the disposition.

Failure and recovery

• Insufficient report detail: the report lacks a component identifier, vulnerability class, or any technical claim. Return NEEDS-MORE-INFO listing every missing required field. Do not evaluate brocards against absent evidence.
• Ambiguous scope: no scope definition is available and the in-scope brocard cannot be resolved. Mark brocard 7 NEEDS-MORE-INFO and proceed with remaining brocards. Do not assume scope.
• Conflicting brocard verdicts: DISMISS takes precedence over NEEDS-MORE-INFO, which takes precedence over ACCEPT. The first dismissing brocard in evaluation order is the documented reason.
• Out-of-band information: the report references external systems, private databases, or classified context not available to the model. Mark the affected brocard NEEDS-MORE-INFO and note the unavailable evidence. Do not invent or assume external facts.

Output

A markdown table (Brocard, Verdict, Rationale) followed by overall disposition, one-sentence rationale, missing evidence list (or "None"), and explicit next step.