Update dependabot auto approve job to use cargo vet

## 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](https://docs.wasmtime.dev/contributing-coding-guidelines.html#dependencies-of-wasmtime):

* 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 `.
* 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.

Start with dev/auto-approve-dependabot.sh, .github/workflows/dep_update_guest_locks.yml, and the existing ValidatePullRequest workflow. Read the current App and guest-lockfile mechanisms before adding cargo-vet configuration, reusable dependency checks, exception handling, tests, and docs. Done means the named workflows and scripts enforce the stated restrictions, pass their tests, and produce actionable results without weakening cargo-vet or audit checks.

Escrito por el modelo de indexación a partir del texto del issue.