Using Dependabot with the Zero-Trust Workflow

The risk

Dependabot monitors your dependencies and opens PRs when newer versions are available. That is useful, but it introduces a specific supply chain risk: a compromised package version published today could have a Dependabot PR open and auto-merged within hours — well inside the detection window where most attacks are caught by the community.

Dependabot also has no access to nuget.org prefix reservation data. It cannot tell you:

• Whether the package's verified flag is set
• Whether the owner on the new version matches the owner you originally trusted
• Whether the version is newly published and within the detection window
• What transitive packages the update would add or change

It is reactive by design — it surfaces known CVEs and version availability, but it cannot evaluate trust. nuget-audit fills this gap, but only if Dependabot PRs do not bypass the review step.

The three-part mitigation

These three settings together make Dependabot compatible with the zero-trust workflow. All three are needed — any one alone is insufficient.

1. Disable auto-merge for dependency PRs

Auto-merge eliminates the review window entirely. Disable it for any PR that touches package references, or require manual approval before merge regardless of CI status.

In GitHub, this is a branch protection rule or a repository-level auto-merge setting. For Dependabot specifically, ensure no automerged_updates rules are set in .github/dependabot.yml for the nuget ecosystem.

2. Add a minimum PR age before merge

Require a minimum age of 14 days (matching recentDaysThreshold) before any dependency PR can be merged. This ensures the detection window has passed before the new version enters your project.

GitHub does not have a native minimum PR age feature. The recommended pattern is a scheduled CI check that reads the PR creation date and fails until the age threshold is met. This becomes a required status check that blocks the merge button.

3. Run nuget-audit audit --check as a required CI status

Add the audit check to the required status checks for the branch. On a Dependabot PR branch, the audit will flag any newly published package within the detection window in the Recently published section — giving you visibility before merge.

# In your CI workflow, on every PR:
dotnet restore
nuget-audit audit --check --path .

A clean pass (exit code 0) is required before the PR can be merged. If the new package version is within the threshold, --check exits 1 and the merge is blocked until the window passes and the audit clears.

Reviewing a Dependabot PR

Before approving a Dependabot PR, run preview-update on the PR branch to see the full transitive graph impact — what packages would be added, changed, or removed, and whether any are untrusted or recently published.

# Check out the Dependabot branch locally
git checkout dependabot/nuget/SomePackage-2.0.0

# Preview the transitive graph change
nuget-audit preview-update SomePackage --version 2.0.0 --path .

Review the output for each section:

• ADDED — new transitive packages entering your graph
• CHANGED — existing packages being updated by this change
• REMOVED — packages dropping out of the graph

Any package in ADDED or CHANGED that is Untrusted, VersionChanged, or within the recently published window requires review before you approve the PR.

Lock files and Dependabot

When RestoreLockedMode=true is in effect, Dependabot must update packages.lock.json as part of the PR — it cannot just bump the version in the project file, because restore would fail against the stale lock. Dependabot handles this automatically: it runs dotnet restore on an ephemeral CI runner and commits the updated lock file alongside the version change.

This is the safest integration pattern:

1. Dependabot detects a new version and creates a branch
2. Updates the version in the project file or Directory.Packages.props
3. Runs dotnet restore on the branch, regenerating the lock file
4. Opens the PR with both changes — version bump and updated lock file together
5. CI runs dotnet restore (validates the lock) and nuget-audit audit --check
6. You review the lock file diff and the audit output before approving

The lock file diff in the PR is the exact record of what changed in the resolved graph. Review it alongside the preview-update output to confirm they match.

Verifying PR origin

In 2023, attackers submitted fake PRs that appeared to come from Dependabot. A PR labeled as a Dependabot update is not necessarily one.

Always verify:

• The PR was opened by the dependabot[bot] account — not a user account with "dependabot" in the name
• The branch name follows Dependabot's naming convention (dependabot/nuget/PackageName-Version)
• The lock file diff contains only changes consistent with the stated version bump — no unexpected new packages or unusual version jumps

If anything looks inconsistent, treat the PR as untrusted and investigate before merging.