Developers and approvals
Dry run a policy change
The fastest way to lose the room is a policy that breaks production on a Monday. Dry run shows what a change would break before anyone switches it on.
Pick a new rule (allow or deny, with versions and an application or environment), a vulnerability threshold for safe version resolution, or different license lists. The last 1 to 90 days of downloads are replayed against it, and the answer counts the packages, versions, applications, applications in production, developers, CI pipelines and downloads that would have been refused, or for an allow rule, let through, with a table of each.
Nothing is saved and nothing is enforced. Existing waivers are taken into account, and license changes only count files whose license has been read, so the answer is the one you would really get.
In short
- Rules, vulnerability thresholds and license lists
- 1 to 90 days of real downloads
- Counts per application, environment, developer and pipeline
- Production flagged
- Nothing saved, nothing enforced
In the documentation
- Dry run a change before you make it Administrator Guide
Goes well with
- Allow lists and block lists Whitelist or blacklist by name, scope, wildcard or version range, for every type. A blocked version is not even listed to the client.
- Safe version resolution Versions with serious advisories are left out, so a range quietly settles on the newest safe one.
- License policy Allowed, needs review and blocked SPDX lists, with holds that follow a license change.
One container, about two minutes
A Linux box with Docker, or one without it, and a reverse proxy for TLS. The installer does the rest and it is safe to run twice. Free, MIT licensed, nothing to sign up for.