GitHub Advanced Security (GHAS) is no longer one product — as of the November 2024 Universe announcement, it's sold as two separate paid add-ons, GitHub Secret Protection and GitHub Code Security, each billed per active committer per month. That price tag leads a lot of maintainers to assume real repository protection lives entirely behind a paywall. It doesn't. GitHub ships a substantial security toolkit for free — on every public repository, and on most private ones too: two-factor authentication enforcement, secret scanning with push protection, Dependabot alerts and automated security updates, private vulnerability reporting, and branch protection rules. Teams that skip these because they've mentally filed "GitHub security" under "the expensive add-on we haven't budgeted for" are leaving high-value, zero-cost controls switched off. Below are six GitHub repository security settings you can turn on today at no cost, what each one actually catches, where GHAS still adds real depth, and how Safeguard closes the gaps that sit outside GitHub's settings page entirely.
Why should two-factor authentication be the first setting every maintainer enforces?
Because compromised maintainer accounts, not zero-day exploits, are how most malicious code has actually entered open source projects in the last five years. The ua-parser-js npm package was hijacked via a stolen maintainer credential in October 2021 and pushed to millions of weekly downloads before removal. The XZ Utils backdoor (CVE-2024-3094), discovered on March 29, 2024, was the product of a two-year social engineering campaign specifically aimed at earning commit access from an overworked maintainer — not a code flaw. GitHub itself concluded 2FA was important enough to make mandatory: it began phasing in required two-factor authentication for code contributors in 2022 and completed the rollout to all qualifying contributor accounts by the end of 2023. If you maintain a repository, verify enforcement under Organization Settings → Authentication security → "Require two-factor authentication for everyone in your organization." It costs nothing and closes the single most exploited entry point in supply chain attacks.
What does free secret scanning actually catch that GitHub Advanced Security charges for?
Free secret scanning on public repositories detects and alerts on live credentials — AWS keys, Stripe tokens, Slack webhooks, and roughly 200 other partner-defined token formats — the moment they're committed, and push protection (GA for public repos since early 2023) blocks the push before the secret ever lands in git history. What costs money is running that same detection on private repositories at scale, plus the custom pattern matching, validity checks against live provider APIs, and organization-wide enforcement policies that come with the paid GitHub Secret Protection SKU. If your project is public, there's no excuse: go to Settings → Code security → enable both "Secret scanning" and "Push protection." If it's private, at minimum enable secret scanning alerts through a GitHub Team or Enterprise plan, since a leaked credential in a private repo is just as usable by an attacker as one in a public repo — it's simply harder for anyone to warn you about it.
Are Dependabot alerts and security updates really free on private repositories?
Yes — GitHub made Dependabot alerts and automated security update pull requests free on every repository, public and private, back in 2022, and that hasn't changed since. Dependabot cross-references your dependency graph (also free, and required for alerts to work) against GitHub's Advisory Database, which aggregates entries from the National Vulnerability Database, GitHub Security Advisories, and ecosystem-specific sources like npm and RustSec. When a match is found, Dependabot opens a pull request bumping the affected package to a patched version automatically. The setting lives at Settings → Code security → "Dependabot alerts" and "Dependabot security updates" — both toggle on individually, and both should be on for every repository your team owns, not just the flagship ones. Teams frequently discover, when auditing a portfolio of 50+ repos, that Dependabot was silently disabled on a third of them because a repo was forked or transferred and settings didn't carry over.
How does private vulnerability reporting close the gap in public issue trackers?
It gives outside security researchers a private channel to disclose a vulnerability directly to maintainers instead of filing a public GitHub issue that tips off attackers before a fix ships. Private vulnerability reporting has been free and generally available since September 2022, but it's opt-in per repository — you have to explicitly enable it under Settings → Security → "Private vulnerability reporting." Once enabled, a reporter can open a private security advisory draft that only maintainers and invited collaborators see, giving your team room to work through the industry-standard 90-day coordinated disclosure window without a public countdown clock. Projects that leave this off are effectively telling researchers their only reporting option is a public issue — which means either the researcher stays silent (and you never learn about the bug) or they disclose in the open before you've patched it. Neither outcome is good, and both are avoidable with one checkbox.
Which branch protection rules stop force-pushes and unreviewed merges from reaching main?
The combination of "Require a pull request before merging" with at least one approving review, "Require status checks to pass," and "Block force pushes" is what actually prevents a single compromised or careless commit from landing directly on your default branch. These classic branch protection rules — and the newer, more flexible repository rulesets that GitHub rolled out through 2023–2024 — are free on every public repository, and included at no extra cost on private repositories for GitHub Team and Enterprise plans. Add "Require signed commits" if your project accepts external contributions, so every merge carries verifiable authorship rather than a plausible-looking git config user.email. Configure these under Settings → Branches → Branch protection rules, and pair them with a CODEOWNERS file so security-sensitive paths (CI config, dependency manifests, auth code) always require review from someone who owns that area — a control that costs nothing but a text file at the repo root.
Can GitHub's free dependency graph replace a paid SBOM tool?
Partially, but not entirely. The dependency graph automatically builds a real-time software bill of materials for every manifest GitHub recognizes (package.json, requirements.txt, go.mod, and dozens more) and lets you export it in SPDX format free of charge, which satisfies a lot of baseline compliance asks. What it can't see is anything that isn't declared in a manifest: dependencies pulled dynamically at build time, artifacts fetched from internal registries, or packages introduced through a compromised CI step rather than a source file — exactly the vector used in the 2020 SolarWinds Orion attack and the 2021 Codecov bash uploader compromise, neither of which would show up in a manifest-based dependency graph no matter how current it is. That's the specific depth GHAS's dependency review action, and commercial software composition analysis tools generally, are built to add.
How Safeguard Helps
The six settings above are the right free foundation, but they all live inside a single GitHub repository's settings page — they don't tell you what happened inside your build pipeline, whether a dependency's published artifact matches its source, or whether the same typosquatted package name is being pulled into three different repos across your organization at once. Safeguard sits above the repo-settings layer to cover exactly that gap: it continuously verifies build provenance and SBOMs against what actually shipped, flags dependency confusion and typosquat risk before a package lands in a lockfile, and gives security teams a single view across every repository and registry your organization touches, on GitHub or elsewhere. Where GitHub's free tools protect the front door of an individual repo, Safeguard watches the supply chain that feeds it — so enabling all six settings above is the right first step, and Safeguard is what makes sure that step isn't the last line of defense you have.