An open source intake form should ask what the package is for, who owns it internally, which license and version it uses, how it will be deployed, and whether it handles sensitive data. Keep it under ten fields and answer within a promised time, or developers will skip it.
Why a short form wins
Every extra field lowers the number of people who complete it. If the form takes thirty minutes, teams add dependencies quietly and you lose visibility. The aim is to capture enough to sort the request into a tier, not to do the review inside the form.
Fill in what you can automatically. The package name and version can come from a link or a lockfile line. License and known vulnerability data can come from a scanner. Ask people only for what a tool cannot know.
Fields to include
| Field | Why it is there |
|---|---|
| Package name, version and source link | Identifies exactly what is requested |
| Requesting team and named owner | Someone must answer for upgrades |
| Purpose, in one sentence | Lets reviewers spot a duplicate of an approved package |
| Where it runs | Build tool, internal service, customer facing product, or shipped to customers |
| Data touched | None, internal, customer or regulated |
| Direct or transitive use | Direct choices need more care than inherited ones |
| License | Pre filled; reviewers confirm |
| Alternatives already approved | Prompts reuse |
| Needed by | Lets you set priority |
Fields to leave out
Skip anything a tool can fill: download counts, last release date, number of maintainers, open advisories. Show these to the reviewer, not the requester. Skip long free text questions about threat models, since most requesters will write filler.
What happens after submission
- An automatic check pulls license and vulnerability data and assigns a tier.
- Low tier requests with an approved license and no serious open advisories are approved on the spot.
- Middle tier goes to a named reviewer with a target response time.
- High tier, such as packages that run with high privilege, handle credentials or ship to customers, gets a deeper review.
- The decision, reason and owner are recorded and the package is added to the approved list with a review date.
Write down the answer time and measure it. A form with a slow response is worse than no form, because teams learn that asking costs time and not asking does not.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a new dependency in a pull request can trigger the same checks as the form.
Quick check
Should every package go through the form?
Only new packages. Version bumps of approved packages should pass automatically against policy.
Who should own the decision?
A named reviewer or a small group with a response time, not a committee that meets monthly.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
