What do you check about an open-source library before adopting it in a production service?

## 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.