Dependabot PRs Still Arrive, but pnpm 12 Security Alerts Disappear—Why?
After moving to pnpm 12, Dependabot still opens version PRs, but open security alerts start closing with nothing upgraded. Is the vulnerability gone, or just out of view?
- Dependabot version updates and security detection do not have identical pnpm 12 coverage.
- An alert can close without the vulnerable dependency being upgraded.
- Compare the project packages in the lockfile with GitHub’s detected dependencies.
An update PR is not proof that security detection works
After a pnpm 12 migration, disappearing alerts can mean missing detection rather than successful remediation. GitHub’s October 20 support announcement documents a limitation for two-document YAML lockfiles. Version updates work, but the dependency graph misses those dependencies; security alerts and updates are not created for them, and existing alerts may close.
This distinction surfaced in the project’s issue tracker. On October 21, a participant asked whether multi-document parsing worked after the support announcement. That question captures the adoption problem: a working update bot can look like confirmation that the rest of GitHub’s dependency tooling is ready.
One file can contain two YAML documents
The pnpm format documentation describes a leading boot document for package-manager and configuration dependencies, followed by the project dependency graph. Both can declare the same lockfileVersion. The schema number alone does not identify the file’s layout.
Projects that pin pnpm 12 commonly produce this format. Inspect the generated pnpm-lock.yaml, not just the package-manager version. A reader that only finds boot packages may return a plausible inventory while omitting the application’s packages.
Dependabot covers three different jobs
Version updates look for newer package releases using the locations and behavior configured in dependabot.yml. They can open PRs even when a package has no known vulnerability. Receiving one confirms that update path is functioning.
| Feature | Purpose | Evidence to inspect |
|---|---|---|
| Version updates | Propose newer dependency versions. | The update PR and changed files. |
| Dependabot alerts | Match detected dependencies to known vulnerabilities. | The affected file, version and alert. |
| Security updates | Attempt to fix an alerted dependency. | A linked remediation PR or reported error. |
Alerts concern the default branch and respond to advisory or dependency-graph changes. When enabled, security updates attempt to resolve vulnerabilities identified by those alerts. They are not simply another name for every Dependabot PR.
Compare packages and versions, not just the alert count
Open Insights → Dependency graph. The view supports searching by package name and shows versions and the files that introduced dependencies. Compare that inventory with the lockfile on the default branch.
- Inspect the migration diff for a change to a two-document lockfile.
- Search for application packages from that file and match their versions and source manifests.
- For closed alerts, check whether the dependency actually moved to a patched version.
This comparison tests both coverage and remediation. If an alert closes while the same vulnerable package version remains in the lockfile, the closure should not be counted as a completed fix.
A successful migration needs security visibility as well as continuing update PRs. Where packages are missing, resolve the supported-format issue and repeat the inventory comparison. A quiet alert page alone cannot establish that the dependencies were secured.