How to protect your GitHub codebase from identity threats

 Security posture management has come a long way in a relatively short time. The shift-left movement raised the profile of code hygiene, supply chain hygiene and broader cloud application security, and most organizations are doing a commendable job of securing code from the start and preventing back-door vulnerabilities. But there’s a fundamental gap that remains largely unaddressed: identity security within those cloud development tools.

That identity security gap is all the more concerning given that compromised credentials, not sophisticated hacks, are now the leading cause of breaches. Malicious actors aren’t hacking; they’re logging in. And without an identity security strategy that’s ready to catch those risks, you’re undermining even the best code hygiene.

GitHub code security: Breaches expose identity security gaps

Take GitHub — it’s the world's largest source code host, with over 100M developers worldwide contributing to more than 400M code repositories. GitHub is where thousands of companies store the “crown jewels” of their codebase, as well as the code behind their most confidential new products.

Given its ubiquity, it’s no surprise that GitHub has become an attractive target. A number of GitHub breaches have made headlines in the past few years, with big names like Uber, Okta, Samsung, Slack, LastPass, and the New York Times getting breached.  In 2023 alone, over 12 million authentication secrets and keys were leaked on GitHub.

Unauthorized access to blame 

Don’t take this as a knock against GitHub. Like the examples mentioned above, most breaches stem from compromised credentials allowing unauthorized access. Again, the bad actors aren’t breaking in; they’re logging in with legit credentials and freely accessing a company’s codebase.

This demonstrates that identity security is a very common and very risky gap in most organizations’ cloud security postures. And it points at a critical truth: Whether it’s a malicious external actor using stolen credentials or a disgruntled insider who has been planning a sabotage for months, if you can’t see who has access to what across your GitHub environment, you’re bound to be reacting too late to these incidents.

GitHub’s configurability makes identity security hygiene a tall order

One of the best things about GitHub also makes conventional IAM challenging: GitHub gives developers extensive configurability, but complex deployment settings mean subtle changes can have significant impacts on who can access what — and how. Security teams are left wrestling these complex deployment settings into governable compliance. Good identity security hygiene becomes a challenge for even sophisticated security teams.

In short, misconfigurations around access permissions, repository settings, and workflows can lead to unintended access. Identities have more access than necessary, and security teams often lack the visibility and capabilities to clean up those excessive permissions proactively.

Best practices for optimizing GitHub access

At Oleria, we not only help many of our clients to enhance and maintain the security of their own GitHub environments — we’re also working within GitHub everyday as we continue building out new functionality for Oleria Adaptive Security. Here is a set of best practices that are a great starting point for helping your organization address identity and access risks within your GitHub environment:

Enforcing MFA

• Mandate MFA (multi-factor authentication) for all users. Even if users are managed externally through single sign-on (SSO), MFA substantially reduces the risk of unauthorized access through compromised credentials. The higher the security level of your MFA e.g. those based on phishing resistant FIDO2 or WebAuthn, the better.
• Require MFA for all third-party collaborators. Third-party access management is its own beast. In this context, external collaborators and third parties present significant risk when MFA is not enabled, because any SSO requirement (and resulting MFA management) does not apply. Third parties that don’t use MFA or use a weak MFA factor could create potential attack vectors.

Limiting actions & controlling workflows

• Disallow workflows from approving pull requests. This prevents a malicious user from bypassing code-review restrictions by having an automated workflow that approves and merges their changes directly into production without any oversight.
• Restrict GitHub Actions to verified or explicitly trusted actions. Unrestricted workflows can allow unverified and potentially malicious actions into your development pipeline.

Securing code repositories

• Restrict GitHub Actions to selected repositories. Open access to GitHub Actions can be exploited to run malicious workflows, such as unauthorized access to secrets, or even crypto-mining.
• Set default member permissions for repositories to none. Leaving default permissions open allows new repositories to be visible to users who should not have access.
• Limit runner groups to selected repositories. Hosted runners are usually part of the organization’s private network and can be easily misconfigured. When using GitHub Hosted Runners, only allow workflows from private repositories to run on these runners. This prevents malicious actors from using workflows from public repositories to break into your private network and execute code.
• Permit admins only to create public repositories. This significantly reduces the risk of a user inadvertently or maliciously making an internal repository public and exposing confidential data.
• Mediate access to repositories through GitHub teams. Complex configurations can be simplified greatly by mediating access to repositories through GitHub teams, using either standard or custom role assignments. This ensures group-based control, simplifies the process of tracking who has access to what, and reduces opportunities for human oversight and error.

