Skip to content

Domain 6: Describe GitHub Advanced Security best practices (20%) โ€‹

โ† Domain 5 ยท Next Domain โ†’

Exam Tip

This domain tests your knowledge on how to deploy GHAS effectively in an organization without overwhelming developers. Expect questions on phased rollouts and what to do when alerts trigger (corrective measures).


GHAS Rollout Strategy โ€‹

Enabling GHAS across an organization should be done incrementally to avoid overwhelming teams with alerts and disruption.

PhaseActionGoal
1. PilotEnable GHAS on 2โ€“5 critical repositoriesLearn the alert volume and team response
2. BaselineDocument current vulnerability countEstablish metrics before organization-wide rollout
3. ExpandEnable GHAS on all new repositories firstPrevent new debt from accumulating
4. RemediateAddress existing alerts by severity (Critical โ†’ High โ†’ Medium โ†’ Low)Reduce existing vulnerability debt
5. EnforceEnable branch protection + required code scanning checksMake GHAS part of the development workflow
6. MonitorUse Security Overview for ongoing trackingMaintain visibility and accountability

TIP

Start with secret scanning first โ€” it produces the most immediately actionable alerts (exposed credentials) and has the clearest remediation path (revoke and rotate). Then layer in Dependabot and code scanning.


Governance and Ownership โ€‹

GHAS works best when ownership is explicit.

ResponsibilityTypical owner
Enablement, policy, reportingSecurity team, platform team, enterprise admins
Daily alert triage and fixesRepository maintainers and developers
Exception approval and dismissal standardsSecurity leads or designated approvers
SLA tracking and remediation backlogEngineering managers and security program owners

Practical Ownership Model โ€‹

  • Security teams define guardrails, severity thresholds, and rollout policy
  • Developers fix issues in the normal pull request workflow
  • Repository rulesets and branch protection enforce the minimum bar consistently

SBOM (Software Bill of Materials) โ€‹

GitHub can export a Software Bill of Materials โ€” a complete inventory of all dependencies in a repository. This is critical for software supply chain best practices.

Exporting an SBOM โ€‹

  • UI: Insights โ†’ Dependency graph โ†’ Export SBOM
  • API: GET /repos/{owner}/{repo}/dependency-graph/sbom
  • Format: SPDX (Software Package Data Exchange) JSON

Use cases: Supply chain audits, compliance requirements (e.g., US Executive Order on cybersecurity), license inventory.


Corrective Measures โ€‹

For Secret Scanning Alerts โ€‹

  1. Revoke the secret at the service provider immediately
  2. Audit the provider's access logs for unauthorized use
  3. Remove the secret from history using git filter-repo
  4. Resolve the alert with the appropriate reason
  5. Introduce a process change: push protection, pre-commit hooks, or secrets manager (e.g., HashiCorp Vault, GitHub Actions encrypted secrets)

For Dependabot Alerts โ€‹

  1. Assess CVSS severity โ€” prioritize Critical and High
  2. Check reachability โ€” is the vulnerable function actually called in your code?
  3. Apply the fix: Update the dependency (accept the Dependabot PR or update manually)
  4. Dismiss as tolerable if the vulnerable code path is unreachable in your context
  5. Long-term: Enable Dependabot security updates (auto-PR) to prevent accumulation

For Code Scanning Alerts โ€‹

  1. Read the full alert: Understand the data flow from source to sink
  2. Verify it's a true positive โ€” not all alerts are exploitable in context
  3. Fix the code: Apply the recommended remediation (parameterized query, input sanitization, etc.)
  4. Dismiss false positives with a note explaining why it's not an issue
  5. Re-scan to confirm the alert is resolved

Corrective Measure Principles โ€‹

  • Revoke or contain first, then clean up history or code
  • Fix the root cause, not only the individual alert
  • Document dismissals so future reviewers understand the decision
  • Prefer earlier controls such as push protection, dependency review, and PR-time code scanning to reduce recurring issues

GHAS Best Practices Summary โ€‹

Enable Features in the Right Order โ€‹

text
1. Secret scanning + push protection     (highest ROI, fastest results)
2. Dependabot alerts + security updates  (continuous dependency protection)
3. Dependency review action              (block new vulnerable deps in PRs)
4. Code scanning (default setup)         (SAST for code vulnerabilities)
5. Code scanning (advanced setup)        (customize when needed)

Reduce Alert Fatigue โ€‹

  • Use push protection to prevent secrets from being committed in the first place (fewer alerts to manage)
  • Enable Dependabot security updates to auto-fix before alerts accumulate
  • Tune CodeQL to security-extended (not security-and-quality) to reduce noise
  • Triage and dismiss false positives promptly to keep alert queues clean

Study Heuristics for the Exam โ€‹

  • If the scenario is about preventing a bad change in a pull request, think dependency review, code scanning on PR, or required checks
  • If the scenario is about reducing blast radius for leaked credentials, think revoke, rotate, push protection
  • If the scenario is about organization-wide adoption, think pilot first, baseline, expand, enforce, monitor

Domain 6 Quick Quiz

1 / 4
โ“

What is the recommended first GHAS feature to enable when rolling out to an organization?

(Click to reveal)
๐Ÿ’ก
Secret scanning with push protection โ€” it delivers the highest immediate ROI (prevents credential exposure), has the clearest remediation path (revoke and rotate), and produces actionable alerts fastest.

โ† Domain 5 ยท Next Domain โ†’

Happy Studying! ๐Ÿš€ โ€ข Privacy-friendly analytics โ€” no cookies, no personal data
Privacy Policy โ€ข AI Disclaimer โ€ข Report an issue