gh-secure turns on five GitHub security features from the terminal

One command turns on five separate GitHub security settings

gh-secure is a GitHub CLI extension, so it plugs into an existing `gh` installation rather than replacing it. The project description calls it a way to enable security features on public repositories following the best practices published by GitHub Security Lab, and the README frames the goal in plain terms: preventing exploitation of known vulnerabilities, preventing secrets from reaching the internet, preventing unwanted access and modifications, and keeping vulnerabilities private until they are fixed. Five concrete settings sit behind that goal, each with its own section in the README. Branch protection blocks unwanted changes, private vulnerability reporting gives outside researchers a safe channel, secret scanning with push protection covers more than 300 token types from more than 180 service providers, Dependabot opens pull requests for vulnerable dependencies, and code scanning with CodeQL analyses the code and your pull requests. The README notes that everything it enables is free for open source projects.

Install it as a gh extension, then run it against a repo you administer

Installation is one command, and the prerequisites are narrow: GitHub CLI installed and authenticated, plus admin or maintainer permissions on the target repository.

gh extension install GitHubSecurityLab/gh-secure

Once it is installed, the same binary serves both an interactive path and a direct one. The interactive mode walks through all features, and the README describes the goal as enabling security features in two minutes or less. The non-interactive path, which the README calls a "just do it" mode, skips the prompts. Because every change is a write to repository settings, the permission requirement is not decorative. The README's own explanation is that enabling branch protection rules, code scanning, secret scanning, Dependabot and vulnerability reporting requires write access to repository settings, and that organisation repositories may additionally need the `admin:org` OAuth scope, obtained by running `gh auth refresh -s admin:org`. The tool also works from the GitHub Copilot CLI or the GitHub Copilot App, where it can be asked for an overview of a repository's security and instructed to enable the missing features.

Running it: interactive, blind, targeted or a dry run

The usage examples in the README cover the range of ways you might drive the tool:

gh secure                                  # Interactive mode, all features
gh secure --yes                            # Enable all features, no prompts
gh secure branch-protection dependabot     # Enable only these two features
gh secure bp ss cs -y                      # Enable 3 features, no prompts
gh secure --repo owner/repo code-scanning  # Enable CodeQL on specific repo
gh secure --yes --dry-run                  # Preview what would be enabled
gh secure status                           # Check current feature status
gh secure status --repo owner/repo         # Check status of specific repo

The flags table keeps the surface small: `-r`, `--repo <owner/repo>` targets a repository other than the current one, `-y`, `--yes` enables selected features without confirmation, `-n`, `--dry-run` simulates changes without applying them, `-v` prints the version and `-h` shows help. Two of these deserve emphasis for anyone nervous about a script editing repository settings. `gh secure status` is a read-only inspection of what is already enabled, and `--dry-run` shows exactly what a run would change before it changes it. A sensible first session therefore reads, previews and then applies.

Feature names, shorthands and the ruleset conflict warning

Passing feature names narrows what a run touches, and if none are given all five are included. Each feature has a shorthand, and the shorthands can be mixed with full names in one invocation:

| Feature | Shorthand | |---------|-----------| | `branch-protection` | `bp` | | `vulnerability-reporting` | `vr` | | `secret-scanning` | `ss` | | `dependabot` | `dep` | | `code-scanning` | `cs` |

Branch protection is the one feature with a guard rail. Modern repositories increasingly use rulesets, and legacy branch protection can overlap or conflict with an active ruleset. The README says that in that situation `gh secure` will warn you before enabling legacy branch protection, and the troubleshooting section repeats the point, noting that a repository using rulesets may not need legacy branch protection at all and that the tool detects active rulesets and prompts before enabling it. The difference in approach between the two is worth keeping in mind: a ruleset is GitHub's newer, more expressive mechanism, while branch protection is the older per-branch model, and this tool enables the older one only after checking for a conflict.

Three failure modes worth knowing before you run it on an org

The troubleshooting section is short and specific, which makes it more useful than a generic error guide. First, "403 Forbidden" errors usually mean the token lacks the right rights: admin or maintain permissions on the repository, and for organisation repositories possibly the `admin:org` scope, refreshed with `gh auth refresh -s admin:org`. Second, code scanning can fail when the repository contains no supported languages or when code scanning is not available on the account's plan, so a failure here may be a plan limit rather than a bug. Third, branch protection can fail because an organisation policy restricts it, in which case the README's answer is to contact the organisation admin, since no amount of local permission fixes a server side policy. There is also a practical ordering point that the README does not spell out but that follows from the feature list: code scanning depends on the repository's language mix and plan, so a partial success across features is a realistic outcome for a mixed portfolio.

A shell script with one release behind it

The repository is small and mostly written in Shell, and its root layout reflects a CLI project rather than a library: the `gh-secure` executable, a LICENSE.txt, README.md, and the usual community files including CODEOWNERS, SECURITY.md, SECURITY.md.template, CONTRIBUTING.md, CODE_OF_CONDUCT.md and SUPPORT.md, plus an assets/ directory holding the demo GIFs. The licence is MIT, which is the permissive end of the scale and a genuine advantage for an organisation that wants to read the script before it runs, fork it if the shell implementation needs to change, or vendor it internally. The pace is the weaker side. The repository shows a single tagged release, v0.1.0 on 2026-09-16, and the last push to the repository was on 2026-10-02, with the project not archived. One release in and a version number of 0.1.0 both indicate an early tool: the documented surface is small and stable enough to rely on, but the project has not yet accumulated the release history that would let you judge how it behaves when GitHub changes its API or when an organisation's policy setup is unusual.

Editorial conclusion

Maintainers of public repositories who want the five GitHub security features switched on in one pass should install gh-secure and start with `gh secure status` and `gh secure --yes --dry-run`, because both read the repository before anything is changed. Teams that already manage branch protection through rulesets, or that need code scanning on a plan where it is unavailable, should expect the tool to stop short and need a different route. Before running it across many repositories, confirm that `gh auth refresh -s admin:org` is acceptable in your organisation, since the tool writes to repository settings and needs admin or maintain rights.

Frequently asked questions

Official sources

1. GitHubSecurityLab/gh-secure on GitHub
2. Issues
3. License: MIT
4. README
5. Releases