security-alert-triage

Triaging security alerts

Turn four separate alert streams into one ordered list of decisions, each backed by evidence a maintainer can check.

This server reads alerts; it does not resolve them. No tool here dismisses an alert, merges a fix, or revokes a credential. The output is a recommendation with evidence.

Sequence

1. Inventory every source that answers. list_code_scanning_alerts, list_dependabot_alerts and list_secret_scanning_alerts with state: open. Enumerate list_repository_security_advisories separately: omit state for all advisories, or use triage, draft, published or closed. Record which sources answered and which did not — the difference matters, see the failure cases. When the question spans an organisation rather than one repository, list_org_repository_security_advisories with org gives the same advisory picture across every repository in it, and is the right starting point before fanning out.
2. Handle secret scanning first, ahead of any ordering by severity. A live credential is the only alert type where delay keeps causing harm.
3. Order the rest by exploitability, not by count. severity narrows the field; whether the code is reachable decides it.
4. Read the individual alert for anything you intend to recommend on: get_code_scanning_alert, get_dependabot_alert or get_secret_scanning_alert with the alert number. List responses are deliberately thin.
5. Ground it in the code. For a code scanning alert, read the flagged location with get_file_contents. For a dependency alert, search_code for the vulnerable symbol to find out whether the project reaches the affected path at all.
6. Look up the advisory behind a dependency alert with list_global_security_advisories or get_global_security_advisory by GHSA or CVE id. The advisory carries the patched versions and the real-world conditions.
7. Recommend, using the decision points below, naming the evidence each recommendation rests on.