A platform team wants every new Dependabot alert and every change to a Dependabot alert in an organisation to be pushed to an external triage service so it can open and close tickets automatically. They configure an organisation-level webhook and now have to choose which event to subscribe to so that the payload carries the alert and an "action" field such as "created", "dismissed", "resolved", or "reopened". Which webhook event delivers Dependabot alert lifecycle changes?
- ASubscribe to the "dependabot_alert" event, whose payload includes the alert object and an "action" field describing the lifecycle change. Correct
- BSubscribe to the "repository_vulnerability_alert" event, the current event GitHub emits for every Dependabot alert state change.
- CSubscribe to the "security_advisory" event, which fires whenever a Dependabot alert is created or resolved for a repository.
- DSubscribe to the "dependabot" event and read the "action" field to distinguish created from dismissed alerts.
Why A is correct: The "dependabot_alert" webhook event fires for the alert lifecycle and its payload carries the alert plus an "action" value such as created, dismissed, fixed, auto_dismissed or reopened, which is exactly what the external service needs to drive ticketing.
Why B is wrong: "repository_vulnerability_alert" is the legacy event that predates Dependabot alerts and is deprecated in favour of "dependabot_alert"; relying on it risks missing newer actions and payload fields, so it is the wrong subscription for new integrations.
Why C is wrong: "security_advisory" fires when an advisory in the GitHub Advisory Database is published or updated, not when a specific repository's Dependabot alert changes state, so it would not carry the repository alert lifecycle the team needs.
Why D is wrong: There is no webhook event simply named "dependabot"; the correct event identifier is "dependabot_alert", so subscribing to "dependabot" would never deliver any payload.