the github security baseline you actually need

why your github account is basically a skeleton key

think about everything connected to your github account right now. ci/cd pipelines, cloud deploy keys, package registries, maybe production servers pulling straight from main. if someone gets into your account, they don't need to hack your infra. they just push a commit and your infra hacks itself. that's why github security isn't a "nice to have" setting buried in a menu, it's the baseline. here's the checklist, broken down so you actually understand what each piece is doing.

check your 2fa status with one command

first thing, verify 2fa is actually on. don't trust your memory, check it.

gh api user --jq .two_factor_authentication

breaking this down: gh api user hits github's api and pulls back your account data as json. --jq .two_factor_authentication filters that giant json blob down to just the one field you care about. it'll return true or false. if it says false, stop reading and go turn it on. use an authenticator app or a hardware key, not sms. sms 2fa can be defeated with a sim swap, app based or hardware based codes can't be intercepted the same way.

audit your ssh keys, not just your passwords

people rotate passwords and forget ssh keys exist. every laptop, old work machine, or that one vm you spun up for a weekend project might still have a key with push access to your repos. go to settings, then ssh and gpg keys, and actually read the list. ask yourself "do i still own this device and is it still in my possession." if the answer is no to either, revoke it. same goes for personal access tokens, check settings, then developer settings, then tokens, and kill anything you don't recognize or don't need anymore. old keys are the forgotten side door nobody locks.

turn on secret scanning and push protection

secret scanning watches your repo for things like api keys, aws credentials, and database passwords that accidentally get committed. it happens constantly, someone pastes a .env file into a commit at 1am and doesn't notice. push protection goes a step further, it actually blocks the push before the secret ever lands in your git history. that matters because once a secret is in your commit history, it's there forever unless you rewrite history, and plenty of bots are scraping public repos specifically looking for leaked keys within minutes of a push. turn this on under settings, then code security and analysis. if you're on a paid plan it covers private repos too, free tier covers public repos.

protect your main branch like it's production, because it is

main branch protection is the difference between "a teammate reviewed this code" and "whoever has push access can ship whatever they want straight to deploy." set these rules under settings, then branches, then add a branch protection rule for main:

require a pull request before merging, so nothing lands without a second set of eyes. require approvals, at least one reviewer, more if your team can support it. disallow force pushes, this stops anyone from rewriting history and quietly erasing commits or review trails. require status checks to pass, so your tests and linters actually gate the merge instead of being decorative.

this one rule set closes off the two most common "oops" scenarios: someone force pushing over work accidentally, and someone pushing unreviewed code straight to the branch everything deploys from.

the takeaway

none of this is exotic. it's four settings pages and one command. but most accounts and repos skip at least one of them, and attackers know it, because scanning github for exposed secrets and weak accounts is automated and cheap for them. run the 2fa check today, clean out your ssh keys this week, flip on secret scanning and push protection, and lock main behind pull requests. then send this to the dev on your team who's still pushing straight to main with 2fa off. you'll thank yourself the day a key almost leaked and push protection caught it before it ever shipped.