unripe

unripe

unripe checks your lockfiles and fails if any dependency version was published too recently. The default is 3 days. It works across npm, pnpm, yarn, bun, Deno, PyPI, Cargo, Go, Composer, RubyGems, NuGet, Gradle, Dart and Flutter, CocoaPods, Swift, Terraform, Conan, R, Elixir, Nix, Bazel and vcpkg, and it can check the actions your GitHub workflows use too. A repo with a Python backend, a JavaScript frontend and a Flutter app gets one check and one policy instead of a different setting in every tool.

It runs in CI, as a pre-commit hook, from Python, and as an MCP server so AI coding agents check a version's age before they add it.

Here it is on a small test project with Deno, Python and PHP parts, the evening of October 21, 2026. uv add had just locked a certifi released two days earlier:

$ unripe check

unripe: checked 867 versions in 4 lockfiles, minimum age 3d

unripe: 2 versions published less than 3d ago composer laravel/framework 12.70.1 13h old, published 2026-10-21 12:55 UTC, old enough at 2026-10-24 12:55 UTC php/composer.lock:1 12.70.0 is old enough (published 2026-10-13) pypi certifi 2026.10.19 47h old, published 2026-10-20 02:24 UTC, old enough at 2026-10-23 02:24 UTC api/pylock.toml:8, api/uv.lock:6 2026.10.18 is old enough (published 2026-10-18)

fail: 2 unripe, 0 unknown, 865 ok, 0 excluded

Nothing is wrong with either of those. That's normal. Most new versions are fine. The point is that when one isn't, you find out after everyone else does, not before. And when one is too new, unripe tells you which older version would pass.

Why bother

When a popular package gets hijacked, the bad version is usually spotted and pulled within hours. In August 2026 a worm went through npm and published malicious versions of 444 packages in about four hours, stealing CI and cloud credentials from whoever installed them. In March, two backdoored LiteLLM releases sat on PyPI for somewhere between 40 minutes and three hours. Waiting a few days before taking a new version would have skipped both.

You can check that claim. Here is a lockfile with the debug and chalk versions from the September 2025 npm compromise, checked as of two hours after they went out:

$ unripe check --as-of 2025-09-08T15:00Z

unripe: checked 3 versions in 1 lockfile, minimum age 3d

unripe: 2 versions published less than 3d ago npm chalk 5.6.1 1h old, published 2025-09-08 13:13 UTC, old enough at 2025-09-11 13:13 UTC package-lock.json:3 5.6.0 is old enough (published 2025-08-17) npm debug 4.4.2 1h old, published 2025-09-08 13:12 UTC, old enough at 2025-09-11 13:12 UTC package-lock.json:2 4.4.1 is old enough (published 2025-05-13)

fail: 2 unripe, 0 unknown, 1 ok, 0 excluded

Run it today and both come back as unpublished, which is how npm takes malicious versions down, so a lockfile that still has one fails either way.

Most package managers have added a setting for this in the last year, and if yours has one you should turn it on. unripe is for what those settings don't do. It checks what is already in the lockfile, including whatever a bot, an agent or an old tool put there. It reports on just the versions a pull request adds. It applies one policy to every ecosystem in the repo. And it covers Go, NuGet, Gradle, Dart, CocoaPods, Swift, Terraform, Conan, R, Nix, Bazel, vcpkg and GitHub Actions, which don't have a setting yet.

docs/case-studies.md replays more incidents the same way, and docs/threat-model.md says plainly what a cooldown does not protect against.

Install

You need Python 3.11 or newer. unripe has no dependencies, on purpose: a tool that checks your supply chain shouldn't add to it.

uvx unripe check

or pipx install unripe, or pip install unripe. To start a config and a GitHub workflow in one go:

unripe init --github

unripe doctor checks the setup: which config and lockfiles it finds, whether each lockfile reads, and whether each registry they use answers.

Examples

Check everything under the current directory:

unripe

Only the versions a branch adds, the way a pull request check does:

unripe check --since origin/main

Pick a version before adding it. Without a version, explain lists recent releases and marks the newest one that is old enough:

$ unripe explain pypi certifi

