How to ignore a dependency in Dependabot without blocking its security updates

Need Dependabot to get past a version ceiling such as <2.32 rather than skip a package? That is a different fix: how to keep a capped dependency from blocking Dependabot security updates.

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.

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:

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 update types fences the rule out of the security path: Dependabot’s own job log marks each one doesn't apply to security update, and the options reference documents update-types as a filter on version updates, not security 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.

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 such as torch>=2.6 in pyproject.toml and let uv.lock carry the exact version, so the ignore rule is the only thing holding torch back. When it is time to move, how to upgrade a capped dependency with uv walks through the uv lock --upgrade-package torch run and the CUDA packages it drags along.