A short register of rejected packages is worth keeping. It saves repeat reviews, shows an auditor that your approval gate does reject things, and preserves the reason so a later request is judged on new facts. Record the package, version, reason, decision date, owner and a revisit trigger.
What the register is for
Three uses justify the effort:
- Avoiding repeat work. The same package gets requested by different teams. A lookup beats a fresh review.
- Evidence. A control that never says no is hard to believe. A register with dated entries shows the control operates.
- Learning. Patterns in rejections reveal gaps, such as a missing approved option for a common need.
What to record
| Field | Notes |
|---|---|
| Package and ecosystem | Include the registry source |
| Version or range reviewed | Rejections are version specific |
| Reason category | Vulnerability, licence, maintenance, integrity, scope, other |
| Short rationale | One or two sentences, plain words |
| Evidence link | Scan output or ticket |
| Decision date and reviewer | Named person |
| Alternative offered | Link to approved option |
| Revisit trigger | For example a fixed release or a licence change |
Avoid putting accusations about maintainers or vendors in the register. Stick to observable facts such as an advisory identifier or a licence text. Keep the register internal.
Reasons to revisit a rejection
A rejection is not forever. Good triggers include:
- A new version fixes the advisory that caused the rejection.
- The licence changes.
- The requester describes a materially different use.
- A year passes and the package's maintenance picture has changed.
When you revisit, add a dated entry rather than editing the old one. History is the point.
Retention
Keep the register as long as you keep other approval records. Our post on how long to keep vulnerability records and change tickets discusses how to choose a period. Confirm with your compliance owner.
Connecting it to the gate
The best registers are consulted automatically. When a package on the register is requested again, the intake form shows the earlier decision and the alternative, and the reviewer decides whether the facts changed. For packages that were rejected for security reasons, the gate can block the specific version and point to the register entry.
Common mistakes
- Recording only approvals, so the gate looks like a rubber stamp.
- Leaving out the reason, which makes the entry useless.
- Never revisiting, which turns old rejections into folklore.
- Mixing rejections with exceptions. Keep exceptions in their own register, as in the patch exception register.
Quick check
Do we need to record rejected requests that were withdrawn?
Recording them is useful, marked as withdrawn, since the reason for withdrawal often reveals friction in the process.
Can the register be a spreadsheet?
Yes, if edits are logged and access is controlled. A ticket label or a table in your tracker often does the job better.
Safeguard policies and gates can block a specific package version once you decide to reject it. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
