--- name: github-dependabot-alerts description: "Every Monday: open Dependabot alerts across the org by severity, the critical and high ones with a fix available, and the repos that hold the most. Use when the user asks for this, or when it runs on a schedule." --- # GitHub Dependabot alerts by severity Every Monday: open Dependabot alerts across the org by severity, the critical and high ones with a fix available, and the repos that hold the most. Dependabot finds plenty; the trouble is that nobody opens the Security tab on thirty repos. Alerts pile up per repo, and a critical in the production API sits in the same list as a low in a demo app. The agent pulls every open alert in the org in one paginated call, counts them by severity and repo, and lists the critical and high alerts that already have a patched version, since those are one upgrade away. The weekly number shows at a glance whether the pile is shrinking. ## Two ways to get the data Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used. ## Route A: API or MCP server ### What you need - Owner or security manager rights in the org to read alerts across it, or Dependabot alerts read access per repo (the `security_events` scope on a classic token). - `gh` signed in, or a GitHub MCP server or connector that reaches the Dependabot alerts API. If something is missing, say what and stop; do not invent numbers. ### Steps 1. **Pull open alerts for the org** (GitHub): `gh api --paginate "/orgs/acme/dependabot/alerts?state=open&per_page=100"`. For a personal account, call `/repos/{owner}/{repo}/dependabot/alerts?state=open` for each repo instead. 2. **Count by severity and repo**: Group on `security_advisory.severity` (critical, high, medium, low) and on `repository.full_name`. Compare the total with last week's card for the change. 3. **Find what you can fix now**: An alert is patchable when `security_vulnerability.first_patched_version.identifier` is set. For critical and high ones, keep the package, ecosystem, `dependency.manifest_path`, vulnerable range, patched version and GHSA ID. 4. **Note the age**: Days since `created_at`. Call out any critical older than 7 days and any high older than 30, which is where many security policies set their fix windows. 5. **Report**: Total open, the severity split, the top repos, and the patchable critical and high alerts oldest first. ## Route B: the browser ### What you need - Signed in to GitHub as an organization owner or security manager for the org-wide list; for a single repository, an account with access to its security alerts. If something is missing, say what and stop; do not invent numbers. ### Steps Start at https://github.com/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears. 1. **Open the organization's Dependabot alerts**: Go to `github.com/`, click the **Security and quality** tab (labeled **Security** on older layouts) and choose **Dependabot** under Alerts. For a personal account, or an organization whose plan has no org-level alert list, open each repository's **Security and quality** tab > **Dependabot** instead. 2. **Count by severity and repo**: The counter above the list shows how many are **Open**. Filter with `is:open severity:critical`, then `high`, `medium` and `low`, noting each count; use the **Repository** filter or the per-repository counts in the sidebar for the top repos. 3. **Find what you can fix now**: Filter `is:open has:patch severity:critical,high` and set the sort to **Oldest**. Open each alert for the package and ecosystem, the manifest path, the vulnerable range, the patched version and the GHSA ID. 4. **Note the age**: Each row says when the alert was opened. Call out criticals older than 7 days and highs older than 30. 5. **Report**: Total open, the severity split, the top repos, and the patchable critical and high alerts oldest first, with the change since last week's total if you have it. Note: The organization-wide Dependabot alert list is available on organization plans that show it under the org's Security and quality tab; on others, and on personal accounts, the alerts are per repository. The list shows 25 alerts per page, so an organization with hundreds of alerts is faster through the API route. ## The report - **Open alerts** across the org, and the change since last week. - **By severity**: critical, high, medium, low. - **Top repos** by open alerts. - **Patch now**: critical and high alerts with a fixed version, with package, current and patched version, manifest and age. - **Overdue**: criticals older than 7 days and highs older than 30. ## Post it to Briefkin When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on. ```bash [ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \ -H "authorization: Bearer $BRIEFKIN_TOKEN" \ -H "content-type: application/json" \ -d @- <<'JSON' { "v": 1, "event_id": "github-dependabot-alerts/", "item_key": "github-dependabot-alerts", "project": "Acme", "source": "GitHub Dependabot alerts by severity skill", "kind": "metric", "title": "41 open Dependabot alerts, 2 critical", "metric": { "label": "Open Dependabot alerts", "value": 41, "better": "lower", "period_start": "", "period_end": "" }, "glance": [ { "type": "Grid", "props": { "columns": 4 }, "children": [ { "type": "Stat", "props": { "label": "Critical", "value": 2, "tone": "bad" } }, { "type": "Stat", "props": { "label": "High", "value": 9, "tone": "warn" } }, { "type": "Stat", "props": { "label": "Medium", "value": 21 } }, { "type": "Stat", "props": { "label": "Low", "value": 9 } } ] } ], "widget": [ { "type": "Table", "props": { "columns": [ "Package", "Severity", "Repo", "Fixed in", "Age" ], "align": [ "left", "left", "left", "left", "right" ], "rows": [ [ "fast-xml-parser 4.1.2", "Critical", "acme-api", "4.2.4", "9d" ], [ "next 14.1.0", "Critical", "acme-web", "14.2.25", "3d" ], [ "path-to-regexp 0.1.7", "High", "acme-api", "0.1.12", "38d" ], [ "cross-spawn 7.0.3", "High", "acme-infra", "7.0.5", "21d" ], [ "ws 8.11.0", "High", "acme-web", "8.17.1", "12d" ] ] } }, { "type": "Bars", "props": { "items": [ { "label": "acme-web", "value": 17 }, { "label": "acme-api", "value": 13 }, { "label": "acme-infra", "value": 7 }, { "label": "acme-docs", "value": 4 } ], "unit": "alerts" } }, { "type": "Callout", "props": { "text": "The fast-xml-parser critical in acme-api is 9 days old, past a 7-day window, and 4.2.4 fixes it.", "tone": "bad" } } ], "size": "md" } JSON ``` Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report. Set `period_start` and `period_end` to the window the number covers: the tile names it from them ("Last 7 days", "Today", "This month"). For a count right now (open items, a balance), send `"period_label": ""` so no period shows; for another name, send it as `period_label` (at most 24 characters). ## Run it on a schedule Suggested: Mondays at 8:00 (`0 8 * * 1`). From cron, with the agent signed in on that machine: ```bash 0 8 * * 1 claude -p "Run the github-dependabot-alerts skill" # Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run ``` Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/github-dependabot-alerts#schedule Source: https://briefkin.dev/skills/github-dependabot-alerts