-
-
Notifications
You must be signed in to change notification settings - Fork 2
Feature Design Aware Impact Discipline
What it is. A block of instructions injected into every audit, validate, and corroborate prompt (deterministically, in code — not something a model can paraphrase away) that attacks the two hardest false-positive modes at the source, before a finding is even written.
Report proven impact, not reflexive escalation. Concretely: don't assert cloud-metadata/IMDS reachability for an SSRF finding without evidence that it's actually reachable; treat "an admin can do an admin thing" as by design, not a privilege-escalation finding. This came directly out of a real vendor reply where a webhook-SSRF-to-IMDS chain was reported as Critical/confirmed but had never actually been reproduced live — the vendor's platform didn't even expose IMDS. See the lesson in context: Docs & History Corroboration catches the same class of over-claim after the fact; this catches it before the finding is written.
A file recording the vendor's own intended/accepted-by-design behaviors (their threat model, known limitations) is injected downstream so those behaviors are never re-reported as bugs. Additive only — never inferred from the brief, so Argo doesn't guess at what's "probably fine".
The counterpart to impact discipline: a finding that defeats a security mechanism the project itself ships (auth, MAC, crypto, a security-relevant RNG, replay protection, access control) is rated by the property it breaks — it must not be downgraded to "informational hardening" just because exploitation needs on-path access or a partial trust model.
Severity symmetry is qualified by three priors, each traced to a specific disclosure lesson:
- Deprecated/legacy/vestigial mechanisms are low-value hardening notes, not vulnerabilities — a maintainer who says "that's an old remnant we intend to remove" doesn't want a CVE for it.
-
Purpose-is-the-feature — a component whose documented purpose is the flagged behavior (a
memory peek/poke primitive, an eval surface behind an intended privilege boundary) is by design.
A
peek/pokeprimitive doing exactly what its name says is not a bug. - Trusted-bus / embedded threat models — on firmware/bus/avionics/industrial protocols, the absence of authentication on management/command functions is typically intentional; lead with memory-safety/stability findings instead, since those hold regardless of trust model.
- Niche/opt-in component severity — a component being dev/test-only or uncommonly deployed answers whether to report a finding, not how severe it is once wire-reachability and impact are actually confirmed. "How commonly is this chosen" and "how bad is it once chosen" are different axes; conflating them under-rated a fully wire-reachable arbitrary-file-write finding to Medium purely because its transport was niche.
- Config/deserialization-to-exec is a finding, not by-design — the purpose-is-the-feature carve-out covers only an operator directly invoking an exec/command/eval feature through its intended channel. It does not cover the same capability reached silently via a data artifact the design never implies is executable (a shareable recipe/config/template, or a deserialized saved-state file that reconstructs the feature). Loading a shareable recipe that silently runs a command is a real trust-boundary crossing, not "the tool runs commands anyway".
Every one of these priors exists because a real disclosure landed wrong — either over-claimed (pushed back by a vendor) or under-claimed (caught by an independent second-opinion audit). Baking them into a deterministically-injected block means every future audit benefits from a past calibration mistake, instead of relying on the model remembering a lesson from a different run.
- Archetype-Driven Prompts — where this block is injected, alongside the coverage checklist and variant census.
- Docs & History Corroboration — the after-the-fact, networked counterpart for already-fixed / documented-by-design findings.