Enforcing least-privilege principles

• Limit the use of personal access tokens that have no expiration date. Tokens without expiration dates pose a significant risk if compromised, since they are not periodically reevaluated and could allow long-term access to fly undetected.
• Adjust the GitHub Workflow token permissions to read-only. In the event of a token compromise (due to a vulnerability or malicious third-party GitHub actions), this prevents a malicious actor from using the compromised token to sabotage various assets in your CI/CD pipeline, such as packages, pull-requests, deployments, and more.
• Eliminate admin access for accounts with no activity in the past six months. Inactive admin accounts are a major vector for identity attacks with escalated privilege. If an admin account does not have organization activity in the past six months, it should be reevaluated and likely removed.

Continuous monitoring and access certification

Conducting a one-time assessment to implement the best practices above will go a long way toward protecting your codebase from identity security gaps. But over time, even the most well-governed role-based access can lead to over-privileged access — rife with unused or dormant permissions that present major identity security risks. 

Jim, our CEO, went deep on this challenge in a previous blog. One of his key points: security teams need tools that can effectively monitor group utilization and continuously ensure that groups have the appropriate level of privilege and activity.

More broadly, security teams should regularly evaluate the holistic identity security access posture of their GitHub deployments to ensure good hygiene as the organization's needs and membership evolves.

How Oleria makes it easy to monitor & manage GitHub access

On the surface, this long list of best practices can look daunting. GitHub’s extensive configurability — perhaps its greatest strength — makes it difficult to stay on top of all of these access and identity hygiene principles. More to the point, implementing this framework — and doing it continuously — likely requires a set of tools and capabilities that many organizations do not have today. 

That’s why we built Oleria — to give organizations the risk monitoring tools to close their identity security gaps. Oleria and its GitHub integration module makes the process of implementing the above best practices and “getting to good” simple and seamless, by giving you three key capabilities:

1. Centralized risk monitoring visibility across your GitHub environment: We’ve done the hard work upfront, so our Trustfusion platform can connect directly to your GitHub environment and immediately give you a centralized view of risks across your GitHub environment. In addition, Oleria gives you an intuitive visualization of all of your identities and all of their access permissions through Access Graphs. This broad and deep risk monitoring lets your developers make the most of GitHub’s endless, granular configurability, without leaving you to unravel that web of access manually.

2. Utilization insights to enforce least-privilege principles: We also wanted Oleria to go beyond visibility to deliver focused risk monitoring insights. For example, Oleria automatically tracks access utilization across GitHub and shows you unused or dormant permissions in your environment. You can see dormant accounts, remove “ghost accounts” from former employees or offboarded vendors, and overall take a more repeatable, data-driven approach to enforcing least-privilege principles. This includes our Group Utilization insights that show you where group permissions or role-based access practices aren’t lining up with how users actually work within GitHub — so you can remove dormant users from groups or restructure role-based access policies.
3. Rapid incident investigation with fine-grained details: Oleria also makes it easy to connect risk monitoring insights with fast and effective action. When a risk or incident is identified, Oleria helps you answer the essential "who, when and what" questions in minutes — not days or weeks. Our Activity Analysis function automatically surfaces anomalous or suspicious activities to help you identify issues sooner. And Oleria gives you fine-grained activity detail, down to the individual resource and distinct operation (e.g. read or update). So, you can quickly dig into what happened, understand what’s been breached and what actions have been taken, and determine how to effectively remediate.

Secure developer identities should be the starting point for secure GitHub code

It’s worth repeating again that the shift-left movement has dramatically improved the cloud security posture in most organizations today. But the focus on securing code must extend to the identities of the developers and managers accessing that code. Because if you’re not securing the identities of those individuals, you’re leaving a very big gap in your cloud security posture.

Compromised credentials have become the Achilles heel of cloud security, subverting even the most robust DevSecOps practices. But by securing the identities tied to your development environments, you can strengthen the integrity of your entire development pipeline.

Fortunately, Oleria is one step ahead. We’ve already integrated with GitHub — and we’ve already built a set of next-gen identity security tools and capabilities that can directly close those identity security gaps many organizations have today. 

Want to see how Oleria can immediately add security to your GitHub environment? Contact us for a personal demo.