Spectral now part of Check Point’s CloudGuard to provide the industry’s most comprehensive security platform from code to cloud Read now
As the world faced a global pandemic in 2020, many companies encountered another kind of pandemic—a cyber pandemic—due to an increase in cyberattacks. On GitHub, the most notable attacks happened to SolarWinds, when hackers accessed private repositories and harvested exposed secrets.
See how you can maximize security permissions—and your code—before publishing to GitHub. Review the multi-layered permissions and tools you need to create a plan to lock down your GitHub development pipeline.
GitHub has three account tiers that range in the amount of access control.
Know which type of account your development team has so you can take full advantage of all available access permissions.
Centralizing access and permissions to an administrator can streamline management of external collaborators. It can also reduce long-term costs associated with GitHub’s per-user pricing.
GitHub offers the following types of access permissions for development. Set the level of access based on developer role.
Avoid setting up access permissions on an as-needed basis. While convenient in the short-term, this common mistake is far from secure over time because roles and positions in a project might shift. For a maximum security approach, designate one central person to grant the minimum permissions required to work on a project.
If you have an organization owner account, you can add new users to repositories and control their level of access. You must determine the base permissions profile for the organization. Base permissions are automatically applied when you add a new member to a GitHub repository.
By default and for maximum security, make sure the base permissions include only Read access. Grant more extensive access only as needed.
According to a study published in 2019, a comprehensive scan of public GitHub repositories discovered a total of 575,456 instances of sensitive data on the platform. The instances included API keys, private keys, OAuth IDs, AWS access key IDs, and various access tokens.
The primary risks of these types of exposures include monetary loss, privacy breaches, compromised data integrity, and various levels of abuse. Implement the following practices to secure your repositories.
A badly configured server or a developer with poorly configured access privileges might define your server as visible. To avoid this situation and ensure maximum security, restrict repository visibility changes to the organization’s owner account or the project’s administrator level.
Organizations that have the GitHub Enterprise tier can use single sign-on (SSO). With SSO, organizations can use their own accounts and access permission rules without their developers having to use a GitHub account. SSO limits exposure to potential human error and password reuse issues.
With limited read-only access, a developer can easily copy an entire repository using forking. Even by accident, code forking sensitive data can quickly go wrong by forking the repository with different access permissions. Or you might end up with more copies of the code that contain secrets, making them harder to track over time. To avoid these situations, disable forking for maximum security.
To keep your GitHub account and data secure, require and manage authentication access.
Multi-factor authentication—also referred to as two-factor authentication (2FA)—adds a security layer by requiring multiple credentials when authenticating login credentials. For maximum security, GitHub recommends using a time-based one-time password (TOTP) service, such as LastPass Authenticator or Microsoft Authenticator.
Users often choose insecure passwords or share the same password across multiple services, creating an opportunity for credential abuse. To eliminate the use of insecure passwords, use SSH private/public keys to authenticate actions on the server. For additional security, GitHub supports automatic SSH key expiry and rotation, ensuring that, even if an SSH key was leaked, the access window is limited.
For smaller projects, use personal access tokens. Personal access tokens work similarly to SSH keys, but they don’t offer automated rotation. The GitHub account owner must manually set them.
Lock down GitHub server access to a pre-approved list of static IP addresses that are assigned to your organization’s computers. This method is one of the simplest and cleanest ways to secure access. With IP restrictions in place, hackers still have to identify and infiltrate a computer on the pre-approved list before attempting to gain access to your GitHub code repository. It would be a major hurdle for them even if your login credentials are compromised.
To maintain maximum security standards, use granular access permissions and regularly evaluate them during project development. When an person leaves your company’s employment, have security protocols in place to revoke their access. Have a similar plan in place when an employee completes their work on a project and no longer requires the same level of access. Re-evaluate their permissions to determine the minimum level of access (if any) that’s required to assist or monitor other developers who continue to work on the project.
One of the biggest security risks to your GitHub repository is a developer who makes an innocent, but careless, mistake—not a malicious group hacking your well-defended infrastructure. For maximum security, invest in a secrets management solution. These solutions automatically prevent sensitive information from reaching your GitHub repositories and sanitize the repository in such cases where sensitive data has already leaked.
Multiple GitHub tools tackle different security modalities, such as these examples:
Your secrets management solution must integrate directly into the continuous integration and continuous delivery (CI/CD) pipeline. It must also use AI and machine learning algorithms to automatically identify and block secrets well before they are pushed to the GitHub repository and with minimum false positive alerts.
To prevent secrets from being exposed in the first place, even by accident, implement a secrets vault security policy. A secrets vault is a separate system to store sensitive secrets. Every secret in the vault is encrypted, and access is strictly regimented through an audited, unified access interface. With a secrets vault, you consistently track when and who accessed the secrets stored in the vault—a mandatory feature for securing sensitive data.
Your maximum security plan must ensure your secrets never reach your GitHub code repository in the first place. Once you create a plan:
The solution is to invest in a modern secrets scanning tool that easily integrates into your CI/CD pipeline and blocks secrets well before they are committed to the GitHub repository.
SpectralOps builds developer tools for security. With the SpectralOps platform to secure your code, you can build and ship your software without worry. It even scans your public assets on Github and other cloud services, helping you uncover shadow resources and security blindspots. See how SpectralOps can protect your DevOps pipeline and prevent source code leaks before they happen. Request a demo.