-
Notifications
You must be signed in to change notification settings - Fork 6
appendix p security features
Listen to Episode 29: GitHub Security Features - a conversational audio overview of this chapter. Listen before reading to preview the concepts, or after to reinforce what you learned.
Reference companion to: Chapter 08: Open Source Culture | Also relevant: Chapter 17
Authoritative source: GitHub Docs: Code security
Who this is for: Anyone contributing to open source repositories needs to understand how GitHub protects code and what security alerts mean. This appendix explains the GitHub Security and quality tab, how to interpret and respond to alerts, and how to responsibly report vulnerabilities - including in
community-access/accessibility-agents.
- The Security and quality tab - What It Contains
- Dependabot - Automated Dependency Updates
- Secret Scanning - Preventing Credential Leaks
- Code Scanning and CodeQL
- Private Vulnerability Reporting
- The SECURITY.md File
- Software Bill of Materials (SBOM)
- Screen Reader Navigation of the Security and quality tab
- Security and Accessibility Agents
Every GitHub repository has a Security and quality tab in its navigation bar. What you see there depends on whether you are a contributor with elevated access or a public viewer.
- Security policy (if the repo has a
SECURITY.md) - The private vulnerability reporting form (if enabled by the maintainer)
- Dependabot alerts
- Secret scanning alerts
- Code scanning alerts
- Security advisories
- The ability to manage security settings
On any repository page:
Tab navigation → secondary nav region → "Security" link → Enter
Or: G then S (GitHub keyboard shortcut - enable Focus Mode first)
Screen reader users
- Use G then S (GitHub keyboard shortcut) to jump directly to the Security and quality tab from any repo page — much faster than Tab-navigating the full nav bar
- The Security and quality tab content varies by your access level — public viewers see only the security policy and vulnerability reporting form; contributors with write access see alerts
- Dependabot alerts, secret scanning alerts, and code scanning alerts are each a separate link inside the Security and quality tab — use K to navigate between them
Low vision users
- The Security and quality tab link sits in the repository's top navigation bar alongside Code, Issues, PRs, and Actions — zoom in if the tab labels are small
- Alert severity badges (Critical, High, Medium, Low) use colored labels — each badge also includes the severity word, so color is not the only indicator
- If the Security and quality tab shows "No alerts," that is good news — look for the green shield icon next to the tab name as confirmation
Sighted users
- Find the Security and quality tab in the repository navigation bar — it shows a shield icon and may display a count badge if alerts exist
- Inside the Security and quality tab, the left sidebar lists Dependabot, Secret scanning, and Code scanning as separate pages — click each to see its alert list
- A green shield on the repo home page (or no security count badge) means zero open security alerts
Dependabot is GitHub's automated dependency monitoring and update system. It does two things:
When a known security vulnerability (CVE - Common Vulnerability and Exposure) is discovered in a package your project depends on, GitHub creates a Dependabot alert.
| Level | CVSS Score Range | What it means |
|---|---|---|
| Critical | 9.0-10.0 | Exploit likely, wide impact - fix immediately |
| High | 7.0-8.9 | Significant risk - fix this sprint |
| Medium | 4.0-6.9 | Some risk with specific conditions - schedule fix |
| Low | 0.1-3.9 | Low likelihood of exploitation - fix when convenient |
Alert: Dependabot alert #5
Severity: High
Package: lodash (npm)
Vulnerable version: < 4.17.21
Fixed version: 4.17.21
Advisory: GHSA-35jh-r3h4-6jhm
Description: Prototype pollution vulnerability allows an attacker to
modify Object.prototype leading to denial of service or remote code execution.
- Read the advisory to understand the vulnerability scope
- Check whether the project actually uses the vulnerable code path
- The fix is almost always: update the dependency to the fixed version
- Dependabot Security Updates may have already opened a PR - check the PRs tab
If enabled, Dependabot automatically opens a PR to update the vulnerable dependency. The PR will look like:
Title: Bump lodash from 4.17.20 to 4.17.21
Author: dependabot[bot]
Description: Bumps lodash from 4.17.20 to 4.17.21.
- Release notes
- Changelog
- Commits (linked)
As a contributor with access, reviewing and merging these Dependabot PRs is a high-value, low-risk way to contribute.
Beyond security fixes, Dependabot can be configured to open PRs keeping all dependencies at their latest versions (not just security fixes). This is configured in .github/dependabot.yml.
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5Secret scanning detects if you accidentally commit tokens, API keys, passwords, or other credentials to a repository.
Push Protection intercepts a git push before it reaches GitHub and blocks it if it detects a known secret pattern.
If your push is blocked:
remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: Push cannot contain secrets
remote:
remote: - commit: abc123 in file: config.js
remote: secret: GitHub Personal Access Token
remote: location: line 5
- Remove the secret from the file immediately
- Rotate the exposed credential (GitHub will automatically revoke detected GitHub tokens)
- If it was a false positive, you can bypass with justification - but investigate first
Best practice: Use environment variables for secrets, never hardcode them. Example:
// BAD - never do this
const token = "ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
// GOOD
const token = process.env.GITHUB_TOKEN;For public repositories, GitHub scans all existing commits and creates alerts for any detected secrets. These appear in Security → Secret scanning.
Priority action: If you find a secret scanning alert in a project you contribute to - especially a token or API key - treat it as urgent. The credential may have been exposed for a long time.
Screen reader users
- If your
git pushis blocked with "GH013: Repository rule violations found," the terminal output lists the exact file, line number, and secret type — read the error lines carefully - After removing the secret from your code, use environment variables instead (
process.env.GITHUB_TOKEN) — your screen reader will confirm the variable name in the code - Secret scanning alerts appear under Security and quality tab, Secret scanning — navigate with T to reach the alert table, then arrow keys to read each row
Low vision users
- Push Protection error messages appear in your terminal with red text — increase terminal font size to read the file path, line number, and secret type clearly
- The secret scanning alert list in the Security and quality tab uses a table layout — zoom in to read the Secret type and Location columns
- Environment variable names in code (like
process.env.GITHUB_TOKEN) are easier to spot when syntax highlighting is enabled in your editor theme
Sighted users
- Push Protection errors show a red banner in your terminal with the exact commit, file, and line containing the secret — look for the "secret:" label
- In the Security and quality tab, secret scanning alerts are listed with a yellow or red severity icon — click any alert to see the exposed credential's location and revocation status
- The code examples in this section show the BAD vs. GOOD pattern — never hardcode tokens; always use environment variables as shown
Code scanning uses static analysis to find security vulnerabilities in the code itself (not dependencies). GitHub's built-in tool is CodeQL, which understands the code's logic and can detect:
- SQL injection risks
- Cross-site scripting (XSS) vulnerabilities
- Path traversal issues
- Insecure cryptography usage
- Authentication bypasses
- Command injection risks
Alert: Uncontrolled format string
Rule: py/tainted-format-string
Severity: High
File: src/utils/logger.py
Line: 47
Details:
logging.info(user_input) ← user_input flows unsanitized into format string
Flow:
1. User input enters at: request.args.get('message') [line 12]
2. Passed to: logger.info(message) [line 47]
3. Risk: format string injection if message contains %s, %d patterns
As a contributor: Code scanning alerts are excellent, well-scoped contribution opportunities. Each alert shows you the exact file, line, and the data flow causing the issue. Fixing it is often a one-line change.
Security and quality tab → Code scanning → filter by severity, rule, or file.
When you discover a security vulnerability in a project, never report it as a public issue. A public issue immediately broadcasts the vulnerability to anyone who could exploit it.
GitHub provides Private Vulnerability Reporting - a disclosure form that sends your report only to the repository's security team, not to the public.
- Navigate to the repository's Security and quality tab
- Select "Report a vulnerability" (this button only appears if the maintainer has enabled private reporting)
- Fill in the form:
- Title: Short description of the vulnerability
- Description: Detailed explanation, how to reproduce it, and impact
- Severity: Your assessment
- Affected versions: Which versions are vulnerable
- CVSS score: Optional - the Common Vulnerability Scoring System rating
- Submit - only the maintainers see your report
After you submit:
- Maintainers acknowledge your report (typically within 1-7 days for active projects)
- They may ask follow-up questions in the private advisory thread
- They develop and test a fix
- They request a CVE (Common Vulnerability and Exposure) number from GitHub
- They publish a new release with the fix
- They publish a public security advisory - you may be credited as the reporter
- The CVE is published publicly (usually 90 days after report or after the fix is released)
If a maintainer doesn't respond within a reasonable time (30-90 days is the standard window):
- Send a follow-up in the private advisory thread
- Contact GitHub directly if the issue is critical (GitHub can assist with coordinated disclosure)
- Follow the project's SECURITY.md for their stated disclosure policy
A SECURITY.md file at the repository root defines the project's security policy. It typically contains:
- Supported versions: Which versions receive security patches
- Reporting instructions: How to report a vulnerability (email, private advisory form, etc.)
- Response timeline: How quickly maintainers aim to respond
- Disclosure policy: When the project will publish a fix publicly
accessibility-agents's security policy: community-access/accessibility-agents has a SECURITY.md that points to GitHub's private advisory form. If you find a security issue in accessibility-agents - even a potential one - use the private advisory form rather than opening a public issue.
From the repository:
- Security and quality tab → Policies section → "Security policy" link
- Or directly:
https://github.com/owner/repo/security/policy
Screen reader path:
Security and quality tab → H → "Policy" heading → Link: "Security policy" → Enter
An SBOM is a machine-readable inventory of every component (libraries, packages, dependencies) in a software project. It is increasingly required by enterprise and government organizations for supply chain security compliance.
- Navigate to the repository's Insights tab
- Select "Dependency graph"
- Select "Export SBOM" button (top right of the Dependency graph page)
- GitHub generates a SPDX-format JSON file listing all dependencies with their versions and licenses
This export is useful when:
- Your organization requires SBOM documentation before adopting an open source dependency
- You're auditing a project's complete dependency chain
- You want to identify license compatibility for a commercial product
From any repo page:
Secondary navigation landmark → Tab through: Code, Issues, PRs, Actions, Projects, Wiki, Security
Or: Focus Mode → G then S (GitHub shortcut)
Security and quality tab → select "Dependabot alerts" link
Alert list is a table: T (NVDA/JAWS Browse Mode) → navigate rows
Each row: Tab to expand → Enter to open full alert details
Inside an alert:
H → navigate: Alert title, Package details, Description, References headings
2 → jump between major sections
Links → navigate to the GHSA advisory, the vulnerable package, the Dependabot PR
Security and quality tab → select "Code scanning" link
Alert list: T to find the table → ↑/↓ to navigate rows
Open an alert: Enter
Inside the alert:
H → Alert title, Description, Code flow, Steps headings
Links → navigate to the specific file and line
The code flow section shows the path from source to sink:
Navigate with ↓ through the flow steps
Security and quality tab → "Report a vulnerability" button → Enter
Form fields: F or E → cycle through: Title, Description, Severity (select), Versions, CVSS
Describe field: NVDA+Space → Focus Mode → type → NVDA+Space to leave
Submit: Tab → "Submit report" button → Enter
Accessibility Agents' /security-dashboard slash command gives you a quick security overview without visiting the Security and quality tab in the browser:
/security-dashboard
## Security Dashboard - community-access/accessibility-agents
### Dependabot Alerts
- 0 Critical
- 1 High: actions/cache < 3.3.2 (fixed: 3.3.3)
- 2 Medium: misc dependency updates available
### Secret Scanning
- No active alerts
### Code Scanning
- Last scan: 2 days ago - 0 new alerts
### Dependabot PRs Open
- #47: Bump actions/cache from 3.3.1 to 3.3.3
"Review and merge to resolve the High severity alert"
### Recommendation
Action needed: Review PR #47 (5 minutes - single file change)
Next: Appendix Q: GitHub Actions
Back: Appendix O: Branch Protection
Teaching chapter: Chapter 08: Open Source Culture