Update dependabot auto approve job to use cargo vet

[simongdavies]

Goal

Keep the existing Dependabot auto-approval job and GitHub App. Add cargo-vet checks and a maintainer command for accepting specific uncovered versions.

Adapt Wasmtime’s maintainer-owned dependency review process:

• Maintainers decide which audits, publishers and exceptions to accept.
• Store those decisions in the repository’s supply-chain files.
• Contributors are not expected to approve their own dependencies.
• Add our own automation for committing maintainer-approved exemptions to Dependabot branches.

Do not adopt Wasmtime’s download-count exemption policy or merge-queue behaviour.

Restrict what the auto-approve script accepts

Update dev/auto-approve-dependabot.sh.

PR selection

NOTE: A similar process is used in hyperlight-js and hyperlight-wasm so we might want to do this work once and make it useable for any repo in the org.

Preserve the existing dependabot-author filter, repository scope and open-PR filter.

• Replace the source-owner comparison with an exact source-repository comparison against $REPO.
• Add a destination-branch filter for main.
• Tighten the source-branch prefix from dependabot/cargo to dependabot/cargo/.
• Skip draft and conflicted PRs before submitting an approval.
• Recheck that the PR remains open immediately before approving.
• Paginate the candidate PR list instead of relying on the default limit of 30.
• Verify whether the existing file and commit queries return complete results. If results are incomplete or truncated, skip approval and report the reason.

Allowed manifest changes

Compare parsed TOML values, not filename substrings or matching lines.

Allow version-requirement changes to existing third-party dependencies in:

• The root Cargo.toml.
• Manifests belonging to members of the root workspace.
• src/tests/rust_guests/Cargo.toml and its workspace-member manifests.

Resolve workspace membership from the base branch so the PR cannot add a manifest to its own allowed list.

Cover normal, development, build, workspace and target-specific dependency tables.

Send the PR to manual review if it:

• Adds or removes a direct dependency.
• Changes dependency features, optional, default-features, package aliases or workspace inheritance.
• Changes a dependency’s registry, Git URL, revision or local path.
• Changes [patch], [replace], package metadata, build settings or cargo-vet settings.
• Adds, deletes or renames a manifest.

Changing version = "1.2" to "1.3" is eligible. Changing the dependency to a Git repository is not.

Allowed lockfile changes

Allow changes to:

• Cargo.lock.
• src/tests/rust_guests/Cargo.lock.

These may include indirect dependency additions, removals and version updates caused by the dependency update. Cargo-vet must check the resulting dependency trees.

Reject a change to the checksum of an otherwise identical package name, version and source.

Reject other Cargo.lock paths, filenames such as Cargo.toml.sh, source-code edits and workflow edits.

Allowed App-generated changes

Permit only these additional changes from the existing GitHub App:

• An update to src/tests/rust_guests/Cargo.lock.
• Exact-version exemptions in either workspace’s supply-chain/config.toml, matching an authorized maintainer command.

Verify the GitHub commit signature and expected App identity. A commit author name or email alone is insufficient.

For exemption commits, compare the actual configuration changes with the approved crate versions. Reject changes to imports, publisher trust, audit criteria or unrelated exemptions.

Do not automatically approve a Dependabot PR containing other human or bot edits.

Approval and merge

• Require DCO, check-labels, report-ci-status and the dependency-check result to succeed for the inspected head commit.
• Handle both GitHub check runs and commit statuses.
• Treat missing, pending, cancelled, failed or unknown required results as blocking.
• Respect outstanding change requests. Do not count an old approval that has been dismissed or superseded.
• Submit the approval for the inspected commit SHA.
• Use gh pr merge --auto --squash --match-head-commit <SHA>.
• Never use an administrator bypass.

Keep .github/workflows/auto-merge-dependabot.yml using the existing App and schedule.

Fix the guest-lockfile updater

Update .github/workflows/dep_update_guest_locks.yml.

The job can currently generate a lockfile from commit A, then attach it to commit B if Dependabot pushes while the job runs.

• Record the checked-out SHA before generating the lockfile.
• Use that SHA as the parent of the generated commit.
• Before publishing, confirm the branch still points to that SHA.
• If it has advanced, stop without pushing and report that a fresh run is needed.
• Update the branch without force. A push occurring after the comparison must cause the update to fail.

Configure cargo-vet

Create:

• supply-chain.
• src/tests/rust_guests/supply-chain.

Each directory contains:

File	Contents
config.toml	Imported audit sources and exact-version exemptions
audits.toml	Maintainer audits and crate-specific publisher trust
imports.lock	Downloaded audit evidence

Import:

• Google: https://raw.githubusercontent.com/google/supply-chain/main/audits.toml
• Mozilla: https://raw.githubusercontent.com/mozilla/supply-chain/main/audits.toml
• Bytecode Alliance: https://raw.githubusercontent.com/bytecodealliance/wasmtime/main/supply-chain/audits.toml

Initialize exemptions for existing uncovered versions once. Record that these are the starting baseline, not audited releases.

Review and configure these proposed publisher rules:

Crate	Publisher identity
cc	github:rust-lang/cc-rs
find-msvc-tools	github:rust-lang/cc-rs
syn	dtolnay
uuid	KodrAus
spin	zesterer
log	KodrAus
tokio	Darksonn
bytes	Darksonn
anyhow	dtolnay
libc	rust-lang-owner
quote	dtolnay
proc-macro2	dtolnay
prettyplease	dtolnay
serde	dtolnay
serde_core	dtolnay
serde_derive	dtolnay
thiserror	dtolnay
thiserror-impl	dtolnay

