Alex: Welcome back. Today we're looking at GitHub security features, and this one is bigger than a settings tour. In open source, your project is connected to packages, workflows, tokens, build tools, and other people's code. A weak link in that chain can affect everyone who installs or contributes to the project.

Jamie: So security is not only the maintainer's problem. If I open a pull request, review an alert, or notice something strange, I'm part of the safety system too.

Alex: Exactly. GitHub gives repositories a set of tools for that work: Dependabot for vulnerable dependencies, secret scanning for leaked credentials, code scanning for risky patterns in the code, and private reporting for vulnerabilities that should not be posted in public.

Jamie: I like that framing. We are not trying to become security experts overnight. We are learning what the signals mean and how to respond without making things worse.

Alex: Most of these signals live behind the repository's Security and quality tab. What you see there depends on your access. A public visitor may see the security policy and, if the maintainer enabled it, a private vulnerability reporting form.

Jamie: And if I have write or admin access, I may see more: Dependabot alerts, secret scanning alerts, code scanning alerts, security advisories, and security settings.

Alex: Right. On a repository page, move to the secondary navigation and open the Security link. GitHub also supports the keyboard shortcut G then S, as long as GitHub keyboard shortcuts are available in your current mode.

Jamie: Inside that tab, the alerts are separated by type, right? Dependabot, secret scanning, and code scanning each have their own area, so I should not assume one empty page means everything is clear.

Alex: Yes. Also, severity labels use words like Critical, High, Medium, and Low, not just color. If there are no open alerts, GitHub may show a green shield or a no alerts message, which is a good confirmation to look for.

Alex: Dependabot is GitHub's automated system for watching dependencies. A dependency is a package your project relies on, like an npm package, a Python package, or a GitHub Action. If a known vulnerability is found in one of those packages, GitHub can create a Dependabot alert.

Jamie: Known vulnerability means something like a CVE?

Alex: Yes. CVE stands for Common Vulnerabilities and Exposures, which is a public identifier for a reported security flaw. Dependabot alerts usually tell you the package name, the package ecosystem, the vulnerable version range, the fixed version, the advisory ID, a description, and the severity.

Jamie: And the severity is not just vibes. Critical is roughly a CVSS score from 9.0 to 10.0, High is 7.0 to 8.9, Medium is 4.0 to 6.9, and Low is 0.1 to 3.9.

Alex: Exactly. When you see an alert, read the advisory first. Then check whether the project actually uses the affected code path. Most of the time, the practical fix is to update the dependency to the fixed version.

Jamie: And sometimes Dependabot has already done that work by opening a pull request.

Alex: Yes. Dependabot security updates can automatically open a PR with a title like, bump lodash from 4.17.20 to 4.17.21. The author is dependabot[bot], and the description usually links release notes, changelogs, and commits. Reviewing those PRs, running tests, and merging them when they pass can be a strong contribution.

Jamie: There is also the non-emergency version of this, where Dependabot keeps packages current even when there is no known security issue.

Alex: That is Dependabot version updates. Teams configure it in .github/dependabot.yml. A common setup says version 2, updates for the npm ecosystem in the root directory, run weekly, and keep the number of open Dependabot PRs limited, maybe five at a time.

Jamie: Secrets are the feature that makes people nervous. What counts as a secret here?

Alex: A secret is a credential that grants access, like a token, API key, password, private key, or cloud credential. Secret scanning looks for those patterns in code and commit history. The goal is to catch accidental leaks before someone can use them.

Jamie: And push protection can stop the problem before it reaches the repository, right?

Alex: Right. If you run git push and GitHub detects a known secret pattern, the push can be blocked. The terminal message may include GH013, the commit, the file, the line number, and the secret type, such as a GitHub personal access token.

Jamie: What should I do in that moment? Because my first instinct might be, just delete the line and push again.

Alex: Delete the secret from the file, yes, but also revoke and rotate the credential. Revoke means disable the old secret. Rotate means create a new one and update the service that needs it. GitHub may automatically revoke certain GitHub tokens, but you still need to verify the damage is contained.

Jamie: And if it is a false positive?

Alex: Investigate first. Some systems allow a bypass with a written reason, but bypassing should be rare and deliberate. The safer pattern is to store secrets outside the code, usually in environment variables, so your code reads something like process.env.GITHUB_TOKEN instead of hardcoding a token string.

Jamie: For existing public repositories, secret scanning alerts can also appear after the fact. If an alert says a credential has been sitting in history, treat it as urgent, because it may already be exposed.

Alex: Code scanning is different from Dependabot. Dependabot looks at packages. Code scanning looks at your code. GitHub's built-in engine is CodeQL, which uses static analysis, meaning it examines code without needing to run the app.

Jamie: So it can find patterns like SQL injection or cross-site scripting before a user ever hits that path in production.

Alex: Exactly. It may also flag unsafe data flow, insecure configuration, or places where untrusted input reaches a sensitive operation. A code scanning alert usually includes the rule name, severity, file, line, explanation, and sometimes a path showing how data moves through the program.

Jamie: Where do I find those alerts?

