You secure a source code repository by controlling who can change it and how a change reaches production: strong sign-in with MFA, protected branches, required review, least-privilege tokens, secret scanning, and audit logs. The repository is where your software is made, so tampering there reaches every customer.
Why do repositories deserve their own controls?
NIST's Secure Software Development Framework, SP 800-218, includes a practice to protect all forms of code from unauthorized access and tampering. It covers source, build files and released artifacts. If an attacker can push a change that passes review, or alter a build script that nobody reads, the product ships their code with your signature on it.
The risk is not only outsiders. A departed contractor with live access, or a token pasted into a ticket, does the same job.
Which settings matter most?
The OpenSSF Scorecard project is useful here, because it turns repository hygiene into named, automated checks. Several map straight to controls you can apply today: Branch-Protection, Code-Review, Token-Permissions, Pinned-Dependencies, Dependency-Update-Tool, Signed-Releases, Security-Policy and SAST.
Read them as a list of questions. Can anyone push directly to the main branch? Does a second person review every change? Do automation tokens have write access they do not need? Are dependencies and actions pinned to exact versions? Is there a written way to report a vulnerability?
A constructed example
A team has 30 developers, a protected main branch and required review. A single engineer has admin rights and can bypass the rule, and a CI token has write access to every repository. An attacker who steals that token can alter any project without a review. The branch rule looked strong. The weak point was the token, which is exactly what a token permission check finds.
What about secrets in code?
Secrets committed to history stay in history even after deletion. Turn on secret scanning for new pushes, scan old history once, and rotate anything found. Rotation matters more than removal, because anyone who cloned the repository has the old value.
What about the pipeline around the repo?
Workflow files are code. Review changes to them like application code, restrict who can change them, and avoid workflows that run untrusted pull request content with write permissions. The Scorecard project names this risk as a check called Dangerous-Workflow.
Pin third-party actions and dependencies to immutable references, so an upstream change does not alter your build without a pull request.
If the question includes provenance, the SLSA specification defines levels for build integrity and records how an artifact was produced, which lets consumers verify that it came from the expected source and process.
Where does Safeguard fit?
Safeguard's policies and gates can block a pull request or release that fails agreed rules, such as a dependency with a known issue, and its dependency scanning and SBOM work show what a build pulls in. These sit alongside repository settings, not in place of them.
How to check or apply this
- Require MFA for all accounts and remove accounts that no longer need access.
- Protect the main and release branches: no direct pushes, required review, required status checks, and no admin bypass for routine changes.
- Replace long-lived personal tokens with scoped, short-lived credentials, and set CI tokens to read-only by default.
- Turn on secret scanning, scan history once, and rotate every secret found.
- Pin dependencies and third-party actions to exact versions, and use an automated update tool to propose bumps.
- Add a security policy file that says how to report a vulnerability.
- Review the audit log monthly for permission changes, new tokens and disabled protections.
- Run the Scorecard checks and fix the lowest scores first.
Quick check
Is a private repository secure by default?
No. Private limits who can read it, not who can change it. Tokens, weak sign-in and missing review still apply.
If I delete a leaked secret from the code, am I safe?
No. The secret remains in history and in every clone. Rotate it.
Sources
- NIST SP 800-218, Secure Software Development Framework
- OpenSSF Scorecard
- SLSA specification, version 1.0
Last reviewed: 18 October 2026.
