An intake form should ask for the package, current and target versions, the reason, affected services, reachability, test evidence, and a requested deadline. With those fields, the deciding team can act in one pass instead of five rounds of questions. Keep it to ten fields and a few minutes to complete.
Why bother with a form
Most disputes drag because the first message is vague: "we need to bump libfoo." The receiving team then asks which version, why, where, and how risky. Each question costs a day. A form moves that dialogue to the start.
It also makes requests comparable. When ten requests arrive in a month, the platform team can sort them by the same fields.
The fields
| Field | Why it matters |
|---|---|
| Package and ecosystem | Names the thing precisely, such as npm, Maven, pip, Go or Cargo |
| Current version(s) in use | Shows drift, since services may differ |
| Requested version | The target and why that one |
| Reason | Advisory ID, bug link, compatibility need, or end of support |
| Where it appears | List of services, and whether direct or transitive |
| Reachability | Is the vulnerable code called, yes, no or unknown |
| Change type | Patch, minor or major, using Semantic Versioning meaning |
| Evidence | Test run, branch, or sample pull request |
| Requested deadline and why | Separates urgent from preferred |
| Requester and sponsor | Who to contact and who backs the request |
Notes on the trickier fields
Where it appears. Ask for the path, not just the name. In Maven, the version chosen depends on the nearest definition in the tree, and in Gradle a constraint on a transitive dependency can affect what another library resolves. Knowing the path explains why a team sees a version they never chose.
Reachability. Accept "unknown" as an answer and treat it as a task, not a refusal. The deciding team can ask the requester or a tool to find out.
Change type. Semantic Versioning defines major as incompatible API changes, minor as backward compatible functionality, and patch as backward compatible bug fixes. Real projects do not always follow it, so treat the label as a hint, then rely on tests.
Deadline. Require a reason. "ASAP" with no reason lowers trust in the next urgent request.
What the deciding team does with it
- Acknowledge within one business day and confirm the decider.
- Complete triage: accept, request more information, or decline with reasons.
- Link accepted requests to a decision record.
- Close the loop with the requester, even when the answer is no.
Publish how long each of these steps should take, so requesters know what to expect and can see when the process is slipping.
Keep the form honest
- Do not make fields mandatory that the requester cannot know. Use "unknown" instead.
- Review the form after a quarter. Remove fields that nobody uses and add one that would have prevented a long thread.
- Make the form reachable from the places people hit the problem: the scanner output, the pull request template, the platform channel.
Quick check
Should security findings use the same form?
Yes for requests that need another team to act. Auto fill the fields from scan results where possible, so the reporter only adds context.
Is a ticket template enough?
Yes. A ticket template with these fields in your tracker is a form. Avoid building new tools until the process proves useful.
Sources
Last reviewed: 19 October 2026.
