6 GitHub security settings every maintainer should enable now

Key Takeaways

• GitHub's native security features are free but disabled by default on most repositories
• Secret scanning and Dependabot can catch vulnerabilities before they reach production
• Branch protection rules prevent unauthorized code from entering your main branch

GitHub published a guide urging repository maintainers to enable six security settings that ship free with the platform but remain off by default. The recommendation comes as software supply chain attacks continue rising, with incidents like the xz-utils backdoor reminding developers that attackers increasingly target open source infrastructure.

The guide was written by Joseph, a security educator whose open source game gh.io/scg has trained over 10,000 developers on secure coding practices. His security content has accumulated more than 2.8 million views, and he has delivered 79 talks across 25 countries over the past four years. The settings he recommends take minutes to configure but address the most common attack vectors maintainers face.

Why these settings matter right now

GitHub hosts over 100 million developers. Most of them have never opened the Security tab in their repository settings. That gap between available tools and actual usage explains why compromised credentials and vulnerable dependencies still dominate breach reports.

The platform already includes secret scanning, dependency analysis, and access controls. But GitHub ships repositories with permissive defaults. A new maintainer can push code, merge pull requests, and accept contributions without ever encountering a security prompt. The guide argues this needs to change at the individual repository level until GitHub adjusts its defaults.

What settings does GitHub recommend?

The six settings fall into three categories: catching secrets before they leak, monitoring dependencies for known vulnerabilities, and controlling who can merge code into protected branches.

Secret scanning detects API keys, tokens, and credentials accidentally committed to a repository. GitHub partners with cloud providers to recognize their credential formats, and the feature can block pushes containing secrets before they ever reach the remote. This matters because secrets pushed to public repositories get scraped within seconds by automated bots.

Dependabot handles dependency vulnerabilities. It monitors your package manifests, compares them against the GitHub Advisory Database, and opens pull requests to update vulnerable packages. For teams that struggle to keep dependencies current, Dependabot automates the tedious version bumping that otherwise gets ignored until an audit forces the issue.

Branch protection rules control merge permissions on critical branches. You can require pull request reviews, passing status checks, and signed commits before code reaches main. Without these rules, any collaborator with write access can push directly to production branches.

How long does setup actually take?

Enabling secret scanning and push protection takes about two minutes in the repository settings. Dependabot requires a dependabot.yml file in your .github directory, but GitHub can generate a starter configuration. Branch protection rules involve more decisions, like how many reviewers you require and whether to enforce status checks, but even a complete setup rarely exceeds 15 minutes.

The friction comes from team coordination, not technical complexity. Enforcing required reviews means existing workflows need adjustment. Blocking secret pushes can interrupt developers who store credentials in config files. These settings work best when enabled early, before teams develop habits that conflict with stricter policies.

What about private repositories?

Secret scanning and Dependabot work on private repositories for GitHub Advanced Security customers. Free and Team plans get these features on public repos only. Branch protection rules are available on all paid plans.

For organizations that cannot justify Advanced Security costs, the recommendation still applies. Even enabling these settings on public repositories reduces attack surface. And branch protection, which works on private repos for paid plans, addresses the most common internal threat: accidental pushes to production branches.

The supply chain context

This guidance arrives during a sustained wave of supply chain incidents. The xz-utils backdoor, discovered in March 2024, showed how a patient attacker could compromise critical infrastructure through years of social engineering. Log4Shell demonstrated how a single vulnerable dependency could expose thousands of applications. GitHub reports a 39% increase in software supply chain attacks over recent years.

Maintainers cannot prevent every attack, but they can eliminate the obvious vectors. A leaked AWS key in a commit, a dependency with a known CVE, an unauthorized push to main. These failures are preventable with settings that already exist in the platform.

The question is whether maintainers will act. Security features that require opt-in suffer from the same inertia that leaves default passwords unchanged and two-factor authentication disabled. GitHub could solve this by changing its defaults, but until then, the burden falls on individual maintainers to configure their repositories correctly.

Frequently Asked Questions

Are GitHub security settings free?

Secret scanning, Dependabot, and branch protection are free for public repositories. Private repositories require GitHub Advanced Security at $49 per committer per month for secret scanning and Dependabot, though branch protection works on all paid plans.

Does enabling secret scanning slow down pushes?

Push protection adds minimal latency, typically under a second. The scan happens server-side before the push completes. Developers only notice a delay when a secret is detected and blocked.

Can Dependabot break my builds with automated updates?

Dependabot opens pull requests rather than merging directly. Your existing CI checks run against the proposed update. You can also configure version constraints to limit major version bumps.

What happens if I enable branch protection on an existing repository?

Existing collaborators lose direct push access to protected branches immediately. Plan for this by communicating the change and ensuring your team understands the new pull request workflow.

How do I check if my repository already has these settings enabled?

Navigate to Settings > Code security and analysis in your repository. Each security feature shows its current status with a toggle to enable or disable it.

Source: The GitHub Blog / Joseph Katsioloudes