Vulnerability Disclosure Queue Overload

This applies The Natural Framework and The Parts Bin to vulnerability disclosure.

A vulnerability report creates verification work.

The recipient may need to identify the affected component, reconstruct the environment, run the reproducer, distinguish a bug from a security boundary violation, estimate impact, coordinate a fix, and decide what can be disclosed. Producing the report can be much cheaper than verifying it.

That asymmetry is not new. Generative models increase it. A model can produce a report that is specific, internally consistent, version-aware, and responsive to follow-up even when the vulnerability is not real. Polished prose is not evidence, but it can cause a report to pass initial screening and reach a specialist.

This creates a possible denial-of-service mechanism against human verification capacity.

The problem

A disclosure channel is an externally writable work queue. Its scarce resource is not inbox space but expert verification.

Report count is an incomplete load measure. Exact duplicates may be cheap, while one alleged race in a hardware-dependent subsystem may require a scarce specialist.

For report (i), let (p_i) be the probability that it requires investigation and (c_i) the expected expert time needed to reach a useful conclusion. Offered load is

[ L = \sum_i p_i c_i ]

and utilization is

[ \rho = \frac{L}{C} ]

where (C) is available verification capacity in the relevant interval. The relevant capacity is often not the intake team’s total headcount. It is the bottleneck specialist shared across maintainers, vendors, distributions, CNAs, and CERTs.

Below (\rho=1), ordinary review can keep up. Above it, backlog age increases. The system must allocate limited verification capacity.

High report volume is not required. A small number of reports can create overload if each is cheap to generate, expensive to falsify, and plausible enough to require investigation. More capable report generators can increase verification work per submission.

Persistent overload can also change disclosure policy. A project may tighten intake, give less attention to unknown reporters, or move coordination into private reputation networks. These changes may reduce access for legitimate reporters after the backlog clears.

“Security siege” is one possible description: the objective is to consume defensive capacity until access to the disclosure process is restricted.

The risk is likely to increase over time. Disclosure channels need to accept reports from unknown parties, and novel claims cannot be rejected by pattern matching alone. At the same time, the cost of generating coherent technical claims is falling as models improve at code analysis, tool use, and follow-up interaction. Triage responses can reveal acceptance criteria, while ordinary bounty incentives and automated scanning can produce similar load without malicious intent. Operational overload can therefore provide information useful to a later deliberate attempt.

This does not make a deliberate attack certain. It does make continued attacker disinterest an unsuitable control. An open channel through which untrusted input allocates scarce expert work should be treated as an attack surface.

Related work

The individual parts of this problem have prior work, although I have not found a disclosure-specific overload protocol that combines them.

• The CERT Guide to Coordinated Vulnerability Disclosure discusses report credibility, reporter reputation, reproduction difficulty, and the possibility that someone may submit reports to waste the recipient’s time.
• CERT/CC’s SSVC coordination model treats each report as a unit of coordination work and assigns outcomes such as decline, track, or coordinate. It provides prioritization semantics but does not define an overload state.
• The FIRST PSIRT Services Framework defines report intake, triage, analysis, prioritization, metrics, and response workflows. It supplies much of the organizational structure needed by the proposed pipe.
• Work on Informational Denial of Service and RADAMS models adversarial saturation of human attention in security operations. The input is a stream of alerts rather than vulnerability reports, but the resource constraint is similar.
• Current disclosure programs are implementing partial responses. GitHub reports that theoretical narratives and AI-generated filler increase triage cost. Bugcrowd uses a priority queue bypass for reporters with an established history.
• Research on adversarial bug reports examines realistic-looking reports designed to mislead automated program repair. That work targets the downstream repair system rather than human verification capacity, but it treats the report itself as adversarial input.

The contribution here is narrower than a new triage algorithm. It is the combination of disclosure-specific work amplification, overload activation and recovery, private conditional verification outcomes, dependency-aware cache invalidation, and protected review capacity for unknown reporters.