Verify identities against crates.io release information. Record the reason, audit criteria and publication start/end dates for each rule. Do not grant blanket trust to every crate from a publisher.

Use cargo-vet’s normal safe-to-deploy and safe-to-run requirements. Do not weaken criteria to obtain a passing result.

Check dependencies on every PR

Create .github/workflows/dependency-review.yml as a reusable workflow called by .github/workflows/ValidatePullRequest.yml.

Create dev/check-dependencies.sh.

• Check the PR contents for both human-authored and Dependabot PRs.
• Run cargo-vet for the root workspace and src/tests/rust_guests.
• Include indirect dependencies and retain cargo-vet’s default all-features analysis.
• Keep Cargo lockfiles unchanged during checking.
• Use the checked-out supply-chain files, as Wasmtime does. Validate changes to those files separately as described below.
• Refresh imported evidence without automatically adding exemptions or publisher rules.
• Run Cargo Audit against both lockfiles. Known vulnerabilities must fail the check. A cargo-vet exemption must not suppress them.
• Keep the existing scheduled Cargo Audit workflow.
• Save the effective cargo-vet files, tool versions and results as workflow artifacts.
• Run without the App’s write token.

Pin tool versions. Use scripts from the protected base branch for checks that decide whether automatic approval is allowed.

Add the reusable workflow to report-ci-status dependencies. Require its result to be success, not skipped.

Require approval for cargo-vet configuration changes

Passing cargo-vet alone must not allow a PR to exempt its own dependencies.

Add a check for changes under both supply-chain directories:

• For human-authored PRs, require an approving review from someone with repository maintain or admin permission, other than the PR author, on the current head commit.
• For Dependabot PRs, accept only the narrowly scoped App-generated exemptions described below. Other configuration changes require manual handling and are not eligible for auto-approval.
• A changed PR head must invalidate any previous passing authorization result until checked again.
• Trigger reevaluation when a review is submitted or dismissed.
• Use the GitHub API to verify permissions and reviews. Do not trust usernames supplied in files or comments.

Add both supply-chain paths to .github/CODEOWNERS for reviewer assignment. CODEOWNERS alone is not the approval check.

Add maintainer commands for Dependabot exemptions

Create .github/workflows/dependency-exception.yml and dev/approve-dependency-exception.sh.

Use an issue_comment creation event. Ignore comments that are not commands on open Cargo Dependabot PRs.

Support:

/dependency-exception crate-name 1.2.4 reason: reviewed the release changes

For several versions, accept one explicit command per line in the same comment.

The handler must:

• Check the commenter’s current repository permission. Require maintain or admin.
• Read the PR’s current head SHA and resolve each requested crate version in its dependency trees.
• Reject missing or ambiguous matches. Verify the source and checksum.
• Determine the criteria required by cargo-vet.
• Use cargo vet add-exemption to add only the requested versions to the relevant configuration files.
• Record the approver, reason, comment link and package identity alongside the exemption.
• Verify that no other configuration values changed.
• Create a signed commit with DCO sign-off using the same GitHub App/Git Data API mechanism as the guest-lockfile updater.
• Confirm GitHub reports the commit signature as verified before updating the branch.
• Use the inspected head SHA as the commit parent. Stop if the branch advances, and never force-push.
• Post a confirmation linking to the exemption commit. Report errors explicitly.

Use the existing App credentials only in this handler. Do not run scripts, build commands or hooks supplied by the PR with those credentials.

The App’s push triggers fresh CI. The existing scheduled job approves and merges once all checks pass. Maintainers do not need to submit another approval or open another PR for the exemption.

The committed configuration is the permanent exception record. Do not build a database from comments on old merged PRs.

After a rebase, reuse an exemption only if the package identity and approved exemption remain unchanged. Recheck the latest PR contents before automatic approval.

Make failures actionable

The workflow summary must identify:

• The failing workspace.
• Each uncovered crate and version.
• The required audit criteria.
• Whether cargo-vet found a usable audit in an approved source.
• Exact maintainer commands to inspect the release or diff, record an audit, or add a version exemption.
• The files those commands update.
• For Dependabot, the exact /dependency-exception comment to use.

Tell contributors that a maintainer handles vet changes. Do not ask them to approve their own dependencies.

For network or tool failures, show the actual error and retry instructions. Do not recommend an exemption.

Tests and reviewer guide

Add tests for approval and exception handling.

Create docs/dependency-updates.md covering:

• The process adapted from Wasmtime and our automated additions.
• What contributors should do when cargo-vet fails.
• How maintainers inspect releases and record audits.
• How to approve one or several Dependabot versions.
• How to add audit sources and add, renew or remove publisher trust.
• How to remove an exemption.
• How rebases affect approval and how to rerun checks.

Include copyable commands for both workspace locations.

Expected benefit

The retrospective covered 100 Cargo Dependabot PRs opened from 10 June to 10 September 2026:

Configuration	Covered	Needed attention
Google, Mozilla and Bytecode Alliance audits	21	79
Those audits plus our proposed 18 publisher rules	68	32

These figures use audit evidence available on 10 September. They are not a guarantee of future coverage. Publisher trust reduces review work but does not protect against every compromise of an accepted publisher.