How do you run dependency-adoption vetting across hundreds of services without it becoming a rubber stamp?

## The failure mode you are being asked about Every organisation that grows past a few dozen services eventually installs a dependency-approval step, and most of them decay the same way: uniform scope, no risk tiering, one queue, one overloaded reviewer. Within a quarter the approval rate is effectively one hundred percent, the median review takes minutes, and nobody can name a dependency it ever stopped. At that point the gate is worse than nothing — it consumes delivery time and manufactures a paper record of diligence that did not happen. ## Tier by blast radius, not by novelty The fix is to stop pretending all dependencies are alike. **Tier one — everything.** Automated signals in the pull request: license compatibility, known-vulnerability status, whether the package resolves from where you expect, basic project-health signals. No human. This is the vast majority of adoptions and it should cost the engineer nothing. **Tier two — runs in production, or in the build with credentials.** A short written review attached to the change, done by the adopting team: how many people maintain it, whether patch fixes ship, is there a private disclosure path, how much of the library we actually use, what it can reach. Ten minutes, in the change itself, reviewable by the code owner. **Tier three — money, keys, customer data, or the build system itself.** A named reviewer from outside the adopting team, and a written decision record. This tier should be small enough that you can list it from memory. If it is not small, your tiering is wrong. Tiering makes the expensive review affordable precisely because it is rare. It also gives an honest answer to "this slows us down": for most changes it does not, and where it does, you can name the risk being bought down. ## Make the approval carry its assumptions An approval that records only *yes* is worthless a year later. Record: what was assessed, what was assumed, which compensating controls the decision depends on, and what would invalidate it — a change of maintainer, a transfer of the project, the library growing well beyond the job it was adopted for, a control it relied on being removed. Attach an owner and a revisit date. This is the difference between a decision you can re-evaluate and one you can only re-litigate. ## Decide the exit at the moment of adoption The most under-used practice here: at adoption, estimate what removing this package would cost in a year. Not to discourage adoption — to make lock-in visible while you still have leverage. Two useful outputs. First, a rough number: how many call sites, is the abstraction leaky, is there a plausible alternative. Second, a design decision: for tier-three dependencies, is it worth putting our own narrow interface in front of it so that replacement is a contained change rather than an estate-wide refactor? That second point is where an adoption review earns its cost. Wrapping every dependency is architectural over-engineering; wrapping the handful that hold keys, parse hostile input, or would take a quarter to remove is cheap insurance. The review is the only moment anyone will ever ask the question. ## Provide the alternative, not just the refusal A gate that only says no gets routed around — vendored copies, an inlined file, a transitive pull that nobody declared. Publish a pre-approved set for common needs so the fast path is also the safe path, and make the reviewer's job include naming a substitute. Adoption security is largely a paved-road problem. ## Measure the gate, or it will drift The metrics that matter are uncomfortable ones: - **Approval rate.** Near one hundred percent, with short review times, means the gate is decorative. Some genuine refusals should exist. - **Time to decision.** If tier two takes days, teams will pick the dependency that avoids review, and you have optimised for evasion. - **Coverage.** What fraction of dependencies actually entered the estate through the gate versus arriving transitively or by vendoring. - **Outcomes.** Dependencies that passed review and later caused an incident, and dependencies removed as a result of a review. Both numbers inform tiering. Counting reviews completed is not a measure of anything except how much time the process consumed. ## What a strong answer sounds like An interviewer at this level is checking whether you can build a control that survives contact with delivery pressure: proportional scope, cheap common path, expensive path reserved for real blast radius, decisions that carry assumptions and expiry, an exit recorded while it is still cheap, and honest metrics — including the willingness to remove the gate for a tier where it demonstrably buys nothing.