GH-500 · Domain 5: Security operations: best practices, prioritization, and remediation · 18% of the exam
Task 5.5: Shift left and strengthen preventive security
Catching problems before they land: push protection, dependency review and code scanning on pull requests working together.
Study it
Shifting left with push protection, dependency review and pull request analysis
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 3
An AppSec lead wants to find out where push protection is causing friction and where secrets still slip through. Which three things does the push protection metrics view show? (Choose THREE.)
AThe total number of secrets in each repository's history
BThe secret types blocked or bypassed most often
CThe repositories that bypass push protection most
DThe validity status of each bypassed secret
EThe share of each reason users give when they bypass
Show the answer and why
AThe total number of secrets in each repository's history
Incorrect
That comes from the secret risk assessment.
BThe secret types blocked or bypassed most often
Correct
The view breaks down blocks and bypasses by secret type.
CThe repositories that bypass push protection most
Correct
The view highlights repositories with the most bypasses.
DThe validity status of each bypassed secret
Incorrect
Validity is on the alerts, not in the metrics view.
EThe share of each reason users give when they bypass
Correct
The view shows the percentage distribution of bypass reasons.
The metrics overview for secret scanning push protection in security overview summarizes how many pushes with secrets were blocked and how many times protection was bypassed, with the secret types blocked or bypassed most, the repositories with the most blocked pushes and the most bypasses, and the distribution of bypass reasons.
A team's advanced CodeQL workflow runs on push for every branch and scans the head of each feature branch. Its results sometimes miss problems that only appear once the branch is merged. Which trigger gives more efficient and accurate pre-merge results?
Aon: pull_request, which scans the merge commit of the pull request
Bon: push with paths-ignore for test folders
Con: schedule every hour
Don: workflow_dispatch so developers start scans themselves
Show the answer and why
Aon: pull_request, which scans the merge commit of the pull request
Correct
Scanning the merge commit is more efficient and accurate than scanning each push.
Bon: push with paths-ignore for test folders
Incorrect
That trims runs but still scans heads, not merge results.
Con: schedule every hour
Incorrect
A schedule isn't tied to pull requests.
Don: workflow_dispatch so developers start scans themselves
Incorrect
Manual runs rely on people remembering.
Using the pull_request trigger, configured to scan the pull request's merge commit rather than the head commit, produces more efficient and accurate results than scanning the head of the branch on each push. The push trigger remains useful for the default and protected branches.
Besides pushes from the command line, which of these does push protection check for supported secrets?
ACommits made in the GitHub web editor
BValues saved as Actions secrets in repository settings
COpening a pull request from a branch already pushed
DApproving a pull request review
Show the answer and why
ACommits made in the GitHub web editor
Correct
Push protection also checks commits made in the GitHub UI.
BValues saved as Actions secrets in repository settings
Incorrect
Actions secrets are encrypted settings, not repository content.
COpening a pull request from a branch already pushed
Incorrect
Opening a pull request adds no new commit; the commits were checked when they were pushed.
DApproving a pull request review
Incorrect
A review approval adds no content to check.
Push protection checks pushes from the command line and also commits made in the GitHub UI, among other ways of writing content, and blocks supported secrets before they are stored in the repository.
How do code scanning results appear on a pull request when code scanning runs as a pull request check?
AAs new issues opened in the repository for each finding
BAs Dependabot alerts
COnly in an email to the author
DAs check results and annotations
Show the answer and why
AAs new issues opened in the repository for each finding
Incorrect
Results aren't issues.
BAs Dependabot alerts
Incorrect
Those are for dependencies.
COnly in an email to the author
Incorrect
They are shown on the pull request.
DAs check results and annotations
Correct
Alerts appear as check results and annotations.
Code scanning alerts can appear on pull requests as check results and annotations when code scanning is configured as a pull request check, or scans each push and maps results to open pull requests.
Which repositories can use Copilot Autofix without a GitHub Copilot subscription?
ANone; a Copilot subscription is always needed
BPublic ones, and private ones with Code Security
COnly repositories with AI Scan enabled
DOnly private repositories hosted on GitHub Enterprise Server
Show the answer and why
ANone; a Copilot subscription is always needed
Incorrect
No subscription is needed.
BPublic ones, and private ones with Code Security
Correct
Copilot Autofix is available to them without a Copilot subscription.
COnly repositories with AI Scan enabled
Incorrect
AI Scan isn't required.
DOnly private repositories hosted on GitHub Enterprise Server
Incorrect
That isn't the condition.
You don't need a GitHub Copilot subscription to use Copilot Autofix. It is available to all public repositories on GitHub.com and to internal or private repositories owned by organizations and enterprises with a GitHub Code Security license.