DEV Community: kotakanbe

A maintained package can still ship malware. What a health check can and can't see.

kotakanbe — Mon, 26 Oct 2026 02:39:49 +0000

On September 8, 2025, the maintainer of chalk and debug was phished, and malicious versions of those and other widely used npm packages were published from that account. The maintainer disclosed it within hours, and clean versions were out the same afternoon. chalk had shipped 5.6.0 three weeks earlier. By any maintenance measure, it was a maintained package.

uzomuzo, the dependency health checker I maintain, judges dependencies by exactly that kind of measure. Its job is to find dependencies with maintenance or lifecycle concerns. Until v0.6.0, uzomuzo scan pkg:npm/chalk@5.6.1 returned ✅ ok … Active. A hijacked release of a maintained package is the case that kind of check can't see.

This post covers the two things we added to narrow that gap, the numbers behind each decision, and what still gets through:

Malicious versions: read OSV's malicious-package records and stop the versions they name.
Before a record exists: for 7 days, mark a release that comes after a year of silence.

1. Stopping versions that OSV says are malicious

The OpenSSF malicious-packages project publishes records with IDs starting with MAL-, served through OSV. For a hijack, a record usually names the specific versions that were malicious; for a package that was malicious from the start, it covers every version.

Here's what uzomuzo v0.10.0 shows (output excerpt, October 26, 2026):

$ uzomuzo scan pkg:npm/chalk@5.6.1 pkg:npm/chalk@5.6.2 pkg:cargo/rustdecimal@1.23.1
STATUS     PURL                          LIFECYCLE                   BUILD
🔴 replace  pkg:npm/chalk@5.6.1           Active ☠ MAL-2025-46969     —
✅ ok       pkg:npm/chalk@5.6.2           Active                      Moderate 4.4
🔴 replace  pkg:cargo/rustdecimal@1.23.1  Review Needed ☠ MAL-2022-1  —

Three design choices are visible here.

The lifecycle label doesn't change. chalk is still Active, because it is. Whether a project is maintained and whether one of its versions is malicious are separate facts, so the malicious record sits next to the label (☠ MAL-…) instead of replacing it. Other tools that read the label keep working.

