GH-500 · Domain 1: Describe GitHub Security suites, features, and ecosystem · 19% of the exam
Task 1.2: Apply secure SDLC and security strategies
How the two products work together across the delivery lifecycle, prevention at the source versus gates before merge, and how security campaigns burn down existing risk.
Study it
A secure SDLC on GitHub: prevention at the source, gates before merge, campaigns for the backlog
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 1
A team protects main with a ruleset that requires a secret-scanner workflow to pass on every pull request before merging. A review finds that a contributor pushed a live token for a supported provider to an experimental branch that never had a pull request, and the token sat in the repository's history on GitHub for weeks. Which change stops this kind of leak at its source?
AMake the scanner workflow a required status check on pull requests into every branch
BAdd a code scanning rule that requires CodeQL results before merging
CEnable push protection so that a push with a supported secret is rejected
DEnable validity checks so that active tokens are ranked first in the alert list
Show the answer and why
AMake the scanner workflow a required status check on pull requests into every branch
Incorrect
The check still runs only once a pull request exists, after the commit is already stored on GitHub.
BAdd a code scanning rule that requires CodeQL results before merging
Incorrect
CodeQL analyzes code for vulnerabilities, not leaked tokens, and the rule also acts only at merge.
CEnable push protection so that a push with a supported secret is rejected
Correct
Push protection checks pushes and blocks a supported secret before it is saved to the repository.
DEnable validity checks so that active tokens are ranked first in the alert list
Incorrect
Validity checks help you prioritize alerts that already exist; they don't stop the leak.
A required check on pull requests is a gate: it runs only when a pull request exists, so a commit pushed to a branch without one is already stored on GitHub and is never checked. Push protection is the prevention-first control: it checks every push, whether or not a pull request follows, and blocks supported secrets before they reach the repository.
A security manager plans a security campaign for SQL injection alerts and wants each affected repository to get a tracking issue. Some of the alerts exist only on long-lived release branches that are never merged back. What should the manager expect?
AThe release-branch alerts are included, and every repository gets a tracking issue
BTracking issues are available only in secret scanning campaigns
CThe campaign has to be split into one campaign per branch before it can be published
DOnly default-branch alerts can be included, and tracking issues work for this campaign
Show the answer and why
AThe release-branch alerts are included, and every repository gets a tracking issue
Incorrect
Code campaigns take only alerts that are present on the default branch.
BTracking issues are available only in secret scanning campaigns
Incorrect
It's the other way round: repository tracking issues are supported for code campaigns, not secret campaigns.
CThe campaign has to be split into one campaign per branch before it can be published
Incorrect
Campaigns aren't scoped by branch; code alerts simply come from the default branch.
DOnly default-branch alerts can be included, and tracking issues work for this campaign
Correct
Code campaigns include alerts from the default branch only, and they support repository tracking issues.
Campaigns for code scanning alerts include alerts from the default branch only, and they support repository tracking issues. Campaigns for secret scanning alerts (in public preview) include alerts regardless of branch and don't support tracking issues.
A team already uses Dependabot security updates. Why does GitHub suggest also turning on Dependabot version updates as part of a secure development lifecycle?
ASecurity updates can run only where version updates are enabled
BVersion updates also scan the team's code for injection flaws
CVersion updates close open Dependabot alerts every week
DUp-to-date dependencies make later patches easier to apply
Show the answer and why
ASecurity updates can run only where version updates are enabled
Incorrect
Security updates don't depend on version updates being turned on.
BVersion updates also scan the team's code for injection flaws
Incorrect
Finding flaws in the team's own code is the job of code scanning.
CVersion updates close open Dependabot alerts every week
Incorrect
They raise pull requests to newer versions; they don't close alerts on a schedule.
DUp-to-date dependencies make later patches easier to apply
Correct
Newer versions make it easier to apply patches and for security updates to raise their pull requests.
Dependabot version updates raise pull requests that keep dependencies up to date. Using newer versions makes it easier to apply patches when vulnerabilities are discovered, and makes it easier for Dependabot security updates to raise pull requests that upgrade vulnerable dependencies.
ATo group alerts and work with developers to fix them at scale
BTo scan repositories that don't have code scanning enabled
CTo approve push protection bypass requests
DTo purchase licenses for more committers
Show the answer and why
ATo group alerts and work with developers to fix them at scale
Correct
Campaigns group alerts and share them with developers to burn down the backlog.
BTo scan repositories that don't have code scanning enabled
Incorrect
Campaigns don't run scans.
CTo approve push protection bypass requests
Incorrect
Bypass requests are reviewed through delegated bypass.
DTo purchase licenses for more committers
Incorrect
Campaigns aren't a billing feature.
Security campaigns group alerts, for example a set of related code scanning alerts or exposed secrets, and share them with developers so security and development teams can fix them together and reduce security debt.
A reviewer wants to see, before merging, whether a pull request adds a package with a known vulnerability. Which feature shows this?
ADependabot version updates
BDependency review
CSecret scanning
DThe tool status page
Show the answer and why
ADependabot version updates
Incorrect
Version updates open pull requests to update dependencies.
BDependency review
Correct
Dependency review shows dependency changes and their vulnerabilities in the pull request.
CSecret scanning
Incorrect
Secret scanning looks for credentials.
DThe tool status page
Incorrect
The tool status page reports on code scanning tools.
Dependency review shows the dependency changes in a pull request, including whether added or updated dependencies have known vulnerabilities, so problems can be avoided before merge.
A security manager has built a filter for a new security campaign but isn't sure which alerts it will pull in. She wants to review those alerts with colleagues before any developer hears about the campaign. What should she do?
APublish the campaign without a contact link, so that developers aren't notified
BRun a dry run of the filter, as for a custom pattern
CCreate the campaign as a draft and review it before publishing
DCreate the campaign in a separate test organization first
Show the answer and why
APublish the campaign without a contact link, so that developers aren't notified
Incorrect
Publishing shares the campaign with developers whether or not it has a contact link.
BRun a dry run of the filter, as for a custom pattern
Incorrect
Dry runs test custom secret patterns; campaigns don't have them.
CCreate the campaign as a draft and review it before publishing
Correct
A draft campaign lets you review the included alerts and collaborate internally before you publish it.
DCreate the campaign in a separate test organization first
Incorrect
A campaign selects alerts in its own organization, so a test organization would show different alerts.
When you're unsure about a campaign's scope, create a draft campaign first. A draft lets you review the alerts that will be included and collaborate internally before publishing; publishing is the step that shares the campaign with developers.