If a package has a newer release, that is a maintenance item. If GitHub reports an open Dependabot advisory affecting a dependency in your repository, that is a security triage item. Put them in different queues. Neither a quiet outdated report nor a successful command exit establishes that the repository has no vulnerabilities, especially if an alert query was denied or the dependency inventory is incomplete.
Make the scan state visible before counting alerts
GitHub's repository Dependabot-alerts endpoint accepts a state filter. Run the read-only query with an identity authorized for each repository; fine-grained tokens need Dependabot alerts read permission. Paginate the response. Record the repository and observation time alongside the result. A 403, a disabled alert feature, or another failed query is an unknown scan state, not an empty list. An empty successful response is still limited to what GitHub identified in that repository's dependency data.
gh api --paginate 'repos/OWNER/REPO/dependabot/alerts?state=open&per_page=100'Replace OWNER/REPO with a repository you are authorized to inspect. This command reads alerts; it does not configure Dependabot, fix a dependency, or verify that a deployed service is safe. If your organization uses a different advisory source, document its coverage separately rather than merging inventories and calling the total a vulnerability count.
Route the result to the right owner
| Observed state | What the report can say | Next action |
|---|---|---|
| New open advisory | A vulnerable dependency was identified in the repository data | Check affected package, advisory URL, scope, exposure, and available fix with the owner |
| Newer registry release, no matching advisory in this check | A version update is available; security status remains bounded by the advisory scan | Queue a routine upgrade and test it |
| Alert query denied or failed | Security-alert status is unknown | Repair permissions or scan coverage; do not send a green report |
| Previously reported open advisory | Still open, not a new incident | Keep it in the owner backlog; re-alert on material change or agreed escalation |
npm outdated compares the installed version with the version wanted by the manifest and the registry's latest tag. It does not interpret an advisory. Use the package manager actually used by the repository, such as pnpm for a pnpm lockfile, and keep this version inventory apart from the Dependabot result. A failed registry lookup also belongs in the incomplete-scan bucket.
Make the runbook repeatable without inventing urgency
Our Dependency Checker gallery checklist previously said 'Every Monday at 9am' inside a HEARTBEAT.md item. That text alone does not create a 9 AM schedule. The revised checklist asks the operator to install a weekly OpenClaw Automation in the intended time zone, verify its run history and alert delivery, and persist last-seen alert IDs so an unchanged advisory is not paged again every week. A weekly scan cannot promise immediate detection between runs; use your existing security notification path if you require faster response.
The agent can summarize the advisory, version inventory, and missing coverage for a human. It should not silently dismiss an alert, upgrade a package, or assert exploitability from a severity label alone. Before relying on the workflow, test a controlled advisory notification and a denied-query case. The Runbooks gallery item is an operating checklist, not a deployed scan or evidence that a patch reached production.
Inspect the Dependency Checker checklist