What do you check about an open-source library before adopting it in a production service?
answer
- who is on the other end
- count maintainers, not stars
- patch cadence, not feature cadence
- a private path to report a flaw
- scrutiny scales with blast radius
basics
~20 sCheck how many people really maintain it, whether releases and patch fixes still ship, whether it publishes a way to report a flaw privately, what the license is, how large the transitive tree is, and how much of it you actually need.
solid answer
~50 sI am asking two things: is anyone home, and how much does it matter here. For "is anyone home" I look at how many people hold merge and publish rights and how many actually commit — the bus factor — plus whether patch releases still ship, how quickly the last reported security issue was fixed, and whether there is a `SECURITY.md` or equivalent giving a private reporting path. I also read the license, the size of the transitive tree it drags in, and how much of the library we genuinely use. For "how much does it matter" I look at blast radius: a build-time formatter and a library that will handle production credentials do not deserve the same scrutiny. None of these signals prove the code is safe. They tell me how likely a problem is to be found and fixed, and by whom.
go deeper
Be ready to name concrete things you would look up — how many people maintain it, whether patch releases still ship, whether there is a private way to report a flaw, the license — and to say plainly that none of them prove the code is safe.
Explain what each signal measures underneath: bus factor versus raw contributor count, patch cadence versus feature cadence, and why download numbers mostly count automated builds rather than human review.
Show that you scale the review to what the dependency can reach, including build-time code that runs with pipeline credentials, and that the outcome is a written decision someone owns rather than a verbal yes.
Own the policy question: which classes of dependency require a human at all, what evidence you demand for the highest-impact ones, and what the review costs the organisation in delivery time versus the risk it actually removes.
## What adoption vetting is actually for Vetting before adoption is the one moment when a dependency is cheap to refuse. Once a library is in the tree it acquires callers, and the cost of removing it grows every sprint. So the review is not "is this code free of vulnerabilities" — nobody can answer that from the outside — but "if something goes wrong with this package, will it get fixed, by whom, and how badly does it hurt us?" ## The signals, and what each one actually measures **Bus factor.** The number of people who would have to disappear before the project stalls. This is not the same as the contributor count: a project can have two hundred contributors who each fixed a typo and one person who reviews and publishes everything. Look at who merges pull requests and who cuts releases over the last year. A bus factor of one is not disqualifying — enormous amounts of critical infrastructure run on it — but it tells you that a single person's availability, motivation or account is your availability, motivation and account. **Release and patch cadence.** Separate feature releases from patch releases. What you care about is whether a reported security flaw turns into a released fix, and how long that took the last time it happened. A project that ships features monthly but let an advisory sit unfixed for a year is worse than a quiet project that turned a report around in a week. **A published security policy.** A `SECURITY.md`, a disclosure address, or a documented reporting process tells you two things: someone has thought about receiving bad news, and you have somewhere to send it. Its absence means that when you find something, your options are a public issue tracker — which is a disclosure, not a report — or nothing. **License.** Not a security property, but it belongs in the same review because it is the other thing that is expensive to discover late, and because a license that forbids your use case forces a removal under time pressure. **Size and surface.** How many lines, how many transitive dependencies, and how much of it you use. A package you adopt for one function but which pulls in forty transitive packages has expanded your attack surface by forty, not by one. "Could we write the part we need?" is a legitimate question at this point. **Behaviour at install and build time.** Does the package run code during installation, or install a build plugin? That code runs on developer machines and on build runners, which typically hold more credentials than production does. ## Signals people over-trust Star counts and download numbers measure adoption, not review. Downloads are dominated by automated builds; a package can be pulled millions of times a week by machines and read by nobody. Popularity does help in one direction — a widely used package attracts more researchers, so flaws surface sooner — and hurts in another: it is worth more to an attacker. It never means "this has been audited". A clean scanner result is also not vetting. A vulnerability scanner tells you that no *published advisory* currently matches the version you resolved. It says nothing about the maintainer, the review process, or what happens next month. ## Scaling the review to the risk The decisive question is what the dependency can reach. A test-only assertion helper, a build-time formatter, a logging façade, and a library that will hold keys or parse untrusted input are four different risk classes and should get four different amounts of attention. "Dev-only" is not a free pass — build-time code runs with pipeline credentials — but the questions change: what it touches during the build and whether it executes install hooks, rather than its runtime attack surface. ## Writing the decision down A vetting decision that lives in someone's head expires silently. Record what you looked at, what you assumed, and what would change your mind — a change of maintainer, a transfer of ownership, the package growing well beyond the narrow job you adopted it for. That record is what makes the next person's review cheap instead of a repeat from scratch.
- The library has had no release in eleven months. Abandoned, or simply finished?Both are real, so I look for evidence rather than guessing. Are issues and pull requests being answered? Are there open advisories with no fix? Is the surface small and stable, or does it track something that moves — a protocol, a language runtime, a file format? A 300-line utility can genuinely be done. A parser, a crypto wrapper or a protocol client that has gone quiet is a liability, because the world it talks to keeps changing.
- Does a dev-only or build-time dependency get a lighter review?Not a lighter one, a different one. Build-time code runs on runners that usually hold registry credentials, signing keys and cloud tokens — often more privilege than the production service has. So instead of runtime attack surface I ask what it can reach during the build, whether it executes code at install time, and whether it can influence the artifact that gets published.
- The package has 30,000 stars and millions of weekly downloads. How much does that buy you?It buys attention, not assurance. Wide use means flaws tend to be found sooner and that fixes reach an ecosystem quickly, and it means peers have hit the same rough edges. It does not mean anyone has read the code, and it raises the package's value to an attacker. Download counts in particular are mostly automated builds pulling the same version repeatedly.
saying these in an interview costs you the question
- Says stars and download counts prove a library is safe
- Treats a clean scanner run as having vetted the dependency
- Checks only the license and calls security someone else's job
- Applies identical scrutiny regardless of what the code can reach
- Assumes no recent release automatically means abandoned
- Never asks how much of the library is actually used