They can do both. DORA's pervasive security page suggests that giving developers preapproved libraries and tools, shaped with input from the security team, standardizes code and makes review easier. A short, well kept approved list also removes a decision from developers, which saves time.
What DORA says
The page recommends developing security-approved tools: preapproved libraries and tools with InfoSec input help standardize developer code, make review easier, and let automated testing check that approved libraries are used. It also notes that this helps scale the security team's influence, since that team is usually understaffed compared with developers. As a measure, it suggests counting the number of approved libraries and toolchains available, or the number in use.
The page gives no figure for the size of the effect on that point, so treat it as reasoning, not a guaranteed gain.
What goes on an approved list
| Category | Examples of entries |
|---|---|
| Authentication and session | One vetted library per language |
| Cryptography | A standard library, with usage guidance |
| Input parsing and validation | A shared validator or schema tool |
| HTTP and web frameworks | The frameworks you maintain expertise in |
| Logging | A library that avoids logging secrets |
| Base images | A small set of maintained images |
Do not try to list everything. Cover the places where mistakes are costly, and let low-risk packages follow a lighter path.
How to build one
- Take an inventory of what your services already use. A dependency inventory shows you which packages are common.
- Pick the common, well maintained ones as the first entries.
- Record why each was approved, who owns it, and when it was last reviewed.
- Publish the list where developers already look, and give a fast path to request additions. A slow request path is how lists get ignored.
- Add an automated check that flags packages not on the list. Make it advisory first, then enforce for sensitive categories.
How to keep it useful
- Review each entry at least yearly, and when a serious advisory lands.
- Retire entries that are unmaintained.
- Publish upgrade guidance so teams stay on supported versions.
- Track request turnaround time. If it exceeds a few days, developers will work around the list.
What to measure
| Measure | Reading |
|---|---|
| Share of dependencies on the approved list | Should rise over time |
| Number of distinct libraries per category | Should fall, which means less to maintain |
| Request turnaround time | Should stay short |
| Advisories hitting approved versus unapproved packages | Shows whether the list helps |
Limits
An approved list is not a guarantee. Approved packages get vulnerabilities too, so keep scanning. And a list can lock in an old choice, so schedule review.
Quick check
Should the list be enforced or advisory?
Begin advisory so you learn what developers need, then enforce for sensitive categories such as cryptography and authentication.
Who owns the list?
Security and engineering together. A list owned only by security tends to be slow, and one owned only by engineering tends to drift.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the dependency inventory view. It is the starting point for deciding what belongs on an approved list.
How Safeguard fits
Safeguard offers SBOM and dependency scanning plus policies that can flag packages outside your standards. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, Pervasive security: https://dora.dev/capabilities/pervasive-security/
Last reviewed: 19 October 2026.
