You can run a lightweight open source health check with standardized checklists at intake, automation where it helps, and short written notes for later reviews. The OSPO book describes a 2024 case with a large automotive company that built exactly this, starting from interviews rather than from a tool.
What the case describes
The OSPO book's metrics chapter includes a case study on how a global automotive company measures open source project health. It says researchers worked with the company in 2024 to create a simple and effective way to assess projects, tailored to the company's workflow.
They began by talking to employees through interviews and focus groups. From those insights they built a short questionnaire and a process that fits the company's environment. The chapter lists three key features of the result:
- Manual inspections at the intake stage using standardized checklists.
- Automated tool support used when helpful.
- Simple documentation of findings for future reviews, follow-ups and training.
The stated goal was to keep the process lightweight and efficient while still capturing important health risks. The chapter goes on to describe how the company monitors projects over time, so read it directly for those details.
What to copy
Start with the people who choose dependencies. The team did not start with a scoring tool. They asked employees how they actually evaluate projects. If you build a checklist nobody recognizes, it will be ignored.
Keep the questionnaire short. A form that takes five minutes gets filled in. One that takes an hour gets skipped.
Make the checklist standard. The same questions for every request make results comparable and reduce arguments about whether a review was fair.
Use tools for the lookups. Anything a tool can fetch, such as release dates or known vulnerabilities, should not be typed by a person. The OpenSSF guide for evaluating open source software mentions public sources such as deps.dev for scores and known vulnerabilities.
Write the finding down. The case calls for simple documentation. A two-line note per dependency, such as the date, the reviewer and the reason for approval, is enough to support later review and training.
A starter checklist
| Question | Source of the answer |
|---|---|
| Is it the authentic project, not a lookalike? | Reviewer, using the project site and registry |
| Recent releases and activity? | Tool |
| More than one maintainer? | Tool or reviewer |
| Known vulnerabilities in the current version? | Tool |
| Clear license? | Tool, then reviewer |
| Instructions for reporting vulnerabilities? | Reviewer |
| Strategic importance to us? | Requester |
Keep it living
A health check at intake is a snapshot. Add a periodic revisit for your most critical dependencies. See what to check before you depend on an open source security tool for a related checklist.
Try it yourself
Click through it at your own pace, or open it full screen. It shows how checks repeat over time instead of happening once at intake.
How Safeguard fits
Safeguard provides SBOM and dependency scanning and policies and gates, which can run the tool-based questions automatically. Try gold.safeguard.sh/scan.
Quick check
Do we need special software for a health check?
No. The case describes manual checklists supported by tools when helpful. Start with a shared checklist.
How detailed should the notes be?
Short. Date, reviewer, decision and reason are enough to support follow-ups and training.
Sources
- OSPO Book, Chapter 6: Using Metrics in your OSPO
- OpenSSF: Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
