An approved software list needs ten fields per entry: name, type, owner, purpose, allowed version or range, data it may touch, where it may run, approval date, next review date and conditions. The owner and the review date do the most work. A list without them decays into a rumor.
What an approved list is for
It answers one question quickly: may I use this? It also gives your searches something to compare against. Every discovery method in this series, from lockfile checks to webhook reviews, ends with "is it on the list?"
It is not a ranking of tools and it is not a purchase list. It records decisions.
The fields
| Field | What goes in it | Why |
|---|---|---|
| Name and type | Package, container image, SaaS tool, AI model, IDE extension, MCP server | Different types need different checks |
| Owner | A named person and team | Someone to call, and someone to ask about renewal |
| Purpose | One sentence on the job it does | Prevents duplicates and drift in use |
| Allowed version or range | Exact version, range, or "latest reviewed" | Approval attaches to a version, not a name |
| Data it may touch | Public, internal, confidential, regulated | Sets limits on where it can be used |
| Where it may run | Production, build, test, developer machines | Build tools and production code differ |
| Approved on | Date and approver | Evidence and audit trail |
| Next review | A date | Stops silent staleness |
| Conditions | For example "no secrets in prompts" or "pinned by digest" | Turns a yes into a safe yes |
| Exit plan | How to replace or remove it | Makes retirement possible |
For AI tools and models, add the provider terms you reviewed, whether the vendor may train on your inputs as stated in its terms, and the file format for model files. See a one page model intake record.
An example entry
- Name: an HTTP client library, version 4.x.
- Type: package, Python.
- Owner: platform team lead.
- Purpose: outbound calls from services.
- Allowed: any 4.x version, reviewed monthly for advisories.
- Data: internal and confidential, no regulated data.
- Runs: production and build.
- Approved on: a date, by the named reviewer.
- Next review: six months later.
- Conditions: use the shared wrapper, no custom TLS settings.
- Exit plan: wrapper allows swapping the library.
Keep it usable
A list nobody reads is a failed list. Three habits help:
- Make it searchable by name, and put it where developers already look.
- Let teams propose entries with a short form. See exception request template for an unapproved package.
- Review old entries on their dates. See keep an approved package list from going stale.
Keep one list with a type column rather than a separate list per team. A single source avoids contradictions.
Quick check
Should the list include transitive packages?
Usually not one by one. Approve direct packages and apply rules to transitive ones, such as advisory checks and license rules, then review the exceptions.
Who owns the list itself?
One accountable person, often in security or platform engineering, with engineering managers responsible for their own entries.
Safeguard offers policies, gates and guardrails, asset discovery, and a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
