Beyond Stars: MTTX Brings Developer Responsiveness to Dependency Decisions, from Dashboard to IDE to GitHub Actions

How fast do open-source packages update their dependencies and remediate known vulnerable dependencies, over time?

Imranur Rahman^*, Ranindya Paramitha^†, Mahzabin Tamanna^*, Laurie Williams^*

^*North Carolina State University, ^†University of Bristol

Paper (soon) Code PyPI VS Code Extension Open VSX Extension GitHub Action Container (GHCR) Zenodo Algorithm Video

Architecture of MTTX: inputs, CLI, historical dependency resolver, OSV index, dependency analyzer, and reporting, with the interactive dashboard, the IDE extensions, and the GitHub Action, which run the CLI

Architecture of MTTX. Numbers give the order of the steps. The resolver resolves each version constraint as of a past date, and the dashed slots show where a new ecosystem plugs in. At the bottom, the interactive dashboard, the IDE extensions, and the GitHub Action run the CLI and show its results.

Overview

Developers often choose a dependency by its GitHub stars and download counts, but these signals are cheap and easy to fake. MTTX gives a signal of observed behavior instead: how quickly the developers of a package responded to new dependency releases and to security fixes over time. It computes two metrics for the direct dependencies of a package in npm, PyPI, or Cargo: Mean Time To Update (MTTU), how long the dependencies stay behind their newest version, and Mean Time To Remediate (MTTR), how long the dependencies keep a known vulnerability after a fix is available.

Prior work computed these metrics with a research prototype for a fixed set of packages. MTTX computes them for any package and time window, with each version constraint resolved as of a past date, so it never uses data from the future. It brings the values to each point where developers decide on a dependency: an interactive dashboard to select one, an IDE extension while they code, and a GitHub Action in CI. All of them run one CLI, which researchers can also run in batches over thousands of packages.

Try It

Compare MTTU and MTTR of up to 5 packages from one ecosystem, with deps.dev data.

Ecosystem

Packages (1 to 5)

Start date

End date

What do you want to see?

One value for each package MTTU and MTTR over the whole period, as a bar chart. A value at each release How MTTU and MTTR changed over time, as line charts.

Weighting

Half-life (days)

Privacy: the Host stores the package names that you submit, so that it can show and reuse the results. For the rate limits, it stores a hash of your IP address for one hour, and it never stores the IP address itself. Cloudflare Turnstile checks that a person sends the form.

Results

Use MTTX in Your Workflow

MTTU and MTTR show how the maintainers of a package responded to new dependency versions and to fixed vulnerabilities in the past. MTTX brings this evidence to each place where you decide on a dependency: when you select it, while you code, and in CI. The same Tool computes every value, so the numbers agree everywhere.

Compare candidate packages before you add one

The interactive dashboard on this page compares up to five packages from one ecosystem, with no installation. Our server runs the Tool with deps.dev data and shows a bar chart, a table, and a plain-English Explanation of each value. Per-release mode adds line charts that show how MTTU and MTTR changed at each release.

Go to Try It, pick the ecosystem, and type the names of the candidate packages.
Pick a time window and a mode, and then select Compute.
Read the Explanation under the table, and download the CSV file if you want to keep the values.

Go to Try It

The sample loads precomputed results at once, so you see the charts and the Explanation without a wait.

See MTTU and MTTR next to each dependency while you code

The MTTX extension shows the MTTU and MTTR of each dependency as an inline hint in package.json, pyproject.toml, and Cargo.toml. The hover gives the time window, the data source, and the Explanation, and a link opens a Comparison of the package with alternatives. The extension runs the Tool on your machine.

VS Code

Install from the Visual Studio Marketplace, or run:

code --install-extension imranur-rahman.mttx

Cursor, Windsurf, VSCodium, and other editors that use Open VSX

Search for MTTX in the Extensions view, or install from Open VSX. For example:

codium --install-extension imranur-rahman.mttx

The first run installs the Tool in a private Python environment (Python 3.10 or later) and offers to build the OSV index, which MTTR needs. To try the extension at once, open the demo project, which has one manifest of each kind.

Report MTTU and MTTR in CI

The MTTX GitHub Action runs the Tool in the pinned container image. It reports the values; it fails the step only when you set a limit and a value is above it.

Review the dependencies that a pull request adds

# .github/workflows/mttx.yml
on: pull_request
permissions:
  contents: read
  pull-requests: write
jobs:
  dependencies:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - uses: imranur-rahman/mttx-action@v1
        with:
          target: pull-request

Track your own packages each week

# .github/workflows/mttx-weekly.yml
on:
  schedule:
    - cron: "0 6 * * 1"
jobs:
  packages:
    runs-on: ubuntu-latest
    steps:
      - uses: imranur-rahman/mttx-action@v1
        with:
          packages: express, koa
          ecosystem: npm
          max-mttr-days: 30

The weekly job also gives step outputs, a job summary, and badge files for shields.io.

Sample output: the comment on a pull request

github-actions bot commented

MTTU and MTTR of the dependencies that this pull request adds

Window: 2024-10-23 to 2026-10-23 · Data source: deps.dev · Weighting: disable

Package	Ecosystem	MTTU (days)	MTTR (days)	Dependencies	Manifest	Note
`serde`	cargo	0.00	0.00	1	`Cargo.toml`
`axios`	npm	52.24	0.00	4	`package.json`
`lodash`	npm	–	–	0	`package.json`	could not compute since 'lodash' has no dependencies
`requests`	pypi	0.00	0.00	4	`pyproject.toml`

