SOFTWARE SUPPLY CHAIN
Protecting Stale Code Repositories on GitHub: Essential Security Measures
July 18, 2022
Maintaining developer access and privileges across your code repositories can be burdensome; not maintaining these protections across your repositories can represent a serious risk to your source code security. Implementing effective strategies such as security scans, archiving, and branch protections are critical to ensuring the security of your software supply chain.
Back in the day, your code repositories might have been hosted on-premises and hidden from the public internet, but nowadays, it’s common to put your code on a service like GitHub Cloud. This makes following security best practices crucial since everyone can potentially access your repositories.
Sadly, security is often an afterthought when implementing new systems, and development teams tend to give their members excessive permissions to repositories, which can lead to attacks. With the rise of the DevOps movement, where developers' code changes can end up in production systems automatically, a review process by fellow engineers is required for code merges. Four eyes see more than two.
The move to remote work, where developers work from their own devices, has also required companies to reconsider security because administrators don’t have control over developers’ computers, as these machines aren’t in their local, trusted networks anymore.
Supply chain attacks drastically increased in 2021 and constitute a significant risk today, with attackers often targeting companies that lag behind the industry in implementing current security practices for their development process.
But when a company has been hacked once or has very zealous security professionals, things can go to the other extreme too. Developers don’t get the permissions they need or have to wait extended amounts of time until their permissions are updated, which slows them down needlessly. Striking a balance between moving fast and staying safe isn’t easy.
This article will talk about stale code repositories, which form one of the primary attack vectors. Specifically, we will discuss how to secure these repositories to ensure they don’t become a liability while also not impeding developers’ day-to-day work.
Stale repositories are code repositories that are either no longer being used or no longer being updated.
Unused repositories have been used in the past, but their code isn’t deployed anywhere. They don’t have recent clones or fetches or pushed commits.
Passive repositories don’t have any recent commits, but they are deployed independently or dependent on another system. The audit log shows current clones or fetches for them.
Often, your team simply isn’t focused on stale code repositories anymore; they either aren’t accessed at all or are just used as a dependency. Coupled with excessive access permissions and potentially outdated or unknown dependencies, they can thus become a security issue.
Any old repository that is no longer being leveraged is more likely to have common vulnerabilities and exposures (CVE). And these are known to a broad audience, hackers who will automatically find them upon scanning your source code.
To make sure your repositories are secure and monitored, you should activate GitHub’s Dependabot security scans. These will scan the code and suggest updates and fixes for its dependencies.
GitHub also offers advanced security scans for your code and configurations in their enterprise plan. These include scanning code for well-known vulnerabilities gathered from thousands of repositories on GitHub. It additionally prevents you from accidentally committing secrets to your repositories so they don’t get stolen.
Both will automatically create pull requests.
Archiving is one of the central GitHub features to make stale code repositories a bit more secure. When you archive a repository, everything related to the repo will effectively become read-only, from issues, permissions, and releases to pull requests, labels, milestones, and code scanning alerts.
So, if a developer's computer gets hacked, nobody can use it to smuggle some malicious updates into your archived repositories.
Note: Dependabot will stop scanning archived repositories, and GitHub's advanced security features will be disabled. You should only archive unused repositories, not passive ones, which need their dependencies checked regularly.
Also remember, you can’t add or remove collaborators or teams to/from archived repositories, so you should ensure they aren’t being updated anymore. However, people can still fork your repository when archived, allowing others to maintain their copy.
Again, only archive unused repositories that don’t have any reads or writes for a significant amount of time. Since passive repositories, while not updated, are still in use, archiving poses a security risk to them since Dependabot will no longer scan them.
Branch protections are another way to secure your stale repositories. You can set them up in your repository's settings to enforce different kinds of automation for merging pull requests.
For example, if you configure a setting so that nobody can directly push a commit to the default branch, everyone will be required to create a pull request for that commit. Using branch protection rules and CODEOWNERS files, you can make sure that a trusted party reviews everything that lands in your default branch.
Furthermore, if you create a valid CODEOWNERS file with an empty team, only admins will be able to approve and merge pull requests into that branch
Keeping your systems secure is paramount for developing software. This includes your applications and development environments, but also your code repositories.
Supply chain attacks have been on the rise in recent years and are a severe problem for companies that lag in implementing security best practices. The sooner you address the security holes in your own supply chain, the better.
But you should remember that too many rules can slow down your developers, and if they have to ask someone for permission at every step of their work, they won’t follow your directions for long.
Stale repositories are an excellent place to start your security improvements because they aren’t in high demand, and changes to their permissions won’t affect as many developers as changes to your active repositories.
Arnica helps you improve your security posture when it comes to stale code repositories.
With our behavior-based automatic excessive permission reduction, you don’t have to manually check all of your repositories. It will generate minimal permissions based on the previous usage so your developers aren’t affected in their daily work.
.png)