GH-500 - Describe GitHub Security suites, features, and ecosystem - 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.

More in this domain

Back to all Describe GitHub Security suites, features, and ecosystem objectives, or the GH-500 cert hub.

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