GitHub Security Lab Shipped gh-secure So You Can Stop Shipping Open Source Naked

Most public repos still treat security settings like optional DLC. GitHub Security Lab’s answer is a CLI extension called gh-secure that flips on the boring guardrails in about two minutes: branch protection, private vulnerability reporting, secret scanning with push protection, Dependabot, and CodeQL code scanning. Free for public open source. Requires admin or maintain on the repo. Does not require you to enjoy clicking through seventeen settings pages while your coffee dies.

The project lives at GitHubSecurityLab/gh-secure on GitHub. Install with gh extension install GitHubSecurityLab/gh-secure. Then run gh secure interactively, or gh secure --yes if you already know what consent looks like, or gh secure --yes --dry-run if your change-control board has trust issues. You can also aim it with --repo owner/name and cherry-pick features like branch-protection, secret-scanning, dependabot, code-scanning, and vulnerability-reporting (with shorthands bp, ss, dep, cs, vr).

What it actually enables

1. Branch protection: reduce force-push and drive-by main branch chaos. If you already run modern rulesets, gh secure warns before enabling legacy branch protection so you do not stack conflicting religion.
2. Private Vulnerability Reporting + security policy path: give outsiders a private bug channel instead of a public issue titled “your product is on fire.”
3. Secret scanning + push protection: stop shipping cloud keys in commit three of a “quick fix.” GitHub’s scanner covers hundreds of token types across many providers.
4. Dependabot: automated PRs when dependencies are known-sad.
5. Code scanning (CodeQL): catch common vulnerability classes in supported languages; pair later with autofix workflows if your org pays for the grown-up seats.

Why this is funny (and necessary)

The security industry spent a decade selling “shift left” while maintainers shipped npm packages with admin tokens in .env committed “temporarily.” GitHub already offered the toggles. Humans did not toggle them. An official Security Lab extension that batch-enables the defaults is an admission that documentation alone lost. I respect the honesty.

It also talks to Copilot CLI / Copilot App style assistants: ask for a security overview, ask what is missing, ask it to enable the gaps. That is useful if you accept that an LLM suggesting gh secure --yes is still on you when the org policy forbids legacy branch protection. Dry-run exists for a reason.

Install and first run (lab notes)

gh extension install GitHubSecurityLab/gh-secure
gh auth status
gh secure status --repo yourorg/yourrepo
gh secure --repo yourorg/yourrepo --dry-run
gh secure --repo yourorg/yourrepo secret-scanning dependabot --yes
gh secure --repo yourorg/yourrepo --yes   # only after dry-run and policy check

Prerequisites: GitHub CLI installed and authenticated; admin or maintain on the target; for some org repos you may need gh auth refresh -s admin:org. Code scanning needs supported languages and plan availability. Branch protection can fail under org policies that ban it or prefer rulesets.

Where this sits next to last week’s GitHub toys

GitHub also made AI Scan for pull requests generally available around October 15, 2026, and agentic autofix for code scanning alerts GA the same day for Advanced Security customers. Those are signal and remediation aids. gh-secure is the “turn the lights on” step for public repos that never enabled secret scanning. Different layer. If you already wrote about AI Scan, do not pretend gh-secure replaces it. One finds bugs in PR diffs for languages CodeQL skips. The other enables the baseline features Security Lab has been begging maintainers to click.

Security Lab’s Fuzzing Taskflow (LLM-babysat AFL++) is another neighbor: deep bug hunting in disposable VMs. Also not a substitute for push protection. Your supply chain needs both seatbelts and crash testing. Most open source shipped with neither.

Operational gotchas

• 403 Forbidden: you are not admin/maintain, or org scope is missing.
• Code scanning fails: unsupported languages or plan limits. Read the CodeQL language list before filing a ghost story.
• Branch protection vs rulesets: let the tool warn you; do not double-armor until you understand which system wins.
• Org policy: some enterprises disable exactly the features open source wants. That is a governance ticket, not a CLI bug.

What maintainers should do this week

1. Install gh-secure on a throwaway public repo first. Dry-run. Read the plan.
2. Enable secret scanning + push protection and Dependabot everywhere you actually ship.
3. Turn on private vulnerability reporting so researchers stop sliding into your DMs with exploit screenshots.
4. Add CodeQL where languages support it. Review the first week’s alerts like an adult, not like a spam folder.
5. Document which org repos are blocked by policy so “we thought it was on” dies in the meeting.

Sloth take

Open source security failed the checkbox era so hard that GitHub Security Lab shipped a robot to press the checkboxes. Use it. Then do the part the robot cannot: review code, rotate leaked secrets that already escaped, and stop merging “temporary” credentials because the demo was Friday. Two minutes to enable guardrails. Infinite minutes to explain why you did not.

Need help turning repository hygiene into an actual program? Book Dark Edge Consulting.

Suggested team policy blurb

“All public repositories under our orgs must run gh secure status clean for secret scanning, Dependabot, and vulnerability reporting. Branch protection or equivalent rulesets required on default branches. Code scanning required where CodeQL supports the primary language. Exceptions need a written owner and expiry date.”

Paste into your CONTRIBUTING or internal security wiki. Adjust for rulesets-first orgs. The point is measurable defaults, not vibes.

Copilot-assisted use without surrendering your brain

If you drive gh-secure through an AI assistant, keep human confirmation on --yes for production orgs. Ask the assistant to explain each feature it wants to enable, map it to your rulesets policy, and produce a dry-run transcript for the change ticket. An LLM that enables secret scanning is helpful. An LLM that silently fights your org’s ruleset strategy is how you get a weekend incident about locked branches.

Metrics that are not vanity

• Percent of public repos with secret scanning push protection on
• Percent with Dependabot alerts enabled and PRs not rotting
• Mean time from private vuln report to first human response
• Code scanning alert reopen rate after “fixed” merges
• Number of repos still failing gh secure status after thirty days

Star counts on the extension repo are irrelevant. Coverage across your org’s public surface is the scoreboard.

Supply-chain angle without the TED talk

Public repositories are how the internet installs dependencies. Leaving secret scanning off is how one maintainer laptop compromise becomes everyone else’s CI incident. gh-secure will not stop a malicious maintainer. It will stop a lot of accidental key leaks and known dependency CVEs from being pure self-owns. That is enough reason to run it before your next stars milestone.

Also enable it on the template repos your org clones from. Defaults propagate. Bad defaults propagate faster.

Feature shorthand cheat sheet

• bp / branch-protection
• vr / vulnerability-reporting
• ss / secret-scanning
• dep / dependabot
• cs / code-scanning

Example: gh secure bp ss cs -y --repo owner/repo enables three features non-interactively. Run gh secure status after and paste the output into the change ticket so future you knows what “done” meant.

MIT-licensed tooling from Security Lab does not remove your duty to read org policy. If your enterprise disabled private vulnerability reporting, the CLI will not invent permission. Escalate to the people who own the org settings, not to a Twitter thread.

Sources

• GitHubSecurityLab/gh-secure README and repository (GitHub)
• GitHub Security Lab protect-your-project guidance (linked from the extension docs)
• GitHub Changelog: AI Scan for pull requests GA (Oct 15, 2026) and agentic autofix GA (Oct 15, 2026) for adjacent context