Your dependency policy rejects any library without an OpenSSF silver badge. How do you handle a rigorously run library that never applied?

## Why the gate is the wrong shape The policy treats a **voluntary, self-asserted, project-level** signal as a **mandatory, verified, artifact-level** control. Every problem below follows from that mismatch. ### It rejects good projects for reasons unrelated to quality A badge exists only if a maintainer chose to spend an afternoon on a questionnaire. Plenty of the most carefully run libraries in any ecosystem never did, because nobody asked and there was no incentive. Worse, the silver level includes criteria about **contributor independence** — at least two significant contributors not employed by the same organisation — which a one-author library cannot satisfy at any level of care. A gate at silver therefore systematically prefers larger, better-resourced, often corporate-adjacent projects, which is not the same thing as preferring safer ones. ### It accepts projects on the strength of stale prose An entry records when it was last updated, and nothing expires it. An entry completed once, years ago, by a contributor who has since moved on, displays exactly the badge that a diligently maintained current entry displays. If your policy reads the level and not the date, those two are indistinguishable to you. ### It confuses the level with the evidence The level is a rollup of answers that are individually far more informative than their sum. Which criteria were marked N/A and why; how the project describes its release process in prose; whether the justification links still resolve. A gate throws all of that away and keeps one word. ### The badge belongs to upstream, not to your copy A related trap: if your team hard-forks a badged library internally, **the fork inherits nothing**. The entry describes the upstream project's reporting channel, review practice and release process — none of which describe your fork. Citing the upstream badge in your own risk register turns the register into a false record, which is a worse outcome than an empty field, because the next reader believes it. ## What to do instead **1. Make the badge an input, not a decision.** The decision is "do we adopt this dependency, who owns that call, and what did we verify". A badge entry is one of the things that can inform it. An absent badge triggers *asking the underlying questions directly*, not rejection. **2. Read entries, don't count them.** Where an entry exists: check the last-updated date against the project's recent releases; read the justifications for anything that matters to you; treat an entry untouched across several releases as unverified rather than met. This costs minutes and is the whole value of the programme. **3. Handle the never-applied case explicitly.** For the rigorously run library in the question, the correct output is a short written assessment: what you looked at, what you found, who signed it, when it should be revisited. That record is stronger evidence than any badge, because you produced it and you can defend it. **4. Give exceptions an expiry and an owner.** Blanket waivers rot. An exception with a date and a name forces a re-look and keeps the register honest. **5. Anticipate the workaround.** On an estate of hundreds of dependencies, a hard gate that blocks a library teams genuinely need does not stop adoption — it moves it somewhere you cannot see: vendored source, a copied file, an internal fork nobody registered. Every one of those is worse than the dependency you rejected, because it is now unmonitored and unpatched. Design the policy so the compliant path is the easy path. **6. Be honest upward.** If a customer contract quotes badge levels for your dependencies, separate what you can prove from what you cannot compel. You control your own project's entry and your own verification records; you cannot make an upstream maintainer fill in a form. Offer the compensating evidence you do control — what you pin, what you verify, how you respond when something changes — rather than pretending upstream's paperwork is within your reach. ## The one-line position **Badges are evidence of engagement, not a licence to skip your own assessment.** A policy that gates on the level rewards form-filling, punishes small careful projects, and quietly converts blocked adoptions into invisible ones. A policy that requires a named owner, a written rationale, and re-examination on a cadence uses the badge for what it is actually good for — a cheap starting point — and keeps the accountability where it belongs, with you.