Alex: Open the Security and quality tab, then Code scanning. You can move through the alert list, open one alert, read the affected file and line, and check the recommendation. It is worth reading the full alert before changing code, because the fix is often about the flow of data, not just one line.

Jamie: How does a repository turn CodeQL on?

Alex: Usually through GitHub Actions. In the repository, you add a workflow file under .github/workflows, often a CodeQL workflow that chooses the language, initializes CodeQL, builds if needed, and runs analysis. It can run on pushes, pull requests, and a schedule, so new code gets checked continuously.

Jamie: What if I find something serious that is not already an alert? Like a vulnerability that could expose user data.

Alex: Do not open a public issue with exploit details. If the repository has private vulnerability reporting enabled, go to the Security and quality tab and choose the reporting option. The form lets you privately describe the vulnerability, affected versions or files, reproduction steps, and impact.

Jamie: That gives maintainers a chance to fix it before the whole internet gets a recipe for abuse.

Alex: Yes. Maintainers can triage the report, discuss it privately, prepare a fix, create a security advisory, and publish details when the patch is ready. They may also credit the reporter or request a CVE, depending on the project and severity.

Jamie: And if nobody responds?

Alex: Check the repository's security policy for response expectations. Many projects describe how long to wait and what contact path to use. If there is still no response, follow responsible disclosure norms: avoid posting exploit steps publicly, keep records of your contact attempts, and choose the least harmful way to escalate.

Alex: A SECURITY.md file is the repository's written security policy. It usually explains supported versions, what is in scope, how to report a vulnerability, what information to include, and what response timeline to expect.

Jamie: Where would I find it?

Alex: The Security and quality tab often links to it if it exists. You may also find it at the repository root, inside .github, or in a default community health file for the organization. If you are unsure whether to post publicly or report privately, SECURITY.md is the first document to check.

Jamie: The appendix also mentions SBOMs. That acronym shows up a lot in software supply chain conversations.

Alex: SBOM stands for Software Bill of Materials. It is an inventory of the components and dependencies in a project. In GitHub, when dependency graph data is available, repository maintainers can export an SBOM, often from the dependency graph area, such as Insights, Dependency graph, then Export SBOM.

Jamie: So if a new vulnerability appears in a library, an SBOM helps a team answer, are we using that thing anywhere?

Alex: Exactly. It is not a fix by itself, but it gives teams a clearer map of what the project is built from.

Jamie: Let's slow down on navigation, because security pages can be dense.

Alex: From any repository page, you can Tab to the secondary navigation and open Security, or use G then S if GitHub shortcuts are active for you. Once inside, use headings, links, and tables to move by alert type. In many screen readers, T can help reach tables, and arrow keys can read rows and columns.

Jamie: For Dependabot alerts, I would listen for package name, severity, vulnerable version, fixed version, and advisory link.

Alex: Yes. For code scanning alerts, listen for rule name, severity, file, line, and any data-flow explanation. For the private vulnerability reporting form, move field by field and include impact, reproduction steps, affected area, and any safe supporting details.

Jamie: Low vision learners may need a slightly different tactic.

Alex: Increase browser zoom or terminal font size when reading alert tables and push protection errors. Severity badges include text, so you do not have to rely on color alone. In an editor, syntax highlighting can make environment variable names and accidental hardcoded strings easier to spot.

Alex: Security also connects to the Accessibility Agents work in this course. The Accessibility Agents collection is a living catalog, so the useful move is to inspect the current repository state, not memorize a fixed number of agents.

Jamie: And for Challenge 15, learners browse that catalog first. They are not required to fork the accessibility-agents repository just to complete discovery.

Alex: Right. A security-focused agent or checklist could summarize a repository's current posture: Dependabot alerts open, secret scanning status, code scanning status, open Dependabot PRs, and a recommendation like, review the high-severity dependency update before adding new features.

Jamie: For community-access/accessibility-agents, that means a dashboard should be treated as a current snapshot, not a permanent truth.

Alex: Exactly. A sample output might say, Dependabot alerts: check the Security and quality tab. Secret scanning: verify whether alerts are enabled and whether any are open. Code scanning: review CodeQL results if configured. Dependabot PRs open: review, test, and merge safe updates. Recommendation: keep security maintenance visible alongside accessibility improvements.

Jamie: That also fits the Capstone Project. Challenge 16 can be a contribution to Accessibility Agents, GLOW, or another meaningful repository, and a review-ready draft or contribution plan can be valid evidence when the work is thoughtful and actionable.

Alex: One last habit: use GitHub's code security documentation as the source of record when you need exact behavior. These features change, and repository settings vary by visibility, plan, and maintainer choices.

Jamie: So the workflow is: open the Security and quality tab, identify the alert type, read the details, act carefully, and document what you did.

Alex: Yes. Security work rewards patience. Read before clicking, revoke secrets instead of just deleting them, test dependency updates, keep vulnerability reports private when needed, and use SECURITY.md to respect the project's process.

Jamie: That makes security feel less mysterious. It is still serious, but it becomes a set of careful contribution habits.