pypi certifi: 77 versions, minimum age 3d 2026.10.19 2026-10-20 02:24 UTC 2d 8h ago too new, old enough at 2026-10-23 02:24 UTC 2026.10.18 2026-10-18 16:21 UTC 3d 19h ago old enough <- newest old enough 2026.7.22 2026-07-22 03:35 UTC 13w ago old enough ...

A stricter rule for one ecosystem and a looser one for type packages, in .unripe.toml:

min-age = "3d"

[min-age-for] npm = "7d" "npm:@types/*" = "1d"

Your own packages are always new; skip them:

unripe check --exclude "npm:@myorg/*"

A version you need now, let through until a date, with the reason in the report:

[[allow]]

package = "npm:axios@1.13.2" reason = "fixes the redirect bug we hit in production" until = 2026-11-15

Results for a script:

unripe check --format json | jq -r '.findings[] | select(.state == "unripe") | "\(.name) \(.version)"'

Quiet unless something is wrong, for a git hook or a cron job:

unripe check --quiet

Lockfiles it reads

Dependencies from git, a local path, a workspace or another registry are skipped, since there's nothing public to ask about them. The old binary bun.lockb can't be read; bun 1.2 and later write a text bun.lock.

NuGet's packages.lock.json doesn't record which feed a package came from, so unripe looks everything up on nuget.org. Packages from a private feed come back unknown; exclude them. For Gradle, artifacts that live in another Maven repository (Confluent's, say) can be found by adding it to maven-repositories in the config.

For Go it reads go.mod, not go.sum. Since Go 1.17, go.mod lists every module in the build, while go.sum also remembers versions that aren't used.

Swift packages are dated like GitHub Actions, below, so only packages hosted on GitHub are checked. Terraform providers from other registries, including OpenTofu's, are skipped. A Conan version is dated by the recipe revision the lockfile pins, since a new revision of an old version is new code; recipes with a user and channel aren't on ConanCenter and are skipped.

In a flake.lock, nixpkgs from a NixOS channel is dated by when the channel published that release, which is often a day after the commit. Inputs on GitHub are dated like GitHub Actions; other hosts, plain git servers and local paths are skipped. A MODULE.bazel.lock lists every module version Bazel read while resolving, and Bazel uses the highest of each, so that is the one checked; a version the registry yanked is reported as unknown. vcpkg has no lockfile: a manifest pins a builtin-baseline, a commit of microsoft/vcpkg that every port's version comes from. Moving the baseline is how a project takes new versions, so unripe checks that the baseline commit is old enough.

renv.lock packages are read from CRAN, or from a Posit Package Manager mirror serving CRAN under /cran/, under whatever name the repository was given. Packages from Bioconductor, GitHub, a local path or another repository are skipped, since CRAN is the only public registry unripe can ask about them.

GitHub Actions

With --workflows (or workflows = true in the config), unripe also reads the uses: lines in your workflows and composite actions. Each one is dated by the GitHub release whose tag points at the same commit, so actions/checkout@v7 and actions/checkout@3d3c42e... are both judged by when that commit was released. A commit with no release falls back to its commit time. An action used at a branch, like @main, has no release to go by, so it comes back unknown. Set GITHUB_TOKEN to get past GitHub's limit of 60 requests an hour; in the Action it is set for you.

A commit time is whatever the commit's author says it is, so a version that passes on one is marked: by its commit time in the text report and "dated_by": "commit" in JSON.

In GitHub Actions

name: unripe

on: pull_request

permissions: contents: read pull-requests: write # only needed for comment: true

jobs: unripe: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v7
• uses: ashfall-sh/unripe@v0.11.0 with: min-age: 3d comment: true

On a pull request it only looks at versions the PR adds, compared with the base commit. It fetches that commit if the checkout is shallow, so you don't need fetch-depth: 0. On a push it checks everything.

Each version that is too new is marked on its line in the lockfile, in the pull request's files view. The report goes to the job summary, and with comment: true also to a comment on the pull request, so reviewers see it without opening the logs. That's one comment, posted when something is too new or unknown and edited in place on later runs, so it doesn't pile up. If the job can't comment, for example on a pull request from a fork, it says so in the log and the check result stays the same.

Pin the action to a full commit sha rather than a tag if you can. The action runs unripe from its own checkout, so the code that runs is the commit you pinned, and nothing gets downloaded from PyPI.

Inputs:

| `min