How we used a classifier to find the dependency packages you don't need

Supply chain risk sits near the top of most CISOs' priority lists. In the World Economic Forum's Global Cybersecurity Outlook 2026, 65% of large companies named third-party and supply chain weaknesses as their biggest challenge, up from 54% a year earlier. On 28 September, the UK's AI Security Institute published a test where GPT-6 Astra, running in a simulated environment with its safeguards off, launched supply chain attacks on its own. It created fake identities to fool developers, posted from fake accounts to argue against accurate security reviews, and delivered malicious payloads to open-source codebases.

Those attacks target open-source packages: ready-made code that engineers add to a product instead of writing it themselves. A typical product uses hundreds of packages, and engineers add more all the time. We call the result package sprawl: more packages than anyone on the team can keep track of.

You can't predict which package attackers will compromise next, but you can shrink what they have to work with. Every package you don't need is one more way in and one more thing for your team to patch. And a little-known package with a single maintainer is an easier target than the mature, widely used library that does the same job.

Most products carry more packages than they need: two libraries that do the same job, packages the language now handles by itself, and packages their maintainers have deprecated or archived.

We built Dependency Consolidation to find the packages you can cut, and to give your coding agent a prompt to swap or remove each one, so the cleanup doesn't turn into a project of its own.

It's free, needs no account, and never sees your source code. Here's how it works and why we built it the way we did.

A dependency tree with many roots

Packages bring packages. Add one for file uploads, date formatting or charts, and it installs packages of its own, which install theirs. A product that lists a few dozen packages often installs hundreds.

Every package is code that you didn't write, and if it contains a bug, so does your product. If its maintainer turns malicious or has their account taken over, the attacker's code is also running in your product. Log4j is the most famous case: a bug found in a logging library used by most of the internet sent the industry into a tailspin as security teams everywhere hustled to answer the question “are we exposed?”

Two files tell you exactly which packages your product uses.

The agents have taken over the dependency tree

AI is making package sprawl worse, mostly through speed. Coding agents write far more code than people do, and whenever a feature needs a capability, the agent pulls in a package for it so packages get added faster than anyone removes them.

AI also creates duplicates. Coding tools don't always check whether the project already has a package for the job, and in a big codebase where different people and different agents build different parts, you end up with two date libraries, two file upload libraries, and two HTTP clients. Depending on the prompt, an agent may also pick a little-known package over the mature standard. Fewer people watch a little-known package, so nobody may notice when its maintainer walks away or an attacker takes over their account.

What your packages do, and who stands behind them

Tools like Dependabot and Snyk answer one question well: does one of my packages have a known vulnerability? They don't tell you whether you need the package at all.

aisy's Dependency Consolidation does. It looks at what each package actually does and flags duplicates, so you can reduce sprawl. While a scanner runs version numbers against known bugs, we read what each package does and compare it with the rest of your tree. It's how we think about security in general: to make smart decisions, you have to understand how your systems really work.

aisy's Dependency Consolidation reads your dependency files and tells you which packages you could drop. aisy labels each public package by what it does, using Jev, a classifier model from TypeSafe, then applies its own rules to decide which labels count.

Knowing what a package does tells you which packages overlap. Knowing how mature each one is tells you how far to trust it. aisy researches every package a finding names: who publishes it and what else that account publishes, whether a company or a funding programme backs it, whether it has a security policy, its advisory history in OSV, how quickly past advisories got fixed, and whether any public report says it was compromised.

Part of that research happens on the open web. For each package behind a recommendation, aisy runs a search, digs further when the package is archived, deprecated or long unreleased, and reads the most relevant pages, starting with official and security sources. This includes logging incidents, such as a compromised release or a maintainer account takeover.

aisy also flags a new publisher, a licence change, a moved repository or a lapsed maintainer email domain. The report shows this research next to each finding, under Maintainers, Governance, and Security and integrity.

Why we used a classifier

Before we can tell you two packages do the same job, we have to know what every package does. That means labelling tens of thousands of packages, one small judgment at a time.

The usual move is to ask a large chat model. This job needs the same question answered the same way every time, so we used Jev, which TypeSafe calls a structured evaluation model. You give it some text and a set of typed questions, yes-or-no or pick-one, and it answers all of them in one call. Each answer is a probability, with no prose to parse. Jev costs about $0.04 per million input tokens and nothing for output, so labelling a package costs a fraction of a cent. aisy labels each package once and reuses the answers for every project that installs it.

Jev reads each package's registry description and README, then answers one question per area: is this package's main job HTTP and networking? Interface components? Testing? aisy uses 30 areas for npm and 31 for PyPI. Plenty of packages make HTTP requests, but few are HTTP clients. A chart library that fetches its own data is still a chart library, and a tool that filed it as a second HTTP client would tell you to delete your charts.

In the areas that score well, Jev answers the same question about specific features, out of 111 on npm and 143 on PyPI, and picks the one that is the package's main job.

Two packages in your project with the same main job are a possible overlap. aisy then checks whether one can replace the other. It rules out a pair where one package depends on the other, where one is a plugin for the other, or where the package you would keep lacks a feature the other has. Last, Jev answers two questions about the pair: would switching work, and would you lose something. Only a pair that passes every check becomes a removal recommendation. A close call comes back for you to review.

Most security decisions break down the same way: a run of narrow questions about evidence you already have. Does this package do the same job as that one? Would switching lose something? When each answer costs a fraction of a cent and comes with a probability, aisy can ask thousands of them, decide how sure an answer has to be before it acts, and bring the uncertain ones to a person.

How it works

1. 1

   Upload your manifest and lockfile

   For JavaScript and Python.

2. 2

   aisy builds the full tree

   It labels each package by what it does. It finds:

   • Packages that do the same job

   • Packages you list directly that are already installed through another package

   • Packages the language now covers natively without needing a package

   • Deprecated packages, and packages archived by their maintainers

   You get findings, each with a confidence level, evidence and an agent remediation prompt.

   High confidence

   Replace moment with dayjs

   Both packages parse, format and compare dates, and moment is in maintenance mode. Your agent checks that dayjs covers each use before it removes moment.

   REMOVE

   direct • moment@2.30.1

   KEEP

   direct • dayjs@1.11.13

   Fix with agent

3. 3

   Paste the prompt into your coding agent

   Paste the prompt into Claude Code, Cursor or whatever agent you use. The agent has your code, so it finds where each package is used, checks whether the swap is safe, and moves that code onto the package you keep.

aisy works before anything goes wrong. Every package you drop is one less thing that can be compromised.

Sounds great, how do I get started?

aisy's Dependency Consolidation doesn't need a complicated setup or an integration. You upload files, and the output goes into the coding agent you already use.

With fewer packages, your team has less to patch and the scanners you already run raise fewer alerts. Engineers benefit too. Smaller builds and faster installs make a security request feel less like a tax on their time, which helps the relationship between security and engineering.