What's changed: New GH-100 Chapter 3 (policies & rulesets = govern member capabilities vs enforce on code changes, enterprise cascade, audit log/SIEM streaming, defense in depth; repo security features = enable vulnerability alerts/secret scanning/CodeQL, default config, Dependabot/advisories, response plan/SECURITY.md; API & integrations = fine-grained PAT/least privilege/revocation, GitHub App vs OAuth App, rate limits, app approval/denial)
3.2Repository Security Features
Understand configuring vulnerability alerts, secret scanning, and CodeQL; managing Dependabot and security advisories; and defining/implementing a security response plan—from an admin’s view.
Admins enable and govern the GHAS (GitHub Advanced Security; GH-500 covers depth) features org-wide and set up the mechanism from detection to response. GH-100 tests, as an admin, configuring features and preparing a response plan for detected issues (deep operations are GH-500’s territory; here it’s admin-view enablement and governance).
3.2.1Vulnerability alerts, secret scanning, and CodeQL
Admins enable, at org/repo level: vulnerability alerts (known dependency vulns, Dependabot-linked), secret scanning (Secret Protection) (detect leaked secrets and Push Protection), and CodeQL (Code Security) (static code analysis). A default security configuration templatizes these for bulk application + inheritance across many repos (shared with GH-500). Admins also know that public repos are largely free while private/enterprise need a GHAS license.
3.2.2Dependabot and security advisories
Dependabot detects dependency vulnerabilities and performs security updates (PRs to safe versions) and version updates (detailed in GH-500). Security advisories (GitHub Advisory Database / repository advisories) are the source of vulnerability info; repo admins can fix privately then publish a vulnerability in their own project. Admins enable these org-wide and set up alert recipients/permissions so remediation doesn’t stall.
3.2.3Security response plan
Beyond setting up detection, define a response plan for "who responds, at what priority, by when"—severity criteria (rulesets can enforce severity-based merge protection, but cannot enforce time-based SLAs), roles and ownership (developer/security manager/admin), escalation, and records (dismissal reasons). This ensures alerts are not neglected but reliably remediated. A repo can also publish a SECURITY.md with the vulnerability-reporting procedure (contact, response policy).
Common: (1) Admins enable vulnerability alerts / secret scanning (Secret Protection) / CodeQL (Code Security) org-wide; use a default security configuration for bulk apply + inherit. Public=free / private=GHAS license. (2) Dependabot detects dependency vulns + auto PRs; security advisories are the vuln-info source (private fix → publish). (3) Beyond detection, define a response plan (who/priority/SLA/roles/records) to prevent neglect. Publish a SECURITY.md for reporting.
Watch out: (1) "Enabling" alone isn’t enough—without a response plan and ownership, detections are neglected. (2) Full features on private/enterprise need a GHAS license (don’t conflate with public=free). (3) Dependabot security updates (vuln-driven) vs version updates (currency) differ. (4) SECURITY.md publishes a reporting procedure, not detection/remediation itself.
3.2.4Section summary
- Enable vulnerability alerts/secret scanning/CodeQL org-wide; default config for bulk apply + inherit
- Dependabot detects dependency vulns + auto PRs; security advisories are the source (private fix → publish)
- Beyond detection, define a response plan (who/priority/SLA/roles/records) to prevent neglect
- Full features on private/enterprise need a GHAS license; publish a SECURITY.md for reporting
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. An admin wants to bulk-enable vulnerability alerts, secret scanning, and CodeQL across many repos and inherit to future repos. What do you use?
Q2. Which detects known dependency vulnerabilities and auto-creates PRs to safe versions?
Q3. What is generally required to use the full GHAS feature set (secret scanning/CodeQL) on private/enterprise?
Q4. What should an admin prepare so detected security issues aren’t neglected?
Q5. What lets you handle a vulnerability in your own project privately until fixed, then publish?
Q6. Which file publishes a repository’s vulnerability-reporting procedure (contact, response policy)?