axios: MTTU is 52.24 days: in this time window, a direct dependency of axios was behind the newest available version for 52.24 days in total, on average over the direct dependencies. In this time window, no direct dependency stayed on a version with a known vulnerability after a fix was available.

The comment also lists the Explanation of each package and the limitations of the data. A new push updates the same comment.

From a test pull request in imranur-rahman/mttx-action-smoke, shortened. The Action README lists every input and output.

Run the Tool yourself, at scale or exactly again

CLI from PyPI

pip install dependency-update-metrics

# One package, with the OSV index built on the first run
dependency-metrics --ecosystem npm --package express \
  --start-date 2024-01-01 --end-date 2025-12-31 --build-osv

# MTTU and MTTR at every release of a package
dependency-metrics --ecosystem pypi --package requests \
  --start-date 2020-01-01 --end-date 2021-01-01 --per-release

# A batch of packages from a CSV file, in parallel
dependency-metrics --input-csv input.csv --workers 8 --output-dir output

Container image on GHCR

The image pins Python, every dependency, and the patched pip. The -osv- tag holds the OSV index of that date, so a rerun uses the same vulnerability data and downloads none.

docker run --rm -v "$PWD:/data" \
  ghcr.io/imranur-rahman/mttx:0.2.1-osv-2026-10-23@sha256:3d528b998884f985e484b1da0cceb1219930c1d38625e18bb9ed9f69bce5c2eb \
  --ecosystem npm --package express \
  --start-date 2024-01-01 --end-date 2025-12-31 --depsdev --json

Output (shortened). The values equal the sample Comparison of the interactive dashboard:

{"package": "express", "data_source": "depsdev",
 "summary": {"mttu": 120.31748718584655, "mttr": 3.0759126984126985,
             "num_dependencies": 28, "status": "ok"}}

More container options

Each command reads the package data from deps.dev (--depsdev), as the interactive dashboard and the GitHub Action do, so that the values agree. Without --depsdev, the Tool reads the registry of each ecosystem.

Pull the image once, so that later runs start at once:

docker pull ghcr.io/imranur-rahman/mttx:0.2.1-osv-2026-10-23

On Linux, add --user, so that the result files in your folder belong to you and not to root:

docker run --rm --user "$(id -u):$(id -g)" -v "$PWD:/data" \
  ghcr.io/imranur-rahman/mttx:0.2.1-osv-2026-10-23 \
  --ecosystem npm --package express --start-date 2024-01-01 --end-date 2025-12-31 --depsdev

MTTU and MTTR at every release of a package, and a batch of packages from input.csv in the current folder:

docker run --rm -v "$PWD:/data" ghcr.io/imranur-rahman/mttx:0.2.1-osv-2026-10-23 \
  --ecosystem pypi --package requests \
  --start-date 2020-01-01 --end-date 2021-01-01 --per-release --depsdev

docker run --rm -v "$PWD:/data" ghcr.io/imranur-rahman/mttx:0.2.1-osv-2026-10-23 \
  --input-csv /data/input.csv --workers 8 --depsdev

For the vulnerability data of today, use the plain tag. It has no OSV index, so the first run with --build-osv downloads the OSV data and keeps the index in your folder for later runs:

docker run --rm -v "$PWD:/data" ghcr.io/imranur-rahman/mttx:0.2.1 \
  --ecosystem npm --package express --start-date 2024-01-01 --end-date 2025-12-31 --depsdev --build-osv

Print the build date of the OSV index that a run uses:

docker run --rm ghcr.io/imranur-rahman/mttx:0.2.1-osv-2026-10-23 --osv-index-date

The mounted folder keeps the output of each run: the results (for example express_results.json), the log run.log, and the cache cache/cache.db, which a later run reuses. Do not add --build-osv to the -osv- tag; image/README.md gives the reason and all other details.

Cite the image digest for an exact rerun. The README lists all options, ALGORITHM.md describes how the metrics are computed, and TESTING.md maps each test to what it checks. The source code is archived on Zenodo (DOI 10.5281/zenodo.23608337).

Validation

328

offline tests: unit, integration, regression, and metamorphic

90 / 90

case-study packages manually verified: the dependency resolution at each release point and the MTTU and MTTR computation

72 / 90

case-study packages whose scores match the reference scores of prior work exactly (80 within one day)

The test types follow research on testing scientific software; TESTING.md maps each type to its tests. CI runs the suite on Ubuntu, macOS, and Windows with Python 3.10–3.12. All front ends run the same CLI, so they give the same values: for express (npm, 2024–2025, deps.dev), the interactive dashboard, the container image, and the GitHub Action all report an MTTU of 120.32 days and an MTTR of 3.08 days.

Who Can Use It

Researchers who study technical lag, software supply chains, or maintainer behavior can compute MTTU and MTTR for thousands of packages and get a full time series per package.
Developers can compare how promptly candidate libraries keep their own dependencies current and patched, in the interactive dashboard before they choose one and in their IDE while they code.
Development teams can report MTTU and MTTR in CI with the GitHub Action, and review the dependencies that each pull request adds.
Security teams can run a batch over their portfolio to find the projects that lag behind available fixes.
Builders of security metrics, such as the OpenSSF Scorecard, can use MTTU and MTTR as signals of maintenance.

Demo Video

Watch on YouTube

Related Work from the Authors

How Quickly Do Development Teams Update Their Vulnerable Dependencies?

Which Is Better For Reducing Outdated and Vulnerable Dependencies: Pinning or Floating?

CHRONO-RESOLUTION: A Dependency Resolution Dataset at Release Points for npm, PyPI, and crates.io Packages

What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls