The library our auth system depended on was archived on GitHub two years ago. We found out during a compliance audit.

Problem

We’d built session handling on top of a small, well-liked open source library. It worked, so nobody touched it. It also stopped being maintained two years before we noticed: no commits, no security patches, an “archived” banner sitting quietly at the top of a repo none of us had opened since the day we installed it.

We only found out because an auditor asked for our dependency maintenance policy, and someone actually went and checked.

Why it happens

Dependencies get evaluated once, at adoption time, and then trusted forever. There’s no event that tells you a library went quiet: no page, no alert, nothing breaks. It keeps compiling, keeps passing tests, keeps looking exactly as reliable as the day you added it, right up until it’s the reason you fail an audit or the reason a known CVE has no patch coming.

Better approach

Treat dependency health as something you check on a schedule, not something you assume. For anything security-sensitive (auth, crypto, payments), look at last-commit date and open-issue response time before adopting it, and re-check that a couple of times a year. Wrap critical dependencies behind your own thin interface so replacing one doesn’t mean rewriting every call site.

Example

An auth library with 2,000 GitHub stars and zero commits in 26 months. Still worked fine. Still had an open, unpatched vulnerability report sitting in its issues tab that nobody at the company had ever seen, because nobody was watching a repo they thought was finished.