GH-500 - Configure and use supply chain security (18% of the exam) - Section 3.5

Manage permissions, role-based alert assignment, workflow management, and external notifications, webhooks, and integrations for supply chain security.

Manage supply chain security permissions and role-based alert assignment to ensure the right teams own Dependabot findings. Configure webhooks and external notifications to route supply chain alerts to external incident management or chat systems.

role-based alert assignmentwebhooksnotificationssupply chain permissions

Practice question for this objective

Free sampleConfigure and use supply chain securitymedium

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.

Identify the "dependabot_alert" webhook event as the mechanism that delivers Dependabot alert lifecycle changes with an action field to external integrations. GitHub emits the "dependabot_alert" webhook event for the full alert lifecycle, and each delivery includes the alert object alongside an "action" field (created, dismissed, fixed, auto_dismissed, reopened), which lets an external service react to state changes without polling.

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.

See more GH-500 practice questions, answers explained.

Exam traps in Configure and use supply chain security

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-500 bank for this domain.

An organisation-level email notification routing rule that forwards Dependabot alert emails to the incident tool's inbound address.
Why it is wrong: Forwarding alert emails to an inbound address could in theory reach the tool, which is why it is tempting as a quick fix, but it is the email path the lead has already rejected as too slow and it delivers human-formatted mail rather than a structured event payload. It is not the push integration designed for this.
Adding a Dependabot configuration block that sets the alert severity threshold so that only critical advisories are recorded as alerts in the repository.
Why it is wrong: A configuration that suppresses non-critical advisories would reduce email noise, which is why it seems to match, but it would also stop lower-severity alerts appearing in the security tab and so breaks the requirement to keep all alerts visible for triage. It changes what is detected rather than what is notified.
Granting the engineer the maintain role on every repository, since maintain includes managing Dependabot alerts organisation-wide while withholding administrative actions.
Why it is wrong: The maintain role does sit below admin and withholds some destructive actions, which makes it look like a careful fit, but it is assigned per repository rather than organisation-wide and it also grants the ability to push to protected branches. It overshoots on code access while being tedious to apply everywhere.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.