Before adding a dependency to a health app, ask what job it does, what data it will touch, whether it makes network calls, who maintains it, what it pulls in with it and how you will update it. If any answer is unknown, hold the merge. Seven short questions catch most problems.
Why intake matters more in health software
A library runs with your app's privileges. If it handles requests, it can see patient data. If it sends telemetry, it can send that data out. Healthtech teams also face buyer questions about third-party components, so an unrecorded dependency becomes a problem later.
Intake does not need a committee. It needs a short form and a rule: no new dependency merges without a filled form.
The seven questions
| # | Question | Why it matters |
|---|---|---|
| 1 | What does it do, and could we write the few lines ourselves? | Fewer dependencies, less exposure |
| 2 | Will it see patient data, credentials or request bodies? | Sets the review depth |
| 3 | Does it make outbound network calls or collect telemetry? | Data egress |
| 4 | Is it maintained: recent releases, several maintainers, a security policy? | Update and response risk |
| 5 | What does it bring in? List direct and transitive additions | Hidden surface |
| 6 | Does it run install scripts? | Code runs on build machines |
| 7 | How will we update it, and who owns it? | Prevents abandonment |
How to answer each one
Question 3 deserves a real test. Run the library in a sandbox with a proxy and watch for connections. Documentation sometimes omits default telemetry.
For question 5, compare the lockfile before and after. The npm documentation notes that npm ci installs strictly from the lockfile and errors if it does not match package.json, which makes lockfile diffs a reliable record of what changed. Use the same discipline for other ecosystems.
For question 6, npm documents an ignore-scripts setting that stops package scripts from running. Consider it in CI and review any package that needs install scripts.
Record the decision
Keep the form with the pull request. Include the date, the approver and the answers. When a buyer asks how you vet third-party components, you have a real record to show.
A short approval rule
- Low risk: a dev tool that never ships and never sees data. One reviewer.
- Medium: ships, but does not see patient data. Engineer plus tech lead.
- High: touches patient data or auth. Engineer, tech lead and privacy owner.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the inventory lists direct and transitive packages. That is the view you want for question 5.
Where Safeguard fits
Safeguard does SBOM and dependency scanning, reachability analysis and policy gates, so new packages can be checked against your rules before they merge. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do dev-only dependencies need intake?
Yes, a lighter version. They run on developer machines and build servers, which hold credentials.
Is a popular package safe to approve fast?
Popularity helps with maintenance signals but does not answer questions 2, 3 or 6.
Sources
Last reviewed: 19 October 2026.
