GitHub officially recommends using GitHub Apps when integrating with GitHub, as they are easy to build and enjoy a rich and extensive API.
Most of us GitHub users have probably installed at least a few GitHub Apps, but have you ever stopped and wondered about the security and complexity of introducing a 3rd party app to GitHub, and the inherent risks that the integration poses?
In this blog we’ll step into an organization’s admin shoes when asked by one of the developers to install a JavaScript code-linter GitHub App, and through this example understand how to secure GitHub Apps throughout the 4 phases of an app’s lifecycle.
GitHub Apps in a nutshell
There is an abundance of GitHub Apps in the GitHub marketplace where you can find GitHub Apps in 19 different categories enabling automation in different aspects, whether it’s to run security checks, code linters, unit tests, backing up repositories and many more scenarios.
GitHub Apps don’t necessarily need to be listed in the marketplace in order for users to be able to use them, as they can also be installed using an installation URL.
Technically, it takes only a minute or so to integrate a GitHub App into your organization. Apps can be installed on organizations or personal users accounts, and after an app is installed – it acts on its own behalf, performing actions via the API directly using its own identity, which means the organization doesn’t need to maintain a bot or service account as a separate user.
The GitHub Apps permission model
GitHub Apps offers an impressive list of repository, organization and user permissions to control access to GitHub, ranging from vulnerability alerts to actual code base and repository administration. In total, 30 different app permissions can be set to ‘none’, ‘read’, or ‘read + write’.
The default app permission is set to ‘none’. As the app builder, this means that you have to specifically choose the permission that the app requires via the app configuration settings. Adding permissions to an existing app requires a new permission approval cycle, in which the app users need to agree to grant the app owner the new permissions.
In addition, GitHub Apps can be installed on organizations, narrowing their scope by allowing you to grant access to specific repositories. For example, you can install an app called MySecretScanner that scans code for secrets in the MyRepo repository, or simply select ‘All’ repositories.
Personal users, not under the context of organizations, are allowed to install GitHub Apps on their own repos, while in organizations only an organization owner can install a GitHub App.
Governing 3rd party apps
It’s important to monitor a GitHub App throughout its lifecycle. If the onboarding (approval) process of a GitHub App to your organization is the only interaction with the GitHub App, you may be putting your organization in jeopardy. Let’s break down the issues you need to properly address the risks of using GitHub Apps.
Approval
Going back to the developer request to install a code-linter GitHub App, this sounds like a very logical request, as code-linters can dramatically improve code readability, flag potential problems and even squash some bugs early on.
As a responsible administrator, you perform a vetting process to verify that the app publisher is legitimate. Check for a GitHub verified creator badge, GitHub’s own publisher vetting process that ensures that the app meets several requirements including GitHub having a way to contact the app creator, that the creators have enabled two-factor authentication for their organization, and that the organization’s domain ownership has been verified.
Code-linting is important, therefore you decide to install the code-linter app on all of the organization’s repositories. It’s worth mentioning that the code-linter app will automatically be granted permissions on newly created repositories.
It’s crucial to understand and acknowledge that by installing a GitHub App you are in fact inviting an outside collaborator into your GitHub organization to take part in your company’s intellectual property. This 3rd party is an entity that you don’t have control over or have a deep relationship with, if at all.
Integration
It’s imperative to keep visibility of 3rd party services around your CI\CD, asking yourself the following questions:
- Which apps are installed?
- What permissions do they have?
- On which repositories are they actually using their granted permissions?
Following the important principle of least privileges is important, the org admin must make sure that the permissions GitHub App asks for corresponds with the GitHub App requirements.
We’ve all seen the pain inflicted during the recent security incident affecting Heroku and Travis-CI or the case of DeepSource, in which app credentials were stolen by an attacker. Any organization that installed these apps could have been impacted by this security incident, allowing the attackers to access their codebase or to penetrate their production systems either by commencing PPE attacks or by using secrets lying in the code.
Visibility over ongoing usage
Did our administrator verify which organization resources the linter-app has access to? Does the app have any unused permissions or is the scope of the application in the organization’s repositories too wide?
Permissions granted to 3rd party apps are a concern that requires constant monitoring. Excessive app permissions should be detected and treated. It’s important to check for both ‘read’ and ‘write’ permissions that are not actively in use. In our example, the app might scan pull requests for the purpose of code linting, but does not use its granted write permission.
By definition, GitHub admins cannot reduce GitHub App permissions. Therefore if there’s a need to reduce a certain permission, or there is no clear understanding why certain permissions are required – the only option is to contact the app publisher asking for clarifications or modifications. App publishers could range from well established vendors to independent open-source maintainers, so you should probably expect different levels of cooperation. Also, if the publisher decides to accept your request and reduce permissions, it’ll affect all organizations using the app – which eliminates the option of customized permissions per organization. You can always consider suspending or deleting the GitHub App if your concerns are not addressed.
Another issue with app permissions is the scope granted on the organization’s repositories. In our case we installed the code linter app on all of the organization’s repositories as all repos included JavaScript, but over time most of the new repositories became purely Python-based. As a result, the app does not scan these repositories, but still has access.
By not limiting the scope of the code linter app to JavaScript based repositories, the admin has potentially enlarged the attack surface of the organization, as attackers who gain access to the JavaScript linter will not only have access to the repositories including JavaScript, but will also be able to access Python-based repositories.
The issue above raises a dilemma – you have to balance between automatic coverage of new repositories by leaving the installation scope of an app on ‘all repositories’ vs the ongoing and costly manual effort of installing apps on handpicked repositories, in order to eliminate unnecessary exposure to repositories.To maintain the security posture of your organization it is important to limit GitHub Apps’ permissions and scope to those absolutely essential. Monitor your 3rd party apps’ on-going usage in your organization to detect excessive permissions and/or unnecessary repository exposure using the GitHub Audit Log, and API endpoints like events.
Deprovisioning
As the administrator, you should put procedures in place to check whether the code-linter is being maintained by the original developer or whether the app has vulnerabilities. Also they should verify if the app is no longer relevant to the organization’s needs, if for example the organization found and installed a much better code-linter months ago. If redundant, the app should be deleted to minimize risks.
The organization administrator should periodically review all integrated 3rd GitHub Apps, check their actual usage to detect idle apps due to POCs that have ended or through lack of need, and either suspend them until further inquiry (blocking access to the apps) or delete them.As we have shown in this blog, risks relating to the ungoverned usage of 3rd party services rely on the extreme ease with which a 3rd party service can be granted access to resources in CI/CD systems. For more on the risk of Ungoverned Usage of 3rd Party Services, see the “Top 10 CI/CD Security Risks”.
Summary
GitHub Apps truly provide great value and are easy to integrate, but they do come with a security price tag. By applying the principles described in this article, you can significantly reduce your organization’s potential risk from 3rd party GitHub Apps.
