GH-500 - Describe GitHub Security suites, features, and ecosystem (18% of the exam) - Section 1.4

Identify vulnerability and secret detection mechanisms and choose how to act on, dismiss, or ignore security alerts across roles.

Identify how GitHub generates vulnerability and secret detection alerts and understand the actions available to developers versus security managers. Choose when to act on, dismiss, or ignore an alert, and recognise the audit trail created by each decision.

security alertsalert managementdismissing alertsdeveloper and security responsibilities

Practice question for this objective

Free sampleDescribe GitHub Security suites, features, and ecosystemmedium

An organisation wants to define how alert handling is divided between developers and the security team. Developers should remediate findings in their own repositories, but the organisation wants to make sure that closing certain critical alerts is not left solely to individual developers. Which approach reflects how GitHub supports this division of responsibility for security alerts?

AClosing any security alert always requires organisation owner permission, so developers with write access can only view and comment on alerts in their own repositories and never dismiss them.
BDevelopers and the security team share one identical permission level, so any alert action one can take the other can take, with no way to differentiate.
COnly the security manager role can dismiss alerts across the organisation, and developers with write access are limited to commenting on findings without ever changing an alert's state.
DDevelopers with write access can triage and dismiss alerts in their repositories, while the security manager role gives a central team alert visibility and control of security settings across repositories. Correct

Map alert-handling duties to GitHub roles, where write-access developers triage and dismiss findings and the security manager role gives a central team cross-repository oversight. GitHub supports separation of duties through repository roles and the security manager role. Developers with write access remediate and dismiss alerts in repositories they own, while the security manager role grants a central team read access to alerts and management of security settings across the organisation. This balances developer remediation with organisation-level oversight rather than collapsing or over-restricting either side.

Why A is wrong: This overstates the restriction: developers with write access can typically triage and dismiss alerts in repositories they work on. Reserving every dismissal for organisation owners would make routine remediation unworkable, so this misrepresents the default permission model.

Why B is wrong: GitHub distinguishes capabilities by repository role and by the security manager role, so the two groups are not forced into identical permissions. Claiming there is no way to differentiate ignores the role-based controls that exist precisely to separate these duties.

Why C is wrong: This wrongly strips developers of the ability to act on their own findings. Write access already permits dismissing alerts, so restricting all state changes to the security manager role would block the day-to-day remediation developers are expected to perform.

Why D is correct: This matches the model: repository write access lets developers triage and dismiss their own findings, and the security manager role grants a central team visibility into alerts and control of security configuration across the organisation. The two roles together divide remediation from oversight.

See more GH-500 practice questions, answers explained.

Exam traps in Describe GitHub Security suites, features, and ecosystem

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.

Buying Secret Protection enables secret scanning, push protection, and code scanning with CodeQL, because both belong to the same Advanced Security licence and cannot be purchased apart.
Why it is wrong: This reflects the older single-licence model where the two arrived together, which makes it tempting. Since the split into two standalone products, code scanning sits under GitHub Code Security and is not included when only Secret Protection is purchased, so this is no longer correct.
The Security tab of one representative repository, which rolls up alerts from all sibling repositories in the organisation.
Why it is wrong: A repository Security tab is scoped to that single repository only and does not aggregate sibling repositories. It is tempting because that tab does list all alert types, but only for the one repository it belongs to.
Dismissing the first alert permanently silences the package, so no further Dependabot alerts are raised for it regardless of new advisories.
Why it is wrong: This is tempting because dismissal removes an alert from the open list, but dismissal is scoped to a single advisory, not to the whole package. New advisories for the same dependency still surface as fresh alerts.

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