The strategy

Treat vulnerability disclosure as a congestion-controlled information pipe.

The pipe should make repeated and weakly evidenced claims cheap to process while preserving a route for surprising genuine findings. It has five forward operations and one learning operation:

[ \text{Perceive} \rightarrow \text{Cache} \rightarrow \text{Filter} \rightarrow \text{Attend} \rightarrow \text{Transmit} ]

[ \text{Consolidate}: \text{outcomes} \rightarrow \text{policy}’ ]

Calling the whole mechanism a filter hides the important distinctions. The Parts Bin gives each operation a separate contract:

• Perceive turns adversarial prose into explicit claims.
• Cache retrieves evidence from prior investigations.
• Filter applies cheap tests before expensive ones.
• Attend allocates a bounded and diverse slate of expert work.
• Transmit preserves what was known when a decision was made.
• Consolidate learns from outcomes, including items the current policy would not have selected.

Guarantees

The implementation can adapt to the host system, but it should preserve these properties:

• Evidence has precedence over presentation. An LLM may parse a report and propose tests, but strong cache entries require artifacts, deterministic checks, or accountable judgment.
• Reporter history affects scheduling rather than validity. An unknown reporter retains a path to expert review, including during overload.
• Similarity retrieval proposes related records. Approximate matching alone does not invalidate a report.
• Negative evidence remains conditional on versions, configuration, environment, and the security boundary being tested.
• Cache dependencies can be invalidated, and affected claims can be reconsidered.
• Validation state changes independently of publication state.
• Deferred reports are sampled so that the policy can detect blind spots created by its own selection.
• Decisions remain attributable to the evidence and policy available when they were made.
• Overload controls can be removed when load returns below capacity.

The success criterion is not a clean inbox. It is continued progress on genuine high-impact reports under saturation.

When to use it

Use congestion control when expected verification work persistently approaches or exceeds the capacity of the relevant specialists. Signals include:

• oldest-report age rising across several review intervals;
• critical-response objectives being missed;
• one subsystem queue growing while aggregate headcount appears adequate;
• verification time per report increasing;
• duplicates or generated reports consuming specialist review;
• staff abandoning remediation or incident response to maintain intake;
• a release, major disclosure, or incident producing a predictable surge.

The instrumentation should run during normal operation so baselines, service times, cache quality, and reporter histories exist before an incident. Consequential load shedding should activate progressively:

• Normal: use ordinary review and measure workload and outcomes.
• Pressure: enforce structured evidence, increase deduplication, and protect bottleneck specialists.
• Overload: schedule bounded diverse slates, batch related claims, rate-limit identities, retain unknown-reporter exploration, and hold reserve capacity.
• Recovery: drain deferred work, sample cache-assisted dismissals, audit delayed reports, and relax controls with hysteresis.

The playbook should be exercised in a closed replay before it is needed. Include polished false reports, badly written genuine reports, duplicates, specialist bottlenecks, and a real critical finding hidden inside the surge. Do not test the idea by sending synthetic reports into a live project; that performs the harm the exercise is supposed to prevent.

When not to use it

• Do not deploy the full protocol for ordinary triage inconvenience. Below capacity, direct human review is simpler and less likely to exclude an unusual report.
• Do not use inbox size as the performance target. It rewards premature closure.
• Do not use reporter reputation as admission control, an LLM score as a validity verdict, or semantic similarity as grounds for rejection. These make the system dependent on prior status rather than current evidence.
• Do not share the full verification-outcome cache publicly. It can contain embargoed claims, internal configurations, source locations, defensive assumptions, and information useful for adapting reports to the triage policy. Share narrowly scoped signed assertions with trusted partners when appropriate.
• Do not learn only from completed high-priority reports. Selection bias can make the policy appear more accurate while reducing coverage.
• Do not keep overload mode active after pressure subsides. Temporary controls should not become the normal disclosure policy without separate review.
• Do not automate consequential dismissal of novel, high-impact claims. Difficult-to-reproduce reports can include races, hardware interactions, and distributed failures.

