Approve at the version level for new or sensitive packages, and at a bounded range for trusted packages with a steady release record. Approving a bare package name means approving every future release, including one published after a maintainer change. Write the scope into the approval.
Three scopes compared
| Scope | What it covers | Strength | Weakness |
|---|---|---|---|
| Package name | Any version, now and later | Least admin work | Trusts future releases blindly |
| Exact version | One release | Most control, clear evidence | Every update needs a request |
| Bounded range | For example patch releases of one minor line | Balance of control and speed | Needs automated checks to stay safe |
How to choose
Ask three questions about the package:
- How much damage could it do if compromised? A build plugin or an authentication library is higher stakes than a date formatter.
- How stable is its release history and maintainer group?
- How much of the update work can your automated checks catch?
For high stakes packages, approve exact versions. For low stakes packages with a good record, a patch range with an automated gate is often enough. For everything else, start with exact versions and widen later when trust is earned.
Make the range enforceable
A range in an approval is meaningless unless something enforces it. Options include a mirror that only serves versions inside the approved range, a lockfile that pins exact versions inside the range, and a gate that fails a pull request outside it. Pair the range with a rule for new transitive packages, which a range does not cover. Our post on transitive dependencies policy goes into that.
Record the scope clearly
In the approved list, store these fields: package, ecosystem, approved version or range, purpose, approver, date and review date. If your list shows only a name, an auditor cannot tell what was actually approved.
When a range should end
Shrink or close a range when a maintainer changes, when a release breaks expectations, when a new advisory appears, or when the package is used in a new way. Re-approval for a new use is consistent with NIST SP 800-218 practice PW.4.1, whose example says to repeat review when a component is used in a substantially different way.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the versions in use with what you would want approved.
Quick check
Is a caret range in a manifest an approval range?
No. A manifest range says what the build may resolve. An approval range says what your organisation accepted. They should agree, but they are separate records.
Should patch updates need approval?
Within an approved range and with passing checks, many teams treat them as standard changes. Your policy decides.
Safeguard dependency scanning and policies can check versions against an approved scope. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
