Before adopting an open source component, check six things: why you need it, whether the license fits, whether it is maintained, whether it has known vulnerabilities, how you will verify its integrity, and which team will own it. Automate what you can and reserve human review for failures.
Why intake belongs in governance
Adoption is the cheapest moment to say no. CSF 2.0 outcome GV.SC-06 says planning and due diligence are performed to reduce risks before entering formal supplier or third-party relationships. SSDF practice PW.4.4 says acquired commercial, open source and other third-party components should be verified to comply with the organization's requirements throughout their life cycles. Its examples include checking for publicly known vulnerabilities, confirming a component is still actively maintained and not at end of life, planning for components that will no longer be maintained, and confirming integrity through digital signatures or other mechanisms.
The six checks
| Check | Question | Automatable? |
|---|---|---|
| Need | Does the standard library or an approved component already do this? | No |
| License | Is it on the allowed list, or does it need legal review? See license policy tiers | Yes |
| Maintenance | Recent releases, active maintainers, not marked end of life | Mostly |
| Known issues | Open advisories, and whether the affected code is reachable | Yes |
| Integrity | Source is the official registry, signatures or checksums verified | Mostly |
| Ownership | A named team will upgrade it and answer for it | No |
A decision flow
- Run the automated checks in the pull request.
- If all pass, the team proceeds. No ticket.
- If one fails, the team may fix it (pick another component, upgrade) or request review.
- The review group decides within a set time, and records the outcome.
This keeps the review group's workload small and focused on real judgment calls.
What to record
Keep a short entry per approved critical component: purpose, owner, license, date reviewed, and any conditions such as a required version range. For routine components, the inventory and the automated check results are enough.
Mistakes to avoid
- Reviewing just the top level package. A component's own dependencies come with it. See transitive dependencies policy.
- Checking once and never again. SSDF speaks of verification throughout life cycles, so re-check on update and on new advisories.
- Counting stars or downloads as a quality signal. They are popularity, not maintenance.
- Letting intake slow every developer down. If it takes a week, people will bypass it.
Try it yourself
Click through it at your own pace, or open it full screen. Watch which checks run on the pull request and what a failure looks like.
Safeguard's SBOM and dependency scanning, reachability analysis and policy gates can run these checks on each pull request, and a free scan shows the dependency picture of a project today.
Quick check
Do dev dependencies need intake?
Yes, with lighter checks. Build tools can be a path for tampering.
Who approves a license outside the allowed list?
Legal, usually through the review group.
Sources
Last reviewed: 19 October 2026.
