Secure GitHub Accounts & Repos Against Malicious Code

This guide shows you how to lock down both your GitHub account and your repositories so malicious code can’t be pushed, pulled, or injected into your projects. You’ll learn concrete settings, branch protection rules, and code review habits that block common attack vectors like compromised tokens, malicious pull requests, and dependency tampering. No prior security expertise is needed—just a GitHub account with admin access to the repositories you want to protect.

What You’ll Need

• A GitHub account (free or paid) with admin rights on the repositories you manage.
• Two-factor authentication (2FA) enabled on your account (strongly recommended before starting).
• Access to repository settings—usually under the “Settings” tab.
• For advanced steps: a code editor or command line if you want to add a SECURITY.md file, but this is optional.

Step-by-Step

1. Enable two-factor authentication (2FA) on your account. Go to Settings → Security → Two-factor authentication and set it up using an authenticator app or hardware key. This prevents attackers from logging in even if they steal your password.
2. Review and revoke unused access tokens and SSH keys. Under Settings → Developer settings → Personal access tokens and Settings → SSH and GPG keys, delete anything you don’t recognize or no longer use. For tokens, set short expiration dates and limit scopes to only what’s needed (e.g., read-only for public repos).
3. Require 2FA for all organization members (if you use organizations). As an org owner, go to Organization Settings → Authentication security and check “Require two-factor authentication for everyone.” This blocks members with weak credentials.
4. Protect your default branch. In your repository, go to Settings → Branches → Add rule. Set the branch name pattern to your default branch (e.g., main). Enable: Require pull request reviews before merging (at least 1 review), Dismiss stale reviews, Require status checks to pass (if you have CI), and Do not allow bypassing the above settings. This prevents direct pushes and forces code review.
5. Require signed commits. In the same branch protection rule, check Require signed commits. This ensures every commit is cryptographically signed by a verified GPG key, making it harder for an attacker to impersonate a contributor.
6. Limit who can push to the repository. Under Settings → Manage access, remove any collaborators who don’t need write access. For public repos, consider changing the default branch to “Protected” so only maintainers can push directly.
7. Enable dependency review and Dependabot alerts. Go to Settings → Code security and analysis and enable: Dependency graph, Dependabot alerts, and Dependabot security updates. This flags known vulnerabilities in your dependencies and auto-opens pull requests to fix them.
8. Add a SECURITY.md file. In your repo root, create a file named SECURITY.md with instructions on how to report vulnerabilities (e.g., “Email security@example.com”). This encourages responsible disclosure instead of public exploits.
9. Scan pull requests for malicious code. Before merging any PR, manually review the diff for suspicious patterns: obfuscated code, unexpected new dependencies, changes to build scripts, or attempts to exfiltrate data (e.g., calls to external URLs). Use GitHub’s “Files changed” tab to see exactly what’s modified.
10. Use GitHub Actions with caution. If you use CI/CD, pin actions to a full commit SHA (e.g., actions/checkout@) instead of a tag like @v3—tags can be moved to point to malicious code. Also, avoid running untrusted code in workflows triggered by pull requests from forks unless you’ve reviewed it.
11. Rotate secrets and tokens regularly. If you have any secrets stored in GitHub (Settings → Secrets), rotate them every 90 days. Never hardcode secrets in your code—use GitHub’s encrypted secrets feature.
12. Monitor your account activity. Under Settings → Security log, review login attempts and actions. Set up email notifications for new logins and password changes.

Common Mistakes

• Ignoring branch protection for old branches. If you have multiple long-lived branches (e.g., develop), apply the same protection rules to all of them, not just main.
• Using weak personal access tokens. Tokens with unlimited scopes or no expiration are a huge risk. Always use fine-grained tokens with minimum permissions and short expiry.
• Merging PRs without checking the diff. Malicious code can hide in large diffs or in files you don’t normally look at (like .github/workflows). Always review the full diff.
• Trusting third-party actions blindly. A popular action can be compromised. Pin to a commit SHA and verify the action’s source code.
• Not enabling 2FA on all accounts. If you have multiple GitHub accounts (work and personal), secure every one—attackers often target the weakest link.

Tips

• Use a dedicated deploy key with read-only access for CI/CD systems instead of a personal access token—this limits blast radius.
• Set up a CODEOWNERS file to require approval from specific people for sensitive paths (e.g., /src). This adds an extra review layer.
• Enable “Require conversation resolution” in branch protection so no unresolved comments are left before merge.
• Regularly audit your repository’s “Insights → Traffic” for unusual spikes that might indicate scraping or probing.
• Keep your own machine secure—malware on your computer can steal your GitHub credentials. Use a password manager and keep your OS updated.

Troubleshooting

I can’t push to my protected branch. If you’re an admin, you might still be blocked if “Do not allow bypassing” is enabled. Check the branch protection rule—you may need to create a pull request instead of pushing directly. If you’re a collaborator, ensure you have write access and that your commits are signed if required.

Dependabot alerts aren’t showing up. Make sure you’ve enabled the dependency graph first. For private repos, you may need to enable “Dependency graph” under Code security and analysis and wait a few minutes for the initial scan.

Signed commits are rejected. If you enabled “Require signed commits,” you must have a GPG key set up in GitHub and your local Git configured to use it. Check git config user.signingkey and ensure your key is added to your GitHub account.

2FA isn’t working. If you lose your authenticator app, use recovery codes (save them securely) or contact GitHub support. To avoid lockout, always store a backup code offline.

I accidentally merged a malicious PR. Immediately revert the merge (via git revert or GitHub’s revert button), rotate any exposed secrets, and review your security log for unauthorized actions. Then tighten your branch protection rules.

Frequently Asked Questions

Q: Do I need 2FA for a personal account?
A: Yes, absolutely. 2FA is the single most effective way to prevent account takeover. Even if your password leaks, an attacker can’t log in without your second factor.

Q: Can I protect a public repository from malicious code?
A: Yes, branch protection and code review work the same on public repos. You can also limit who can push, but anyone can still fork and submit PRs—you just need to review those carefully.

Q: What is a “fine-grained” personal access token?
A: It’s a token with restricted permissions (e.g., only read access to a specific repo) and an expiration date. Unlike classic tokens, they can’t access everything on your account.

Q: How do I know if a pull request is malicious?
A: Look for: new or modified files that download and execute code, changes to .github/workflows, base64-encoded strings, or any attempt to read environment variables. If unsure, ask the contributor to explain the change.

Q: Should I enable all branch protection options?
A: Not necessarily. For small projects, requiring one review and signed commits is enough. For large teams, add status checks and codeowners. Over-protecting can slow down development, so balance security with workflow.

Q: What should I put in SECURITY.md?
A: A simple policy: “If you find a vulnerability, email [address] with details. Do not disclose publicly until we’ve fixed it.” You can also include a PGP key for encrypted reports.

Related

• Host a Society Sunlit Cobblemon Server
• Show More Than 30 Custom Fields in WordPress
• Samsung Smart Switch: How to Use It