The shared responsibility model between GitHub and its customers means that GitHub Security is the end user’s responsibility (most likely you, the person reading this). Over the years, several security issues have affected GitHub repositories (e.g., RepoJacking). It’s now more important than ever to review your GitHub Security settings and ensure that you are not using any insecure default configurations that could put your security at risk.

7 GitHub Security Settings To Configure ASAP

1. Prevent the Creation of Public Repositories

While convenient, there have been many documented instances of businesses accidentally exposing sensitive information in public repositories (intentional or unintentional), including proprietary code or hardcoded secrets. While this can be seen as restrictive by some organizations, for larger organizations, preventing your users from creating public repositories (and instead having a formal process for users to message someone to create one of them) can be a way to prevent unintended data leakage.

• Restricting repository creation in your organization (GitHub Docs)
• Nearly 13 Million Secrets Spilled Via Public GitHub Repositories (Infosecurity Magazine)

2. Configure Default Permissions for Repositories

When users join a GitHub organization by default, they gain automatic access to all the repositories in the organization. This default behaviour breaks the concept of zero trust and the least privilege model. Instead, configure your GitHub organization to ensure all users have no permission to any repository by default and are added to repositories following the concept of least privilege, only being added if they have a business case to do so.

• Setting base permissions for an organization (GitHub Docs)

3. Disable Inviting External Collaborators to Repositories

Unless your business case requires external collaborators, disable this setting to prevent users from inviting unauthorized users to repositories. While unlikely, an attacker who gains access to an account on GitHub may attempt to maintain persistence by adding external collaborators (that they control) to keep access even if their initial access is revoked.

4. Restrict Users from Forking Internal/Private Repositories

While the second control we proposed around setting default permissions will prevent access to repositories, restricting forking adds an extra layer of protection. Doing so will mean that even users granted access are prevented from copying and potentially sharing sensitive code or documents unless explicitly granted permission.

• Managing the forking policy for your organization (GitHub Docs)

5. Enforce Admin Approval for Third-Party Apps

“Consent phishing” is a technique where attackers disguise malicious apps as legitimate ones, hoping that users will accept them. Allowing any user to accept apps can lead to potentially malicious applications performing actions in your Slack workspace, such as reading messages or carrying out other malicious activities. To reduce this risk, enable app approval and allow users to request adding apps. As an admin reviewing app approval, make sure to verify the identity of the application and the permissions it is requesting. For instance, if a supposed Calendar integration is asking to read your files and messages, it should raise red flags. Always assess consent permissions, even for legitimate applications.

• Approving OAuth apps for your organization (GitHub Docs)
• Enabling OAuth app access restrictions for your organization (GitHub Docs)

6. Enable Multi-Factor Authentication (MFA)

Enforcing MFA adds an essential layer of security to your Slack accounts. Even if a user’s password is compromised, MFA ensures that the attacker cannot access the account without the second authentication factor preventing unauthorized access to your workspace.

• Requiring two-factor authentication in your organization (GitHub Docs)

7. Configure Protected Branches

To protect your code, configure branch protections on all critical branches (like main or production). Require pull requests for all changes, enforce that the reviewer is not the same person who wrote the code, and consider requiring multiple reviewers for high-risk repositories. Enable status checks so automated tests and security scans must pass before merging, and restrict branch deletion to admins only. These controls help prevent accidental changes, unauthorized code, and ensure proper oversight.

• Managing a branch protection rule