Your dependencies are 48% unmaintained — and SCA tools can't see it

--- title: "Your dependencies are 48% unmaintained — and SCA tools can't see it" published: true description: "I analyzed 16,000 production packages. Half have lifecycle risk your scanner can't see. Here's uzomuzo — the open-source tool I built to find and fix it." cover_image: "https://dev-to-uploads.s3.amazonaws.com/uploads/articles/30j6dljugztycg0zn8ih.png" tags: security, opensource, supplychain, devops --- I just presented this at [VulnCon 2026](https://www.first.org/conference/vulncon26/program#pThe-CVE-Blind-Spot-Defeating-Hidden-EOLs-and-Repo-Jacking-with-Engineering-Triage-Code-Diet) ([slides](https://github.com/future-architect/uzomuzo-oss/blob/main/docs/presentations/vulncon2026.pdf)). Here's the tool and the data. --- ## The blind spot Your vulnerability scanner is excellent at finding CVEs. Trivy, Snyk, Grype — they do their job well. But there's a category of risk they **cannot see**: packages that are no longer maintained. No maintainer means no security patches. No bug fixes. No one watching. And because no one is looking — **no CVEs get filed**. Your scanner reports zero vulnerabilities, and you assume it's safe. **It's not safe. It's invisible.** I analyzed 16,000 packages across ~100 organizations running in production (published in [Nikkei](https://www.nikkei.com/article/DGXZQOUE066RT0W6A300C2000000/) — Japan's largest business newspaper — March 2026): | Status | % | Meaning | |---|---|---| | 🟢 Active | 40.6% | Someone is working on it | | 🔵 Legacy-Safe | 10.9% | Dormant but stable | | 🟡 **Stalled** | **34.6%** | Activity declining | | 🔴 **EOL** | **13.9%** | End of life | **48.5% of production dependencies have lifecycle risk.** Most of it is invisible. ## What does this look like in practice? I scanned [HashiCorp Vault](https://github.com/hashicorp/vault) — the tool you trust with your secrets. 209 dependencies. ```console $ uzomuzo scan --file vault-go.mod STATUS PURL LIFECYCLE ✅ ok cloud.google.com/go/storage@v1.56.1 Active ✅ ok Azure/azure-sdk-for-go/sdk/azcore Active 🔴 replace aws/aws-sdk-go@v1.55.8 EOL-Confirmed 🔴 replace mitchellh/copystructure@v1.2.0 EOL-Confirmed ... (209 deps total) ── Summary ────────────────────────────────── │ 209 deps | ✅ 186 ok | ⚠️ 11 caution | 🔴 11 replace ``` **11 packages are EOL.** In a secrets management tool. Most have **zero CVEs**. ### The scary one: `copystructure` Mitchell Hashimoto — Vault's creator — left HashiCorp in 2023. He publicly announced: ["I very rarely write Go anymore."](https://gist.github.com/mitchellh/90029601268e59a29e64e55bab1c5bdc) He archived 15 libraries at once, including `copystructure`. Unlike `mapstructure` (which has a [community fork](https://github.com/go-viper/mapstructure)), **copystructure has no successor**. Nobody picked it up. Where is it used? `vault/acl.go` — **the access control layer**. It deep-copies the deny rules for each security check. If this package were compromised — deny rules silently disappear. No error. No log. No crash. Your scanner will never find this because there is no CVE to find. **The risk is not a bug. It's being abandoned.** ### From detection to analysis — with an LLM Finding the EOL package is step one. But *what exactly happens if it's compromised?* I used an LLM to trace the data flow and build the attack scenario: ```plaintext mitchellh/copystructure — Risk: CRITICAL Lifecycle: Archived. Maintainer left HashiCorp in 2023. CVEs: 0 Data flow: IN: ACL DeniedParameters, MFA methods, ClientToken OUT: Deep-copied structs for per-request isolation Attack scenario: 1. acl.go: deny rules silently disappear 2. request.go: ClientToken shared across requests 3. policy.go: MFA bypass via shared ControlGroup → NO errors. NO logs. NO crashes. ``` **Verdict: CRITICAL.** Action: self-implement with ~100 lines of reflect-based code, replacing the ~500-line archived dependency. This analysis — tracing what data flows through a package, constructing attack scenarios, assessing severity — takes weeks to do manually across 209 dependencies. With uzomuzo + LLM, it takes minutes. I automated this as the `/diet-assess-risk` skill. ## How I built a tool to find this I built [**uzomuzo**](https://github.com/future-architect/uzomuzo-oss) — an open-source tool that detects unmaintained packages that SCA tools miss. The name comes from a Buddhist concept: *uzōmuzō* (有象無象) — "the visible and the invisible." That's exactly what your dependency tree is. ### What makes it different **1. Seven lifecycle stages, not binary.** Other tools give you "maintained or not." uzomuzo gives you a spectrum: | # | Signal | Result | |---|--------|--------| | 1 | Archived / Disabled? | **Yes →** 🔴 EOL-Confirmed | | 2 | Registry EOL? (npm deprecated, PyPI inactive) | **Yes →** 🔴 EOL-Confirmed | | 3 | EOL announced? | **Yes →** 🟠 EOL-Scheduled | | 4 | No recent human commits + HIGH/CRITICAL advisory? | ⚫ EOL-Effective | | | No recent human commits + LOW/MEDIUM advisory? | 🟡 Stalled | | | No recent human commits + no advisory? | 🔵 Legacy-Safe | | 5 | Recent human commits + recent publish or VCS-direct? | 🟢 Active | | | Recent human commits + no publish + low Scorecard? | 🟡 Stalled | Each check is evaluated **top to bottom** — first match wins. "Stalled" and "dead" require different responses. Stalled — you watch. EOL — you replace. **2. Multiple signal sources.** It combines data from deps.dev (Scorecard, releases, advisories), GitHub API (archive status, commit history), and registry heuristics (PyPI classifiers, npm deprecated flag, Packagist abandoned). The judgment is ecosystem-aware. Go delivers via git — commits *are* releases. npm requires a registry publish. Same commits, different verdict. **3. Two-axis evaluation: lifecycle × build integrity.** Lifecycle alone isn't enough. A package can be actively maintained but have no signed releases, no reproducible builds, no provenance. uzomuzo evaluates both axes — so you can distinguish "healthy and well-built" from "active but risky." **4. Not just detection — all the way to removal.** This is the big one. Every other tool stops at detection. Scorecard gives you a score. Trivy gives you a CVE. Then you're on your own. uzomuzo goes from **detect → prioritize → remove**: - `uzomuzo scan` — find EOL packages (every CI build) - `uzomuzo diet` — rank by removal priority: graph impact × health risk × coupling effort - `/diet-*` Claude Code skills — assess risk, evaluate removal, execute safely ## Try it now (30 seconds) ### Install ```bash go install github.com/future-architect/uzomuzo-oss/cmd/uzomuzo@latest ``` Or download a binary from [GitHub Releases](https://github.com/future-architect/uzomuzo-oss/releases). ### Scan your project ```bash # Go project uzomuzo scan --file go.mod # Any language (via SBOM) trivy fs . --format cyclonedx | uzomuzo scan --sbom - # GitHub Actions uzomuzo scan --file .github/workflows/ci.yml # Single package uzomuzo scan pkg:npm/express@4.18.2 ``` ### CI gate ```bash # Fail the build if any EOL dependency is found trivy fs . --format cyclonedx \ | uzomuzo scan --sbom - --fail-on eol-confirmed ``` That's it. One pipeline command. ## I used it on my own project I ran uzomuzo on my own project — [vuls](https://github.com/future-architect/vuls), an open-source vulnerability scanner with 391 dependencies. Then I removed what I found. Binary size: [106.6 MB → 34.1 MB (**-68%**)](https://github.com/future-architect/vuls/pull/2476). Dependencies: 352 → 144 (**-59%**). I reported my findings upstream — Grafana's maintainer [closed the community PR](https://github.com/grafana/grafana/pull/122122) and committed to replacing the archived Action internally using their own [shared-workflows](https://github.com/grafana/shared-workflows). The full story of how I did it — in a follow-up post. ## The blind spot is bigger than you think I cross-checked SCA results against lifecycle status on real-world projects. The overlap was almost zero — most EOL packages had no CVEs at all. They are completely invisible to SCA tools. "No CVE" doesn't mean "no vulnerability." It often means "no one is looking." Full methodology and data — in a follow-up post. ## Start today 1. **30 seconds:** `uzomuzo scan --file go.mod` or `uzomuzo scan https://github.com/your/repo` 2. **5 minutes:** Add `--fail-on eol-confirmed` to your CI pipeline 3. **Quarterly:** Run `uzomuzo diet` for a prioritized removal plan You will be surprised what you find. --- ⭐ [github.com/future-architect/uzomuzo-oss](https://github.com/future-architect/uzomuzo-oss) — Apache 2.0 *Kota Kanbe — Creator of [vuls](https://github.com/future-architect/vuls) (12K+ ⭐), presented at VulnCon 2026*