The match is by version. Chalk's record names 5.6.1, so 5.6.2, the clean release that followed, isn't affected by it. A flag on the whole package would push people away from the fix. (rustdecimal's record covers every version, because that package was malicious from the start.)

Any CI gate catches it. If --fail-on names anything at all, a matched malicious version fails the build. A pipeline that only ever wrote --fail-on eol-confirmed will stop on chalk@5.6.1 too:

$ uzomuzo scan pkg:npm/chalk@5.6.1 --fail-on eol-confirmed > /dev/null; echo $?
1

Two conditions apply. Without --fail-on, findings alone don't make uzomuzo exit with an error (command errors still do). And if the OSV lookup fails (no network, for example), uzomuzo warns that the check is incomplete; it doesn't fail the build on that alone.

No waiting period

uzomuzo already waits 14 days before acting on a RustSec "unmaintained" advisory, because those advisories are sometimes withdrawn and filed again. For malicious-package records there is no waiting period. Chalk's record was published about four hours after the malicious version (13:13 → 17:11 UTC, the same day). Waiting a few days before trusting such a record would let the version through during exactly the days it matters.

That has a cost, and we accepted it. In June 2024, MAL-2024-2929 named react@1.0.0 and react@35.0.0 as malicious. Those versions don't exist on npm, and the record was withdrawn about six days later as "False positive caused by problematic ingestion". Nobody's build could have broken on that one. But if a record like it named a version people actually use, our rule would fail every gate on that version until the record was withdrawn. The flag clears on the next run after a withdrawal; it doesn't undo a build that already failed.

What it misses

uzomuzo only acts on records that say, in a field a machine can read, that the code is malicious: a MAL- ID, or a GitHub advisory tagged CWE-506 ("embedded malicious code"). ctx 0.2.6 on PyPI was hijacked in 2022. Its advisories list the affected versions and describe the takeover in prose, but none carries that classification. We considered reading the prose and decided against it: in a CI gate, misreading free text is expensive.

2. Before a record exists

A record needs time to appear. We looked at npm records in the OpenSSF data (as of October 8, 2026) that name only some versions of a package, kept packages that had existed for at least a year with at least three normal releases before the malicious one, and treated those as takeovers. That left 1,556 packages.

For the 1,515 of them with a usable timestamp, the median time from the first malicious publish to the earliest timestamp in its record was about 6 hours. 89% were within a day, and 98% within 7 days. That timestamp approximates when the malware was found, not when OSV started serving the record.

Those figures are flattered by a few huge events. Most of the 1,556 packages belong to bulk account compromises, where one stolen account published to every package it owned and records came quickly (1,418 packages, 99% within 7 days). Outside those waves the tail is longer: of 97 packages, 86% had a record within 7 days, and 8% took more than 30 days.

So for hours, sometimes for weeks, a check that only reads records says nothing. Can anything be said in that window?

What these packages looked like before the attack

In 737 of the 1,556 packages (47%), the malicious version was the first release in more than a year.

That number needs three qualifications.

It's mostly a few events. 724 of the 737 come from 13 bulk account compromises — the Shai-Hulud waves, the September 2025 chalk/debug phishing, and others. Outside those waves, only 13 of 103 packages had been quiet for a year.
It doesn't show that attackers prefer quiet packages. On the dates of those waves, between about a quarter and a half (27–53%) of the same packages that hadn't been hit yet had also been quiet for a year. That fits bulk attacks publishing from accounts that already held many quiet packages; it says nothing about which packages attackers prefer across npm.
It compares different units. 47% is per hijacked package. Among the normal releases of the same packages, about 0.5% came after a year of silence (counting every release), or 6.8% if you look only at the last normal release before the attack.

What the numbers support is narrow: a release after a year of silence is uncommon among normal releases and common among these malicious ones. That makes it a reason to look at a release, not evidence of compromise.

The marker

So for npm packages, uzomuzo now marks a stable release that comes after at least a year without releases. Here's a benign release that triggered it. This is an excerpt from a v0.8.0 scan captured on October 15, 2026; the marker expired on October 18, so running the command today won't show it.

$ uzomuzo scan pkg:npm/dateformat@5.0.4
STATUS     PURL                      LIFECYCLE               BUILD
✅ ok       pkg:npm/dateformat@5.0.4  Active ⚠ 1695d silence  Moderate 5.0

The detailed view explains it:

⚠ Release after silence: This version came out 2026-10-11,
                         after 1695 days with no release.
                         Takeovers of npm packages that
                         had gone quiet looked like this,
                         and so does a maintainer who
                         ships again after a break. No OSV
                         malicious-package record names it
                         yet. Before using it, check who
                         published it (npm view
                         <package>@<version> _npmUser).
                         This marker clears on 2026-10-18.

The verdict stays ok. We did what the message says: npm view dateformat@5.0.4 _npmUser shows the same account that published 5.0.3 four years earlier, and 5.0.5 followed on October 24. That's what a project coming back after a break looks like.

The publisher check is a starting point, not proof. In a takeover the account name stays the same, and a legitimate handover changes it. Look at the release itself and at what the maintainers have said, too.

The marker covers the first release after the silence, plus anything published within a day of it, since a follow-up the next day comes from the same silence. dateformat@5.0.3, the release before the silence, has no marker.

Why 7 days

The marker is a bridge until a record can take over. Once an OSV record names the version, the first mechanism stops it, whatever its age.

Two packages from the same attack, with today's rules applied to the published timestamps. The marker only helps the one that had been quiet. So the question is: for takeovers that started with a release after a year of silence, how long did the record take?

The percentages above count packages, so a bulk wave of hundreds of packages counts hundreds of times. For choosing a marker period the right unit is the incident, so we counted again: incidents whose first malicious version came after a year of silence, a bulk wave counted once, timed from the first malicious publish to when the record entered the OpenSSF data. 27 incidents qualified: 20 that touched one release line (such as 5.x), and 7 that touched two or more at once. An incident qualified if at least one of its packages matched, and the earliest publish and the earliest record can belong to different packages. So these counts describe timing per incident, not a record for every affected version.

Marker kept for	One-line incidents with a record by then (of 20)	Multi-line incidents with a record by then (of 7)
1 day	11	6
3 days	13	7
7 days	16	7
14 days	17	7
365 days	19	7

One one-line incident has no import time; it stays in the count but never counts as recorded. The other three that took longer than 7 days took about 12.6, 57 and 310 days.

Going from 7 to 14 days would have added one incident. A year would have added three, and kept every ordinary return from a break flagged for a year. So 7 days is a policy whose window held a record for 16 of the 20 one-line incidents and all 7 multi-line ones we've seen so far. It isn't proof that 7 days will be enough next time, and when the marker expires, that says nothing about whether the release is safe.

This incident count is a separate selection from the package counts above. It was made outside the uzomuzo repository: the design record publishes the results and limitations, but not the full selection.

Why it doesn't fail CI by default

On the lockfiles of VS Code and the npm CLI, 186 of about 6,100 and 146 of about 2,600 stable releases in the year to October 2026 would have carried the marker. A team that adopts and scans every release within its first week could have run into all of them. None of them is known to be malicious.

So by default the marker only shows up in the output. To fail CI on it:

uzomuzo scan --sbom bom.json --show-transitive --fail-on dormant-release

One exception: when a quiet package returns with releases on two or more lines at once (as node-ipc did in May 2026, with three malicious versions in 55 seconds), an Active or Legacy-Safe label also becomes Review Needed for those 7 days, so an existing --fail-on review-needed gate fails too.

What it can't catch

Attacks on recently active packages. chalk itself had released three weeks earlier, so there was no silence to mark. A release cooldown can delay adopting such a version, and a matching record identifies it once one exists; neither guarantees it's caught in time. (Several other packages published from the same account that day had been quiet for years, and would have carried the marker.)
Patient attackers. An attacker who ends the silence with a harmless release, then publishes the malicious one more than a day later, walks past the marker.
Takeovers that never get a record. Some older incidents have only a GitHub advisory tagged as malicious code, which uzomuzo also reads. Some have nothing.

Turn on a release cooldown too

The marker can't help with the attack this post opened with. What would have helped is simply not taking a brand-new release. chalk@5.6.1 was gone from npm within about 2 hours 40 minutes, so a team that waited even one day before adopting new releases would never have installed it.

So, separately from uzomuzo, we recommend a release cooldown in whatever updates your dependencies. It doesn't detect anything; it just gives the ecosystem time to notice.

Dependabot (.github/dependabot.yml):

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3

Renovate (renovate.json):

{
  "minimumReleaseAge": "3 days"
}

pnpm (pnpm-workspace.yaml, in minutes; pnpm 11 waits one day by default):

minimumReleaseAge: 4320

Two caveats. Dependabot's cooldown applies to version updates, not security updates, so a fix for a known vulnerability still arrives right away; that's usually what you want. And a cooldown is a delay, not a guarantee: event-stream's malicious version went unnoticed for about 72 days.

The two work together. A cooldown holds back every new release for a few days. The marker picks out the small share of releases that end a long silence and asks you to look at them. The MAL record stops the version once someone has identified it.

In v0.10.0 we also added a quieter notice for any selected version that is 7 days old or less, in any ecosystem, when uzomuzo can find its publish time. It's always in the JSON output, and appears in the detailed view unless the release-after-silence marker or a malicious record already covers the version. It doesn't change the verdict or fail CI. It tells you that you're early, before records have had time to arrive.

Try it

go install github.com/future-architect/uzomuzo-oss/cmd/uzomuzo@v0.10.0   # or download a release binary
export GITHUB_TOKEN=...   # optional; adds commit history and repository signals

# One package
uzomuzo scan pkg:npm/chalk@5.6.1

# A whole project, via a CycloneDX SBOM
trivy fs . --format cyclonedx | uzomuzo scan --sbom - --show-transitive --fail-on malicious

Include --show-transitive. Without it, uzomuzo skips the dependencies your SBOM marks as transitive, and chalk and debug usually arrive as transitive ones. What gets checked also depends on what your SBOM contains.

The malicious-version check needs v0.6.0 or later, and the release-after-silence marker v0.7.0 or later. The design records behind this post are ADR-0027 and ADR-0028.

Earlier posts on uzomuzo: "Your dependencies are 48% unmaintained — and SCA tools can't see it" and "Your CI runs other people's code. Is anyone still maintaining it?"

Kota Kanbe — Creator of vuls, an open-source vulnerability scanner, and maintainer of uzomuzo.

We cut our scanner binary by 68% — and removing packages one by one wasn't how

kotakanbe — Mon, 26 Oct 2026 01:57:06 +0000

Finding unmaintained dependencies is the easy part. Removing them is where it gets hard.

This is the story of how we slimmed down vuls, the open-source vulnerability scanner I created — what didn't work, what did, and the tooling we built after doing it all by hand.

The easy win: 15 minutes

mitchellh/go-homedir has been archived for years. Vuls used it in a couple of lines in two source files:

- import "github.com/mitchellh/go-homedir"
- dir, err := homedir.Dir()
+ dir, err := os.UserHomeDir()

Fifteen minutes, start to finish. The standard library has done this since Go 1.12.

Trivy used the same package, so we sent them a similar fix. The Trivy maintainers reviewed and merged it within three weeks.

We felt good. Let's keep going.

The part where almost nothing happened

We kept going. Over two weeks we replaced 9 direct dependencies with standard-library code or a few lines of our own. go.mod went from 60 direct dependencies to 51.

Then we looked at what had actually left the build. go.sum went from 1,220 lines to about 1,210. Only 5 modules disappeared completely. Most of the packages we had stopped calling were still required by other modules, so they stayed in the dependency list anyway.

Adding a dependency takes one line. Removing one can take real work and barely change what you ship.

Just like a real diet.

What worked: removing a whole layer

So we stopped picking off packages one by one and looked at which layer they came in through.

Vuls uses Trivy's parsers to read lockfiles (package-lock.json, go.mod, Cargo.lock, and so on). We called them through fanal, Trivy's analysis framework. fanal is built for everything Trivy scans — container images, disk images, filesystems, infrastructure-as-code. That breadth is exactly what Trivy needs. Our scanner only needed the part that reads lockfiles, but the way we had wired fanal in registered 25+ analyzers through blank imports, and with them the infrastructure-as-code and misconfiguration packages that Trivy needs and we never called.

We changed Vuls to call Trivy's lockfile parsers directly. Much less code compiled in, and — as we checked below — the same results on almost every project we tested. (Vuls still depends on Trivy — we use its parsers, just not through fanal.)

The result (vuls PR #2476):

Metric	Before	After	Change
Scanner binary	106.6 MB	34.1 MB	-68%
Scanner build time	7.8 s	3.2 s	-59%

How we measured: scanner-only builds (-tags scanner) with our release build settings, CGO_ENABLED=0 GOEXPERIMENT=jsonv2 go build -a -trimpath -ldflags "-s -w". The build times are with a warm build cache.

To be precise about what shrank: this is the scanner binary. The full vuls binary, which also includes the vulnerability detection and reporting code, went from 139.1 MB to 138.5 MB after this change and a follow-up one. That code still uses Trivy's vulnerability database layer, so most of the weight stays.

Packages in the scanner build counted with go list -tags scanner -deps ./cmd/scanner before and after PR #2476.

Don't pick leaves one by one. Find the branch they hang from.

How we tested it

The change rewrote how the whole scanner package reads lockfiles. Here's how we checked it.

Layer 1: Golden tests. JSON output for 35 lockfile types, compared for an exact match.

Layer 2: A/B comparison on real projects. We collected real lockfiles from 129 open-source projects across 13 ecosystems. Then:

old code + lockfile → result A
new code + lockfile → result B
diff(A, B)

No mocks. No hand-written expected values. Just: "does the new code produce the same results as the old code?"

127 of 129 were identical. The other 2 differed only in the pnpm dev flag, which our old wrapper code had been losing along the way. Calling Trivy's pnpm parser directly gave us the parser's correct output.

Building the comparison set taught us something too. On the first pass, many fixtures produced zero packages — requirements.txt files with no pinned versions, a nearly empty yarn.lock, a root pom.xml with only <modules>. "Identical" on an empty result proves nothing, so we replaced those fixtures with ones that actually exercised the parsers.

This lives in vuls as make compare-lockfile. It didn't catch everything: code review and testing on Windows still found a case the comparison had missed (.exe files weren't detected as executables), which we fixed before merging.

The tool we built afterwards: `uzomuzo diet`

We did all of the above by hand, in March 2026. Looking back, the expensive part wasn't writing code. It was deciding where to start — and our first choice was wrong.

So in April we added a diet command to uzomuzo, our dependency lifecycle scanner. It ranks your direct dependencies as candidates for removal:

Dependency graph — from a CycloneDX SBOM: what would disappear along with each direct dependency?
Source coupling — tree-sitter reads your code: how many files import it, how many call sites?
Health — maintenance status (Active, Stalled, Archived, ...), from the same signals uzomuzo scan uses
Score — high impact, high risk, and easy to remove rises to the top

scan and diet are rule-based. No LLM is involved. Their results reflect the dependency and maintenance data available when you run them.

One caveat up front: diet is experimental. An audit against hand-checked expected values found cases where a dependency that is in use is reported as unused or trivial — for example when it's imported from a skipped directory or in an import style the analyzer doesn't recognize yet. The CLI prints a notice saying so after every run, and the Accuracy section of the docs lists what to check. Treat its output as a list of places to look, not a list of things to delete.

Here's an excerpt from a run on Terraform (commit 9ec49e0, October 13, 2026; SBOM generated with cyclonedx-gomod; run on October 26, 2026):

$ uzomuzo diet --sbom terraform-bom.json --source ./terraform

RANK  SCORE  EFFORT    PURL                          REMOVES  IMPORTS  CALLS  STATUS
3     0.13   trivial   github.com/mitchellh/gox            1        1      1  Archived
5     0.10   hard      github.com/mitchellh/colorstring    0       22     79  Archived
6     0.10   moderate  github.com/mitchellh/go-homedir     0        9     11  Archived
 ...
72    0.00   hard      github.com/hashicorp/hcl/v2         0      352   6764  Active

(Edited for width: four of the 77 direct dependencies, PURLs shortened to module paths, and the REMAINS column omitted. Ranks 1, 2 and 4 are not shown: 1 and 4 are Terraform's own nested internal/backend/remote-state/* modules, which the SBOM lists as direct dependencies, and 2 is an active OpenTelemetry package. The full run also reported zero "quick wins".)

The ranking is a starting point for investigation, not a verdict:

gox is archived and has one import and one call site, so it gets a trivial effort label. That's exactly the kind of label to verify: check that one call site, what it does, and what replaces it.
go-homedir is the same package we removed from vuls in 15 minutes. Here it's imported in 9 files, so it's rated moderate. Removing the direct use wouldn't drop it from Terraform's dependency list either — another module still requires it.
hcl/v2 is at rank 72: 352 importing files, 6,764 call sites, and actively maintained. Don't start here.

It works for Go, Python, JavaScript/TypeScript, and Java.

The last mile: Claude Code skills

Ranking is automated. Actually removing a dependency — tracing what data flows through it, writing the replacement, getting the change accepted — still takes judgment. uzomuzo ships three Claude Code skills for that part:

/diet-assess-risk (how risky is it to keep?), /diet-evaluate-removal (is it worth the effort?), and /diet-remove (draft the change or the upstream report). They use an LLM, so review what they propose before you use it.

The rules in /diet-remove come from our own mistakes. When we found that Next.js still depended on @vercel/kv, which Vercel has deprecated on npm in favor of Upstash Redis, we tried three channels by hand:

PR → we closed it ourselves after CI failed. It's a large pnpm-workspaces monorepo, and we couldn't reproduce its CI locally.
Issue → the repository's bot closed it within seconds, pointing to the bug report template. The issue tracker is for bugs with a reproduction, and ours wasn't one.
Discussion → the channel the repository's templates point to. It's still open with no reply yet.

So the skill now defaults to drafting an issue rather than a PR for projects you don't own, checks whether the repository accepts blank issues, and falls back to a Discussion when it doesn't. Those rules are written from that manual experience; we haven't yet published an end-to-end run of the skill itself. And getting the channel right doesn't guarantee a response. Of our four upstream reports in April, two have been fixed and two are still waiting. Whether to fix something is the maintainers' call.

Start your diet

go install github.com/future-architect/uzomuzo-oss/cmd/uzomuzo@latest
CGO_ENABLED=1 go install github.com/future-architect/uzomuzo-oss/cmd/uzomuzo-diet@latest   # needs a C compiler
export GITHUB_TOKEN=...   # read-only is enough; gives uzomuzo repository signals such as archived status

The output in this post was produced with v0.10.0.

Run uzomuzo scan --file go.mod (or pipe in an SBOM for other ecosystems). See what's unmaintained.
Generate a CycloneDX SBOM — for example trivy fs . --format cyclonedx -o bom.json, or for Go, cyclonedx-gomod mod -json -output bom.json — and run uzomuzo diet --sbom bom.json --source ..
Pick a dependency whose use and replacement you understand. Remove it, then measure: binary size, dependency list, build time. If nothing moved, look for the layer it came in through.

And don't give up on your diet.

Earlier posts: "Your dependencies are 48% unmaintained — and SCA tools can't see it" and "Your CI runs other people's code. Is anyone still maintaining it?"

Source and docs: github.com/future-architect/uzomuzo-oss (Apache 2.0)

Kota Kanbe — Creator of vuls, an open-source vulnerability scanner.

Your CI runs other people's code. Is anyone still maintaining it?

kotakanbe — Mon, 26 Oct 2026 01:54:49 +0000

Every third-party uses: line in a GitHub Actions workflow runs someone else's code in your job. Depending on the workflow, that code can reach your GITHUB_TOKEN, the secrets passed to that step, and your checked-out source.

In March 2025, the widely used tj-actions/changed-files Action was compromised: its tags were pointed at a malicious commit that printed CI secrets into workflow logs (CISA alert, CVE-2025-30066). That project was actively maintained — a maintenance check would not have prevented it — and a fixed release followed.

That last part is the point of this post. When something goes wrong in an Action that is still maintained, a fix comes out and you upgrade. When the Action is no longer maintained, there is no next release.

The question workflow scanners don't ask

There are good tools for securing your workflows:

Tool	What it checks
OpenSSF Scorecard	Your repo's practices: dangerous workflow patterns, token permissions, pinned dependencies
zizmor	Your workflow files: injection risks, `pull_request_target` misuse, and more
actionlint	Your workflow syntax and expressions

All three look at your workflow. Scorecard does have a Maintained check, and it gives an archived repository the lowest score — but only for the repository you run it on. Few teams run Scorecard against each of the 30-odd Actions their workflows reference.

Pinning Actions by commit SHA is good practice. It stops a tag from being silently repointed. But it doesn't tell you whether anyone will ship a fix for the code you pinned.

uzomuzo does that inventory for you: it reads your workflows, lists every Action they reference, and reports the maintenance status of each. It complements the tools above — it doesn't replace them.

What we found in Grafana (April 2026)

Grafana is one of the most popular open-source projects on GitHub. In April 2026 we scanned the Actions referenced in its workflows. One of them was archived: tibdex/github-app-token.

The repository was archived in July 2025 (its last push is July 7, 2025). Its README says the Action is deprecated and points to GitHub's official actions/create-github-app-token — the maintainer did exactly the right thing.
Grafana used it in 14 places across 13 workflow files, including release-build.yml and release-npm.yml.
It declares runs.using: node20. GitHub removed Node 20 from Actions runners on September 23, 2026, and an archived Action can't be updated to Node 24. Anyone still using it after that date has a broken workflow.

An Action runs in your job, with access to its workspace, not in an isolated sandbox. Depending on the workflow, it can reach GITHUB_TOKEN (with whatever permissions the job grants), the secrets passed to it, and the checked-out source. Release jobs often hold sensitive credentials. That doesn't mean anything was exposed here — it means an archived Action in a release job deserves a look.

What happened next

We filed an issue on April 5, 2026.

Grafana had already begun moving to actions/create-github-app-token in one workflow in October 2025. A community member opened a PR for the remaining files three days after our issue. A maintainer closed it, explaining that the team had a new recommended approach using their own internal workflow. We don't know whether our issue influenced their timing.

On September 15, 2026, the issue was closed as completed: "This has been done, we no longer use that action :)" — a week before Node 20 was removed.

When we scanned Grafana's workflows again on October 26, 2026, tibdex/github-app-token no longer appeared, and none of the 32 Actions was archived or got a replace verdict.

Reporting doesn't always lead to a fix. Of the four upstream reports we filed in April, two have been resolved and two have had no response yet. Whether and how to fix something is the maintainers' call. What a scanner can do is make sure the question gets asked.

Scan your own Actions

Install

go install github.com/future-architect/uzomuzo-oss/cmd/uzomuzo@latest

Or download a binary from GitHub Releases. You need v0.8.0 or later for --fail-on archived and the · archived marker. The examples below assume GITHUB_TOKEN is set: scanning a repository's Actions reads workflow files through the GitHub API, and the token also gives uzomuzo the repository signals (archived, commit history) it needs.

Check a repository

export GITHUB_TOKEN=...   # a read-only token is enough

# Actions referenced directly in your workflows
uzomuzo scan https://github.com/your-org/your-repo --include-actions

# Also include Actions used inside composite Actions
uzomuzo scan https://github.com/your-org/your-repo --include-actions --show-transitive

A composite Action can itself uses: other Actions. Those run in your job too. The difference is who can fix them: you can swap a direct Action today, but a transitive one needs the parent Action's maintainer to act.

You can also scan a single Action or workflow file:

uzomuzo scan https://github.com/tibdex/github-app-token
uzomuzo scan --file .github/workflows/ci.yml

What an archived Action looks like

$ uzomuzo scan https://github.com/tibdex/github-app-token https://github.com/actions/github-script
STATUS      PURL                                        LIFECYCLE           BUILD
🔴 replace  https://github.com/tibdex/github-app-token  Stalled · archived  —
⚠️ caution  https://github.com/actions/github-script    Stalled             —

Both Actions are Stalled: neither has had much recent activity. Only one is archived, and that's the one marked · archived and given a replace verdict.

The lifecycle label stays Stalled rather than EOL-Confirmed on purpose. uzomuzo uses EOL-Confirmed only for an explicit end-of-life signal, such as an npm deprecation or a Packagist "abandoned" flag. Archiving alone isn't one: some archived repositories are packages that moved to a monorepo and keep shipping releases from there. So the archive is shown as a separate fact next to the label instead. (tibdex's README does say "This action is deprecated", but uzomuzo deliberately doesn't treat README prose as a signal — free text is easy to misread.)

If you read the earlier post in this series: its table showed archived repositories as EOL-Confirmed. Current versions show them as above.

Gate your CI

uzomuzo scan https://github.com/your-org/your-repo --include-actions --fail-on archived

--fail-on archived fails the build when any referenced Action's repository is archived — and, like every --fail-on value, when a version is known to be malicious. It doesn't fire on Actions that are merely quiet. That matters: --fail-on stalled would also catch archived Actions, but in our October scan of Grafana it would have failed on four Actions that are simply less active, including actions/github-script. --fail-on eol-confirmed alone wouldn't fail on an archived Action at all.

Start with a report-only run, look at what comes back, then turn the gate on.

Run it on a schedule

The uzomuzo repository has a monthly workflow that generates an SBOM with aquasecurity/trivy-action, runs uzomuzo scan --sbom, and opens an issue with the results — SCA and lifecycle checks side by side. That workflow covers package dependencies, not Actions. To cover Actions as well, add a step that runs uzomuzo scan https://github.com/$GITHUB_REPOSITORY --include-actions --fail-on archived with GITHUB_TOKEN set.

Two layers, two questions

Scorecard, zizmor, and actionlint answer: "Is my workflow configured safely?"

uzomuzo answers: "Is the code my workflow runs still maintained?"

A safely configured workflow can still depend on an Action that will never get another release. That isn't a known vulnerability. It's something to review before it becomes a broken build — or worse.

Earlier post: "Your dependencies are 48% unmaintained — and SCA tools can't see it"

Source and docs: github.com/future-architect/uzomuzo-oss (Apache 2.0)

Kota Kanbe — Creator of vuls, an open-source vulnerability scanner.

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

kotakanbe — Thu, 16 Apr 2026 22:16:44 +0000

I just presented this at VulnCon 2026 (slides). 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.

Our team at FutureVuls analyzed 16,627 packages across 74 organizations running in production (published in Nikkei — 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.

(These figures come from the FutureVuls survey and its own classification rules. uzomuzo, introduced below, uses similar but not identical rules, so its numbers on the same data would differ.)

What does this look like in practice?

I scanned HashiCorp Vault — the tool you trust with your secrets. 209 dependencies.

$ 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." He archived 15 libraries at once, including copystructure.

Unlike mapstructure (which has a community fork), 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:

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 — 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	Registry EOL? (npm deprecated, PyPI inactive)	Yes → 🔴 EOL-Confirmed
2	Archived / Disabled repository?	Yes → 🟡 Stalled, marked `· archived` or `· disabled`
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

go install github.com/future-architect/uzomuzo-oss/cmd/uzomuzo@latest

Or download a binary from GitHub Releases.

Scan your project

# 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

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

By default, an SBOM scan skips the dependencies your SBOM marks as transitive, since direct dependencies are the ones you can replace yourself. To check transitive dependencies too, including malicious versions that arrive through them, add --show-transitive.

I used it on my own project

I ran uzomuzo on my own project — vuls, an open-source vulnerability scanner with 391 dependencies. Then I removed what I found.

Scanner binary size: 106.6 MB → 34.1 MB (-68%). I reported my findings upstream — Grafana's maintainer closed the community PR and committed to replacing the archived Action internally using their own shared-workflows, and finished the migration in September 2026.

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

30 seconds: uzomuzo scan --file go.mod or uzomuzo scan https://github.com/your/repo
5 minutes: Add --fail-on eol-confirmed to your CI pipeline
Quarterly: Run uzomuzo diet for a prioritized removal plan

You will be surprised what you find.

Updated October 26, 2026: corrected the survey size (74 organizations, 16,627 packages), clarified that the 68% reduction is for the scanner-only build, removed a dependency count we could not trace to a primary record, and updated the lifecycle table: current versions label an archived repository Stalled and mark it · archived, rather than EOL-Confirmed; and noted that SBOM scans skip transitive dependencies unless you add --show-transitive. The scan outputs above were captured in April 2026 with an earlier version.

⭐ github.com/future-architect/uzomuzo-oss — Apache 2.0

Kota Kanbe — Creator of vuls (12K+ ⭐), presented at VulnCon 2026

DEV Community: kotakanbe

A maintained package can still ship malware. What a health check can and can't see.

1. Stopping versions that OSV says are malicious

No waiting period

What it misses

2. Before a record exists

What these packages looked like before the attack

The marker

Why 7 days

Why it doesn't fail CI by default

What it can't catch

Turn on a release cooldown too

Try it

We cut our scanner binary by 68% — and removing packages one by one wasn't how

The easy win: 15 minutes

The part where almost nothing happened

What worked: removing a whole layer

How we tested it

The tool we built afterwards: uzomuzo diet

The last mile: Claude Code skills

Start your diet

Your CI runs other people's code. Is anyone still maintaining it?

The question workflow scanners don't ask

What we found in Grafana (April 2026)

What happened next

Scan your own Actions

Install

Check a repository

What an archived Action looks like

Gate your CI

Run it on a schedule

Two layers, two questions

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

The blind spot

What does this look like in practice?

The scary one: copystructure

From detection to analysis — with an LLM

How I built a tool to find this

What makes it different

Try it now (30 seconds)

Install

Scan your project

CI gate

I used it on my own project

The blind spot is bigger than you think

Start today

The tool we built afterwards: `uzomuzo diet`

The scary one: `copystructure`