Pimp My IDE / garage dispatch
Back to garage
October 1, 2026 | security intake / report quality / queue limits

Filter the report. Keep the receiver.

GitHub added structured forms and daily limits to private vulnerability reporting. The useful pattern is a two-part gate. Ask for evidence before intake, then protect the queue without cutting off the conversation already underway.

A report form improves the packet. A rate limit protects the queue. Neither one replaces acknowledgment, triage, ownership, or a containment route.

A blank box makes the maintainer do the parsing.

GitHub's private vulnerability reporting now starts with four required fields by default: summary, details, a proof of concept with at least 150 characters, and impact. Repository owners can replace that default with a .github/VULNERABILITY_REPORT.yml file that uses issue-form syntax. Custom fields can set a minimum length, and an invalid custom form falls back to the default form.[1]

This is useful friction. It asks the reporter to separate the claim, the reproducer, and the consequence before a maintainer opens the packet. GitHub also lets a repository require a CWE selection. A separate checkbox lets reporters disclose AI assistance.[1]

Make the report carry its own handles. Do not make the maintainer machine a handle out of prose.

The API has to obey the same door shape.

A custom form also applies to reports submitted through the REST API. GitHub says a mismatched API request receives an error that points to an endpoint describing the enforced form. The default form is not enforced for API submissions, which preserves existing integrations.[1]

That difference belongs in the runbook. A repository with the default form still has a looser machine route. A repository that needs the same fields from people and automation should commit a valid custom form and test one API rejection against it.

The queue valve is not a verdict.

GitHub also added daily per-user limits for new private vulnerability reports. Repository administrators can set a custom daily overall limit and allow trusted reporters to bypass limits. The limits apply to new reports. Comments on existing advisories remain available.[2]

That split matters. A queue limit says "not another new packet right now." It does not say that an existing report is false, resolved, or unwanted. Keeping comments open preserves the route for clarifying evidence after intake.

Do not use a trusted-reporter list as a quality score. It is a capacity exception. Review the report itself. Remove stale exceptions. Keep another published contact for cases where platform intake is unavailable.

Good intake still needs a person at the other end.

The earlier Vulnerability Receiver Test covers the rest of the route: a public contact, authorized scope, acknowledgment, ownership, and a bounded stop action. Structured fields improve what enters that route. Limits keep automation from burying it. The receiver still has to answer.

Test the whole path with a harmless sample. Submit through the browser and API. Confirm the required fields, invalid-form fallback, limit message, trusted exception, and existing-advisory comment lane. Then verify that a maintained queue receives the packet and that the published response expectation is honest.

Interactive makeover / report intake manifold

Press the packet before opening the valve.

Traditional purpose replaced: one free-text report box and an invisible queue limit. Better version: native field checks feed one visible form rail, queue pressure drives a separate valve, and the generated plan states what still needs live repository evidence.

Shape the intake packet

This teaching rig changes only the diagram and plan. It does not configure GitHub or submit a report.

Required report fields
Reporter route
Twin-gate cutaway

Form press / queue valve

Packet incomplete
Form press1 of 4 required fields is selected.
Queue valve2 new-report slots remain under this example limit.Existing advisory comments stay on a separate open lane.

Submission plan is incomplete.

Select all required fields before the report packet reaches the queue gate.

Four checks after the form ships

The interface is the first gate, not the program.

01 / SCHEMA

Can a reporter understand it?

Use plain field names. Ask for the minimum evidence needed to reproduce and assess the claim.

02 / AUTOMATION

Does the API match?

Commit a valid custom form when machine submissions need the same fields. Exercise one rejected request.

03 / CAPACITY

What happens at the limit?

Show the retry path. Keep trusted exceptions narrow and review them as access policy.

04 / RESPONSE

Who receives the packet?

Test acknowledgment, ownership, containment, and the fallback contact with a harmless sample.

Sources read

Source log and evidence boundary
  1. GitHub Changelog, "Structured forms for private vulnerability reports", published and read October 1, 2026. This is the first-party source for default fields, proof-of-concept length, custom form location, issue-form syntax, minimum lengths, invalid-form fallback, CWE requirements, AI disclosure, and REST API behavior.
  2. GitHub Changelog, "Rate limits for private vulnerability reports", published and read October 1, 2026. This is the first-party source for per-user daily limits, administrator-set overall limits, trusted-reporter exceptions, retry behavior, and the existing-advisory comment boundary.
  3. GitHub Docs, "Configuring private vulnerability reporting for a repository", read October 1, 2026. This is the product documentation route for repository configuration. The two release notes above contain the new behavior described in this dispatch.

Evidence boundary. Pimp My IDE did not enable private vulnerability reporting, submit a report, hit a live limit, or test a trusted-reporter exception. The manifold uses an illustrative limit of five to explain two independent gates. It is not GitHub telemetry or a recommendation for a universal limit. The generated text is a plan with required evidence fields.