If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Security best practices to protect your GitHub repository
GitHub is a vital DevOps tool for storing, tracking and collaborating on software projects. As a free and open-source version control system, millions of developers use GitHub to handle small to massive projects efficiently.
GitHub has several features that make it robust against security breaches. However, security breaches do occur, and humans mainly cause them. To get started on protecting your GitHub repository, the official GitHub Docs is a great place to gain insight into best security practices.
However, this article will address some of the most crucial security best practices to protect your GitHub Repository.
But first, why should you take GitHub security seriously?
A data breach is a serious problem that arises from poor GitHub security. An unknown attacker recently downloaded critical data from dozens of private repositories. For a company, this may result in the loss of sensitive information.
That’s why understanding the risks of using GitHub is non-negotiable for securing your account. You must consider code security at the start of the project and not just as an afterthought. Doing so enables you to create robust and secure code at every phase of the development process.
And now, here are our top GitHub security best practices.
Restrict & control access
The first step to secure your GitHub repository is to restrict access. You must ensure that only authorized persons have access to the repository—failure to do so in an open invitation for a security breach.
Here are some tips for restricting and controlling access on GitHub:
- Enforce 2-factor authentication across your organization. Examples of good external authentication providers include LDAP, SAML SSO, or CAS.
- Secure all endpoint devices (like phones, laptops, tablets, etc.) with access to the source code.
- Reduce the number of repository admins to be minimum.
- Adhere to the least privilege principle. This principle states that contributors must restrict access to only parts of the code that applies to their task and nothing more.
- Do not forget to revoke access for users who no longer exist
- Regularly change your SSH keys and personal access tokens.
- Only authorized IP addresses must have access to your repository.
Protect your code branches
Branches are an integral part of GitHub. They allow developers to create a contained area of the repository where they can develop new features, fix bugs, and experiment with new ideas without compromising the source code.
However, the merging process can open up critical vulnerabilities if done wrongly. You must follow a controlled merge process, enforcing a proper code review and other security tests.
Thankfully, you can ensure safety by enabling branch protection for your default main branch. Doing so enforces the following best practices:
- Prevents force pushes and deletion
- Requires a pull request before merging
- Requires signed commits
- Requires conversation resolution before merging
- Enforces that branches must be up-to-date and pass predefined checks before merging.
- Require successful deployments before merging
- Enforces restrictions for admins
Conduct a background check on employees
While this point doesn’t directly relate to GitHub, the importance of a proper background check during the hiring process cannot be overstated. Why? Because the security measures you have in place will mean nothing if you have employees trying to sabotage your repository deliberately.
A police check reveals an individual’s criminal record, helping to provide insight into their character suitability for the role. For example, if your business was based in the state of New South Wales (NSW) in Australia and an applicant has been criminally charged for stealing sensitive information from their former employer, it would make sense to mitigate such risks. In this instance, with a police check NSW, you can filter out applicants that may pose a severe risk to your code repository. Moreover, you should conduct police checks on employees periodically to ensure they’ve not been compromised. Police checks are also crucial for employees changing roles as a form of precaution.
Use security control tools to scan for vulnerabilities
Incorporating security guardrails into the SDLC helps ensure your code doesn’t contain vulnerabilities. It would help if you established code audits for both new and imported code. While a code audit might seem tedious or time-consuming, it will save you money, time, and headaches. Code audits are very critical when importing from a closed-source repository.
There are two main types of recommended security tools:
- SAST (e.g., Veracode, SonarQube) – great for identifying security flaws in code that may result in vulnerabilities.
- SCA (e.g. WhiteSource, Snyk) – great for detecting vulnerabilities in dependencies, which helps ensure third-party code doesn’t contain security holes before incorporating them into your repository.
Keep personal identifying information (PII) and secrets away from the code
Do not include sensitive information in a git file or history. That’s why it is a lousy practice to hardcode secrets like API keys, passwords, and tokens because they become visible to individuals with access to the repository. This can be exponentially dangerous if it’s a public repository.
Another common mistake by novice developers is placing credentials to the CI/CD assets in the production pipeline’s code management. Unfortunately, doing so stores this sensitive data in the Git history even if deleted.
Incorporating a secret detection tool in the SDLC is a way to combat this problem. This tool is a pre-commit hook that prevents secrets from entering the git history. You must also revoke a secret key immediately if you find it in the git history.
Beware of forks
Forking is the process of making a copy of the repository. Doing so disconnects the codebase from previous committers. That way, you can make changes to the project without affecting the original repository.
If sensitive data is in the original repository, then all ensuring forked repositories will contain those sensitive data. And this can be disastrous if the visibility of the forked repository changes from private to public.
Consequently, you can only fork public repositories by default in GitHub for security reasons. However, you can configure private repositories to be forkable, and that’s where the problem may arise. Hence, a good practice is to limit access to fork a private repository to those involved in the project. Moreover, you must keep track of forking events through an audit log to ensure their legitimacy and allow for easy resolution of security breaches should they arise.
As a free and open-source version control system available readily on the internet, millions of developers use GitHub to handle small to massive projects efficiently.
There are various methods that can be used to make your GitHub repository robust against security breaches. These include: Restricting and controlling access, protecting code branches, conducting a background check on employees (HR Decision), using security control tools to scan for vulnerabilities and being careful of forking.
Did you like our content?
Spread the word
Subscribe to Our Newsletter
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.