Summary

  • GitHub documents dismissal as a reasoned alert state; an unfixed dismissed alert may be reopened.
  • A dependency-graph observation, a dismissal rationale, a source change and an installed runtime are separate evidence surfaces.
  • A remediation claim needs a joined record rather than an alert-state label.

“Dismissed” is an efficient word for alert triage, but it is a poor substitute for an operational conclusion. GitHub requires a reason when an open Dependabot alert is dismissed. The documented choices include a fix already started, an inaccurate alert, code not used, lack of bandwidth and tolerable risk. Each says something different about how a repository has treated an alert. None, on its own, says that the affected component was upgraded, that a proposed change merged, or that a production estate now runs without the vulnerable version.

GitHub makes the limit visible in its own user guidance: an unfixed dismissed alert can be reopened. That is not a criticism of dismissal. A dismissal can preserve useful triage and keep an alert queue intelligible. It is a reminder that triage state and fixed state are not synonyms. A fix_started rationale can describe work that never reaches review. A not_used rationale may be defensible for a particular path while requiring scope, version and deployment evidence before it becomes a broad safety claim. A tolerable_risk rationale records a judgment; it does not identify who had authority to accept which residual risk for which service.

The alert itself is bounded too. GitHub's dependency graph can derive information from manifests and lock files, graph jobs, automatic dependency submission or submitted data. Static analysis does not have a project's build environment and cannot resolve every variable used in a manifest. Lock files can give a more precise account of resolved versions, but they do not prove which artifact a pipeline built, what passed review, or what a running host loaded. A repository graph is useful evidence of declared or reported dependency state. It is not an inventory of every runtime.

Dependabot security updates add another distinct step. GitHub may create a pull request where it can propose a change. A proposed pull request is neither an approval nor a merge; a merge is neither a successful build nor an accepted release; an artifact is not an installation. Collapsing those steps rewards a reassuring status label while erasing the people and systems that actually decide and verify delivery.

Daniel Kade recommends a six-part remediation receipt: preserve the alert identity, advisory and detected dependency scope; preserve the dismissal reason, comment and deciding authority; preserve the exact source and lock or resolution state; preserve the reviewed change; preserve a build and test artifact with limits; and preserve a bounded deployment observation. Sensitive repository or host identifiers can be protected. The joins cannot be assumed.

Sources

  1. GitHub Docs — Viewing and updating Dependabot alerts
  2. GitHub Docs — How the dependency graph recognizes dependencies
  3. GitHub Docs — Vulnerable dependency detection
  4. GitHub Docs — REST API endpoints for Dependabot alerts