Reference implementation: algorithms and contracts

The implementation is a composition of known operations, not one triage model. The following table is a parts list rather than a required stack. An implementation can use mechanisms already present in the host system when they satisfy the same contracts.

The primary data object is a typed claim graph:

claim
├── product and component
├── versions and commits
├── required configuration
├── attacker capability
├── action sequence
├── expected observation
├── claimed boundary crossed
├── claimed consequence
└── evidence artifacts

The LLM is useful as a parser because fluent paraphrases then collapse to comparable structures. Report text remains untrusted data. The model emits a constrained object with spans back to the source; files, commits, logs, containers, and reproducers receive exact hashes.

One reference design gives the private evidence cache an exact primary key:

[ K=(\text{product},\text{commit},\text{configuration}, \text{preconditions},\text{boundary},\text{reproducer hash}) ]

The cache should preserve the distinction among verification outcomes:

All six outcomes are useful cache records. Only Invalid directly supports a negative assertion, and that assertion remains scoped to the conditions under which the contradiction was observed.

An embedding index retrieves possible analogues. A structural matcher and the stored evidence determine whether the hit is strong, partial, or a miss. A Bloom filter is safe only as a front door to the exact store: a positive means “look this up,” never “discard it.”

Filtering then purchases certainty in increasing-cost layers:

schema complete
→ artifacts retrievable
→ environment constructible
→ behavior reproducible
→ boundary violation observable
→ consequence credible

Failure usually moves a report into a waiting state with a precise request for distinguishing evidence. “Not reproduced” does not silently become “false.”

Reports that survive are not collapsed into one score. Impact, evidence, reporter history, age, verification cost, and specialist scarcity are not naturally commensurate. Establish pairwise better/worse relations only where one report clearly dominates another, preserve the rest as a partial order, and choose the next bounded slate under explicit constraints:

• catastrophic consequence;
• machine-verifiable evidence;
• trusted active coordination;
• unknown reporters;
• distinct subsystems and specialists;
• random audit.

A heap remains useful for deadlines inside a lane. It should not define the global truth hierarchy.

Reporter history can be represented as a decayed, subsystem-specific distribution. A beta-binomial posterior is one candidate for confirmed versus unsupported reports, provided unresolved reports are not counted as failures. Routing can use a conservative confidence bound. It should not use the posterior mean as a validity verdict.

Validation state and publication state remain independent:

unreviewed → investigating → validated | invalidated | unresolved

private → coordinated → scheduled → published

Store every transition in an append-only log. Materialized views answer the current status; the log answers what evidence existed under which conditions when the decision was made.

Cache busting

A negative assertion should name all the conditions that justified it:

assertion
├── tested commits
├── configuration fingerprint
├── compiler and dependencies
├── hardware or topology
├── boundary definition
├── reproduction evidence
└── confidence and expiry

When one changes, the reverse dependency graph finds affected assertions. Justification-based truth maintenance then supports three operations:

• Bust: the old evidence no longer applies; investigate from scratch.
• Downgrade: the old work remains informative but cannot justify dismissal.
• Revalidate: replay the stored tests in the new environment.

The bust event propagates independently of a public notice. It invalidates the private assertion, requeues affected claims, and informs authorized consumers. Frequently matched negative entries need scheduled revalidation because an incorrect entry can affect many later reports.

Evaluation criterion

The system determines which reports wait for review. Its effects are therefore organizational as well as technical.

If trust becomes an admission requirement, established identities receive most capacity. If similarity is treated as validity, an incorrect cache entry can suppress later reports. If overload controls become permanent, unknown researchers may stop using the channel.

The primary evaluation criterion is whether genuine high-impact reports, including reports from unknown people, retain a path to expert attention during overload. Throughput and inbox size are secondary measures.