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.
Recommended Phased Approach โ
| Phase | Action | Goal |
|---|---|---|
| 1. Pilot | Enable GHAS on 2โ5 critical repositories | Learn the alert volume and team response |
| 2. Baseline | Document current vulnerability count | Establish metrics before organization-wide rollout |
| 3. Expand | Enable GHAS on all new repositories first | Prevent new debt from accumulating |
| 4. Remediate | Address existing alerts by severity (Critical โ High โ Medium โ Low) | Reduce existing vulnerability debt |
| 5. Enforce | Enable branch protection + required code scanning checks | Make GHAS part of the development workflow |
| 6. Monitor | Use Security Overview for ongoing tracking | Maintain 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.
| Responsibility | Typical owner |
|---|---|
| Enablement, policy, reporting | Security team, platform team, enterprise admins |
| Daily alert triage and fixes | Repository maintainers and developers |
| Exception approval and dismissal standards | Security leads or designated approvers |
| SLA tracking and remediation backlog | Engineering 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 โ
- Revoke the secret at the service provider immediately
- Audit the provider's access logs for unauthorized use
- Remove the secret from history using
git filter-repo - Resolve the alert with the appropriate reason
- Introduce a process change: push protection, pre-commit hooks, or secrets manager (e.g., HashiCorp Vault, GitHub Actions encrypted secrets)
For Dependabot Alerts โ
- Assess CVSS severity โ prioritize Critical and High
- Check reachability โ is the vulnerable function actually called in your code?
- Apply the fix: Update the dependency (accept the Dependabot PR or update manually)
- Dismiss as tolerable if the vulnerable code path is unreachable in your context
- Long-term: Enable Dependabot security updates (auto-PR) to prevent accumulation
For Code Scanning Alerts โ
- Read the full alert: Understand the data flow from source to sink
- Verify it's a true positive โ not all alerts are exploitable in context
- Fix the code: Apply the recommended remediation (parameterized query, input sanitization, etc.)
- Dismiss false positives with a note explaining why it's not an issue
- 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 โ
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
What is the recommended first GHAS feature to enable when rolling out to an organization?
(Click to reveal)