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

Apply a secure SDLC using GitHub Security suites, and compare prevention-first approaches with gate-based security strategies and security campaigns.

Apply GitHub Security suites across the secure SDLC by combining shift-left, prevention-first controls with gate-based enforcement. Compare how security campaigns differ from gate-based strategies when driving developer remediation at scale.

secure SDLCprevention-firstgate-based securitysecurity campaignsshift left

Practice question for this objective

Free sampleDescribe GitHub Security suites, features, and ecosystemhard

A security architect is sequencing controls along the secure SDLC and wants each control mapped to the earliest stage where it can stop a problem cheaply, embodying the shift-left principle. They list four controls: push protection blocking a credential at push time, a CodeQL pull request scan flagging a SQL injection before merge, Dependency Review surfacing a vulnerable package on the pull request, and a security campaign driving remediation of alerts already in production. Which ordering correctly arranges these from the earliest, most preventive point in the lifecycle to the latest, most remedial?

APush protection at push time, then Dependency Review and the CodeQL pull request scan together at pull request review, then a security campaign driving remediation in production Correct
BDependency Review on the pull request, then push protection at push time, then a security campaign in production, then the CodeQL pull request scan during review
CA security campaign in production first, then push protection at push time, then the CodeQL pull request scan, then Dependency Review on the pull request during review
DThe CodeQL pull request scan first, then push protection at push time, then Dependency Review on the pull request, then a security campaign driving remediation in production

Order GitHub security controls along the SDLC from earliest prevention (push protection) through pre-merge gates to post-deployment remediation campaigns. Shift-left means catching problems at the earliest, cheapest stage. Push protection stops a secret before it is committed, so it is earliest; Dependency Review and CodeQL pull request scans gate changes before merge; a security campaign remediates findings that are already live, so it is the latest. Correct sequencing follows the moment in the lifecycle at which each control can first act.

Why A is correct: Push protection acts earliest, stopping a secret before it ever lands; Dependency Review and the CodeQL scan act next at the pull request stage as pre-merge gates; and a security campaign is the latest, remedial step that chases down findings already shipped, which matches the shift-left progression.

Why B is wrong: This places Dependency Review and the CodeQL scan, which both act at pull request review, on either side of the campaign, mixing pre-merge gates with post-deployment remediation and putting push protection after a pre-merge check, so the lifecycle ordering is incoherent.

Why C is wrong: Leading with a security campaign puts the most remedial, post-deployment activity first, inverting the shift-left intent, and it also separates the two pull request gates that belong together at the review stage.

Why D is wrong: Push protection acts before any code review begins, so placing it after a pull request scan is wrong; the credential block is the earliest control and cannot sit between two pre-merge checks at review time.

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.

Both are prevention-first controls, because each one stops insecure material before it can ever reach the default branch, regardless of where in the workflow the check happens to run.
Why it is wrong: This is tempting because both controls block something, but a required status check on a pull request is the textbook gate: it evaluates a change at a merge checkpoint rather than stopping the act of introducing the material. Pairing them as identical strategies misses the distinction the question is testing.
Dependabot security updates, which automatically open remediation pull requests for the selected alerts and chase them to completion by the deadline.
Why it is wrong: Dependabot security updates raise pull requests for vulnerable dependencies, which sounds like remediation, but they act only on Dependabot alerts and cannot curate a slice of code scanning alerts, attach guidance, or track a programme against a due date. They automate fixes rather than coordinate a campaign.
The Coverage view, because it plots the proportion of repositories with each feature enabled over time, which shows whether remediation is outpacing new alerts.
Why it is wrong: The Coverage view reports feature enablement across repositories, which is an adoption measure rather than an alert-flow measure. It does not compare the rate of new alerts against the rate of closures, so it cannot tell leadership whether remediation is keeping pace, even though rising coverage is a related story.

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