Check ten things in GitHub first: who has access, the dependency graph, Dependabot alerts, dependency review, secret scanning with push protection, code scanning, a SECURITY.md file, read only workflow tokens, pinned actions, and review rules for workflow files. GitHub's own documentation covers each, and most take minutes.
1. Who can see and change the repository?
GitHub's repository security quickstart says the first step is to establish who can see and modify your code. Review visibility and the list of people and teams with access. Remove old contractors and unused bot accounts, and give people the lowest role that fits.
2. Is the dependency graph on?
The dependency graph reads manifest and lock files to identify what you depend on. It powers the next two features, so enable it first.
3. Are Dependabot alerts enabled?
Alerts are raised when a dependency in the graph has a known vulnerability. An alert you never read helps nobody, so assign someone to triage the list each week.
4. Is dependency review on pull requests?
Dependency review shows dependency changes in a pull request before they merge, so a newly added vulnerable package is visible at review time. GitHub notes it requires the dependency graph, and that availability for private repositories depends on your plan.
5. Is secret scanning with push protection enabled?
Push protection blocks a commit that contains a detected secret before it lands in the repository, which is cheaper than cleaning up afterwards. Treat any secret that has reached a repository as exposed and rotate it.
6. Is code scanning running?
Code scanning looks for vulnerable patterns in your source. GitHub provides workflow templates, including its CodeQL workflow, and also supports third party tools. Make results visible in pull requests, so fixes happen while the author remembers the code.
7. Is there a SECURITY.md?
GitHub says a repository maintainer should specify a security policy by creating a SECURITY.md file that tells people how to report vulnerabilities. Without it, researchers either guess or post an issue publicly.
8. Is the workflow token read only by default?
GitHub's secure use reference recommends setting the default GITHUB_TOKEN permission to read access for repository contents, then raising permissions per job. It also warns that anyone with write access to a repository can read all its repository secrets.
9. Are third party actions pinned?
GitHub recommends pinning actions to a full length commit SHA, because tags can be moved. It also suggests keeping actions current with Dependabot version updates, and using OpenID Connect to create short lived tokens for cloud access instead of storing long lived keys.
10. Who reviews changes to workflows?
The same reference describes using CODEOWNERS so changes to the workflows directory need approval from a designated reviewer. A pipeline that deploys to production is among the most valuable files in your repository.
What do people usually skip?
Number 10 and number 7. Both are boring, and both matter after an incident.
A constructed example
A twelve person team spends one afternoon. They remove four stale collaborators, switch on dependency review, set the token default to read only, pin six actions to SHAs, and add a CODEOWNERS entry for the workflows folder. Nothing changes in how they ship. The next week a pull request adds a dependency with a known issue, and the review flags it before merge.
How to check or apply this
- Open repository settings and walk through the ten items in order.
- Apply the same settings at the organization level where possible, so new repositories start secure.
- Assign an owner for alert triage with a weekly slot.
- Rotate any secret that ever appeared in a repository.
- Record the settings you changed and re-check quarterly.
Safeguard's pull request gates and dependency scanning work alongside these features, adding reachability analysis to show which flagged dependencies the code actually calls. The free scan at gold.safeguard.sh/scan checks up to 100 dependencies.
Quick check
What is push protection?
A secret scanning feature that blocks a commit containing a detected secret before it reaches the repository.
Why does workflow token scope matter?
A compromised or malicious step can use the token. A read only default limits what it can change.
Sources
- GitHub quickstart for securing your repository
- GitHub Actions secure use reference
- GitHub security features
Last reviewed: 18 October 2026.
