If you maintain a project on GitHub, security is not something you configure once and forget. It is a handful of settings, a few habits, and knowing which automated tools to trust and which to treat with suspicion. Here is what the evidence and the maintainer community actually say, not the marketing version.
Lock down the repository settings first
The OpenSSF GitHub Configuration Best Practices guide lists concrete, checkable recommendations rather than vague advice. On the repository side, it recommends that the default branch require code review, require at least two reviewers, require all checks to pass before merge, and block force pushes and branch deletion. It also recommends that CI/CD workflows never be allowed to approve pull requests, and that the default GitHub Actions workflow token permission be set to read-only. These are not abstract suggestions: each one closes a specific path by which a compromised or careless workflow could merge code without a human actually looking at it.
On the organization side, the same guide recommends enforcing two-factor authentication, using single sign-on, and restricting who can create public repositories. None of this is exotic. Most of it is a checkbox in the settings page you already have.
Secrets leaking into your code
GitHub's push protection, announced as generally available and free for all public repositories, scans commits before they land and blocks ones that contain recognizable secret patterns, like API keys or tokens. For public repositories this now costs nothing to turn on. It will not catch every kind of secret, and it works on pattern matching, so it is a safety net, not a guarantee.
GitHub Actions: restrict before you trust
Actions are one of the easier ways to compromise a repository, because a workflow can run arbitrary code with repository permissions. The OpenSSF guide recommends restricting Actions to selected repositories and limiting them to verified or explicitly trusted actions, rather than allowing any public action to run. GitHub itself has signaled that more default protections for Actions are coming, publishing a 2026 security roadmap for GitHub Actions. What exactly changes is still unfolding, so treat this as a direction, not a finished feature set yet.
Automated scanners are not infallible
It is worth being honest about the limits of the tools you are told to rely on. The OSSF Scorecard project's own documentation is a good model of how a security check should be written: it explains exactly what the Binary-Artifacts check looks for, why checked-in binaries are a risk (they cannot be reviewed the way source code can, and can drift from the source over time), and what it exempts, like source generated by tools such as bison or flex. That level of transparency lets a maintainer judge whether a low score actually means something for their project.
Not every tool is that legible. In a GitHub issue reported against CodeQL, one maintainer described getting 12 to 20 false positives per pull request, flagging parameters and variables as "unused" when they were in fact read a line or two later in the code. This is a single bug report, not a measured false-positive rate across CodeQL's user base, and GitHub has not published a response in that thread as of this writing. But it is a useful reminder: a static analysis warning is a hint, not a verdict, and blindly auto-merging on a clean scan is itself a risk.
The Dependabot case for caution
A sharper example of noisy automation comes from Go developer Filippo Valsorda's account of turning Dependabot off. After he shipped a one-line fix to a method in filippo.io/edwards25519 that, in his words, "essentially no one uses," Dependabot opened thousands of pull requests against repositories that were not affected, each one carrying what he describes as "a nonsensical, made up CVSS v4 score" and a "worrying 73% compatibility score." He points out that one of those alerts even went to the Wycheproof repository, which does not import the vulnerable package at all, only an unaffected subpackage of it. His argument, and it is his own experience and opinion rather than a controlled study, is that symbol-level vulnerability databases like the Go Vulnerability Database let a scanner tell the difference between "you depend on this package" and "you actually call the broken function," and that a scheduled govulncheck run plus a test run against the latest dependencies does that job with far less noise.
The lesson generalizes beyond Go: an alert that cannot tell you whether the vulnerable code path is even reachable in your project will eventually train you to ignore alerts altogether. That is the real cost of noisy security tooling, and it is worth weighing against whatever convenience the noisier tool offers.
The honest bottom line
None of this is a single fix. Branch protection, workflow token permissions, and two-factor authentication close off entire classes of attack and cost you a few minutes in the settings page. Push protection and Scorecard-style checks catch specific, well-defined risks. Static analysis and dependency scanners are useful, but their output needs a skeptical human reading it, not a rubber stamp. Securing a GitHub project is less about finding the one setting that matters and more about not letting any single layer be the only thing standing between your code and a bad day.
Further reading
- GitHub: What's coming to our GitHub Actions 2026 security roadmap
- GitHub issue #18359: So many false positives that I doubt it actually works
- OSSF Scorecard: Check Documentation
- GitHub: Push protection is generally available, and free for all public repositories
- OpenSSF: GitHub Configuration Best Practices
- Filippo Valsorda: Turn Dependabot Off
