Skip to content

How to Ignore a Dependency in Dependabot Without Blocking Its Security Updates

by Tim Hopper · Markdown
Security uv Packaging Scientific Python

Some dependencies are expensive to upgrade. A PyTorch bump can require a new CUDA toolkit and NVIDIA driver, so it gets scheduled rather than merged, and the obvious response is to tell Dependabot to ignore the package.

That response also switches off the package’s security pull requests. Dependabot expands an ignore entry that names only a dependency into the version range >= 0 and applies it on the security path as well as the version path.

Scoping the rule to version updates fixes it. The examples use PyTorch, because CUDA coupling is the clearest reason to defer an upgrade, but none of the configuration is specific to it. Packages that only need to age rather than be deferred take a cooldown instead, configured alongside the rest of a uv project’s Dependabot setup.

Prerequisites

  • A uv project with uv.lock committed.
  • Dependabot security updates enabled on the repository, under Settings → Advanced Security. That setting is what opens security pull requests. .github/dependabot.yml can narrow which security updates Dependabot proposes, never enable them.
  • Dependabot’s uv security updates, available since December 2025.

Scope the ignore rule to version updates

Ignore version updates for the torch family, and name the update types explicitly. This is a complete dependabot.yml, not a fragment:

.github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "uv"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "torch*"
        update-types:
          - "version-update:semver-major"
          - "version-update:semver-minor"
          - "version-update:semver-patch"

Listing all three types blocks every version update, exactly as a bare rule would; what changes is the rule’s scope. Naming the version-update types fences the rule out of the security path, because update-types applies only to version updates.

The torch* glob matches every package whose name starts with torch, including torchvision, torchaudio, torchmetrics, and torch-geometric. Name torch alone to confine the rule to the one package.

The CUDA packages torch pulls in do not start with torch, so they keep proposing version updates. Add nvidia-* and cuda-toolkit to the same ignore list to cover them.

To stop routine pull requests for every package in the ecosystem rather than for one, add open-pull-requests-limit: 0 beside schedule:. Security updates do not count against that limit and keep arriving.

Note

A security update targets the minimum version that clears every open advisory, not the newest release. On a CUDA-bound package that jump can still cross a toolkit boundary, so treat a torch security PR as a tested upgrade rather than a merge.

Confirm the rule took effect

A rule that parses is not necessarily a rule that applies, and the failure stays silent until a security fix fails to arrive. Open Insights → Dependency graph → Dependabot, click Recent update jobs beside the manifest, then view logs on a security run.

A correctly scoped rule names each update type and marks it as not applying:

Ignored versions:
  version-update:semver-major - from dependabot.yml (doesn't apply to security update)
  version-update:semver-minor - from dependabot.yml (doesn't apply to security update)
  version-update:semver-patch - from dependabot.yml (doesn't apply to security update)

A rule still scoped too broadly logs the expanded range instead, and blocks the run:

Ignored versions:
  >= 0 - from dependabot.yml
All updates for torch were ignored

That run ends in an all_versions_ignored error and opens no pull request.

The alerts page tells you nothing either way, because ignore rules gate pull request creation and not the alert pipeline. An ignored package still reports every advisory and its first patched version, so a quiet alerts page is not evidence the rule works.

For a check that does not depend on dependabot.yml semantics at all, run uv audit in CI. It reads uv.lock against the OSV database and exits non-zero on findings, catching torch even when only torchvision declares it.

Let the lockfile hold the pin

Declare a loose constraint in pyproject.toml and let the lockfile carry the exact version:

pyproject.toml
[project]
dependencies = ["torch>=2.6"]

uv lock resolves that to a single version and records it with per-platform wheels, which is what makes the environment reproducible. Upgrading is explicit, and uv lock --upgrade-package torch moves everything torch’s own metadata requires, so a project locked at 2.6.0 came back with a rewritten CUDA stack:

$ uv lock --upgrade-package torch
Removed nvidia-cudnn-cu12 v9.1.0.70
Added nvidia-cudnn-cu13 v9.20.0.48
Removed nvidia-nccl-cu12 v2.21.5
Added nvidia-nccl-cu13 v2.29.7
Updated sympy v1.13.1 -> v1.14.0
Updated torch v2.6.0 -> v2.13.0
Updated triton v3.2.0 -> v3.7.1

That run added 18 lockfile entries and removed 13. Three kept a suffix and moved from -cu12 to -cu13 (cudnn, nccl, cusparselt); the other ten arrive unsuffixed through a new cuda-toolkit metapackage. Test a torch upgrade against the target CUDA environment before merging it.

Learn More

Last updated on
How to Host Your Own Python Package IndexHow to Install bitsandbytes