GitHub Security 101: Best Practices for Securing your Repository
Published: 2022-10-25 22:00:00

### What is open source software?

In 1998, Christine Peterson coined the term "open source software". She [explained](https://opensource.com/article/18/2/coining-term-open-source-software) that "it was a deliberate effort to make this field of endeavor more understandable to newcomers and to business". This was also the year for the first “Open Source Summit” [organized](https://www.oreilly.com/pub/pr/796) by O’Reilly.

Open source software refers to source code that anyone can inspect, modify, and enhance. Also the difference between “proprietary” or “closed source” software is that the authors make their source code available to others who would like to view it, copy it, learn from it, change it or share it.

Many people prefer using open source software for several reasons. They have more control because they can examine the code. It is regarded as stable for long-term projects because the projects adhere to open standards and will not disappear if their maintainers stop working on them. The community of users and developers is also important.

Open source is also considered more secure than proprietary software because anyone can view and modify it. A contributor can spot an error and raise a pull request to propose some changes. Nevertheless, it comes with its own set of security challenges.

### What is a supply chain attack?

A supply chain attack occurs when someone uses an outside provider or a third party that has access to the data and systems of your organization to infiltrate your digital infrastructure. Supply chain attacks are diverse but we will concentrate on the open-source supply chains.

Anyone can contribute to the development of a project with open-source initiatives. Using this entry point, malicious actors have programmed vulnerabilities into open-source solutions, making it easy for them to introduce new threats to companies that use the software produced, often without knowing it through traversal or indirect dependencies.

### The importance of Web Application Security?

Web application security is a concept that covers a series of security controls embedded into a web application to protect its assets from potentially malicious actors. It involves leveraging secure development practices and implementing security measures throughout the software development life cycle (SDLC) to find security vulnerabilities in the project and its configuration.

The good news is that you can implement protections within GitHub by using different applications and actions, whether it’s for the pet project that you want to demonstrate during a job interview or if you are a maintainer of an open-source project. This way you can give your project the same level of protection as for a proprietary project.

## Section 1 - The GitHub Marketplace and the GitGuardian App

### What is the GitHub Marketplace?

The GitHub Marketplace was [first introduced](https://github.blog/2017-05-22-introducing-github-marketplace-and-more-tools-to-customize-your-workflow/) during the GitHub Universe in 2016. It is a place where developers can find integrations and implement them into their workflows.

![GitHub Marketplace](https://blog.gitguardian.com/content/images/2022/09/image7.png)

### How can you leverage security tools to create a basic pipeline and implement guardrails?

You can leverage the security applications and actions available on the GitHub Marketplace to secure your pipeline at each stage of your development.

A basic pipeline would comprise:

-   a **software composition analysis** tool to focus on identifying the open source in a codebase so maintainers and contributors can manage their exposure to security and license compliance issues.
-   a **tool to prevent secrets sprawling** which is the unwanted distribution of secrets like API keys and credentials through multiple systems.
-   a **tool to cover status code analysis** which is a method of debugging by examining source code before a program is run where it analyzes a set of code against a set of coding rules.

### How to select relevant applications for your projects? What do you need to consider?

Choosing a tool, application or action will depend on your project or your team’s workflow. What kind of tech stack are you using? Are you deploying to Docker or using Kubernetes? How many steps in your pipeline do you have? Can you implement guardrails at each step?

You will find many tools and applications that could cover your needs. And the good news for OSS maintainers is that these applications are usually free for public repositories or OSS projects.

You can implement two tools to cover one stage - for example, Snyk and Mend to scan your dependencies. Both tools will have their pros and cons in terms of coverage and will help you have better visibility of your dependencies on your project. If you think one tool is better than the other, you can still remove the one you don’t need.  
Experiment and keep what’s best for your project!

Let’s take a look at the [OWASP Zap Baseline Scan](https://github.com/marketplace/actions/owasp-zap-baseline-scan) GitHub Action. This action scans a target URL for vulnerabilities and will feed it back to your project when you raise a pull request.

![OWASP Zap Baseline Scan GitHub Action](https://blog.gitguardian.com/content/images/2022/09/image1.png)

When you look at implementing an action or an application within your project, you will look at the different information available on the project page. Has GitHub verified this action? In that case yes, it has the little blue tick next to Verified creator. How many contributors are working on this project? How many stars did the project get? How many issues and pull requests?

Navigate to the GitHub repository and have a look at how actively the maintainers and contributors are pushing into the project. How well is it documented? Do they provide basic example usage, like a simple YAML file to start? Is it easy to implement? Will it cover your needs for your project in terms of programming languages?

Now let’s take a look at an example of an application with **GitGuardian**. You can find it by typing it on the search bar of the Marketplace.

![GitGuardian app in GitHub Marketplace](https://blog.gitguardian.com/content/images/2022/09/image8.png)

Navigating to the product page will give you more information. As a maintainer of a project, you will check the same requirements we describe earlier with the OWASP Action. We can see if GitHub has verified the application, the number of installs, and more information on the organization.

![](https://blog.gitguardian.com/content/images/2022/09/image4-4.png)

When you scroll down to the bottom of the page, you will see the pricing and setup section. GitGuardian offers free monitoring of public repositories. Select the account you want to install it on and click on "Install it for free".

![Install GitGuardian app prompt](https://blog.gitguardian.com/content/images/2022/09/image13.png)

You can choose to install GitGuardian on all repositories or select a few repositories. We would recommend installing it on all repositories. This will give you visibility on all the projects you’ve done and if there are any credentials publicly available.

Once you’ve done this, repeat this process for each stage of your pipeline where you consider that a security guardrail can be implemented.

## Section 2 - Managing your Open Source project

###   
How does it work on GitHub?

When a contributor raises a pull request, it will trigger all the applications and actions you have implemented in your pipeline. Ideally, in the case of GitGuardian, you would like the credentials to not be pushed to the source code and be stopped before the pull request is raised on the contributor’s machine. You can implement [GitGuardian Shield](https://docs.gitguardian.com/internal-repositories-monitoring/ggshield/getting_started) (ggshield) on your [CLI with a pre-commit git hook](https://www.youtube.com/watch?v=8bDKn3y7Br4) integration to add this additional guardrail and make sure no credentials are pushed in your source code.

When they don’t have ggshield set up, contributors pushing a  secret on the repository will be alerted when the pull request is raised. On this [dummy pull request](https://github.com/SonyaMoisset/OWASP-JS-Demo/pull/85), you can see some tools triggered during the process at the bottom of the PR. Depending on the application and actions, you can have a widget implemented within your PR.

![](https://blog.gitguardian.com/content/images/2022/09/image6.png)

You can make some of these tools required on your main branch. To do so go to the settings of your projects and in Code and automation, click on Branches. This is where you can add branch protection rules by making status checks required to pass before merging the PR.

![Branch protection rules](https://blog.gitguardian.com/content/images/2022/09/image12.png)

### How to get value from ChatOps?

ChatOps is a collaboration model that connects people, tools, processes, and automation into a transparent workflow. Using a free Slack account where you can have your team of contributors discussing, and having dedicated channels for specific tools will help you have visibility on what is going on in your projects. Monitoring and setting alerts is a vital piece where developers can help when they get the right information.

![](https://blog.gitguardian.com/content/images/2022/09/image2.png)

### GitHub Project - how can you leverage a board to follow up on security tasks

When working on an OSS project, you can leverage the GitHub projects to list all the tasks you have to work on for a specific feature. You can create labels and epics (milestones) to track progress or for raising issues. Create a Security label to track vulnerabilities in your project.

![](https://blog.gitguardian.com/content/images/2022/09/image5.png)

You can use automated projects or boards where cards will move accordingly to the status of the pull request. This is also a good way to showcase which feature you’re working on and where you might need some help and contributors.

![](https://blog.gitguardian.com/content/images/2022/09/image3.png)

### Showcase the health of your project with labels on the README file

If you want to attract more contributors to your project, don’t forget to showcase the health of your project using the little labels or tags that these applications and action workflows provide, and add them at the top of your project on your README file. You can learn more about badges in the [GitHub documentation](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge).  

## Section 3 - Hardening your Open Source project

Adding security guardrails at each stage of your pipeline is great, but you can also harden your open-source project by applying the following best practices.

-   Apply least privilege: set the base permissions to no permissions on the Member privileges section so they can only clone and pull the public repositories. To give a contributor additional access, the maintainer will need to add them to teams or make them collaborators on individual repositories. Create teams, add users and allocate them to specific repositories with specific permissions.

![](https://blog.gitguardian.com/content/images/2022/09/image16.png)

-   Make 2FA mandatory for all maintainers and contributors. By the end of 2023, [GitHub will require](https://github.blog/2022-05-04-software-security-starts-with-the-developer-securing-developer-accounts-with-2fa) all users who contribute code to enable one or more forms of two-factor authentication.

![](https://blog.gitguardian.com/content/images/2022/09/image10.png)

-   Protect your main branch: as mentioned above, make sure to protect your main branch to avoid any accidental deletion by a maintainer.

![](https://blog.gitguardian.com/content/images/2022/09/image14.png)

-   Enable notifications and alerts: update the email address to make sure you receive notifications from your project.
-   Add the correct license: an OSS license protects contributors and users. If you’re not sure about the correct license to use, [this](https://choosealicense.com/) is a good starting point, and make sure to have a LICENSE.md or LICENSE.txt on your repository.

![](https://blog.gitguardian.com/content/images/2022/09/image9.png)

-   Review the list of applications, tools, and webhooks: if you’re using several applications, tools, or webhooks for one step in your pipeline, review if it’s still applicable and delete any stale or unused ones.
-   If you rely on GitHub Actions to build, test and deploy your project, be sure to check your workflow configuration (you can use this [GitHub Actions Security Best Practices cheat sheet](https://blog.gitguardian.com/github-actions-security-cheat-sheet/)).

## Conclusion

Open source components can be a vector for large-scale cyber attacks. We’ve seen it last year with a vulnerability in Apache Log4j, an open-source Java package used to support activity-logging in many Java applications. While not all software written in Java is vulnerable, the affected package is widely used by developers and there are many applications and services that use this library. Big tech firms such as Microsoft, VMWare, Amazon, IBM, and others were affected.

Having visibility throughout your pipeline using different tools and guardrails is critical to reducing your attack surface and we have seen that leveraging the applications and actions from the GitHub Marketplace could help.

As maintainers and contributors, do not hesitate to create a small pipeline for a start and experiment with some of these tools, and harden your GitHub project for everyone contributing to it.

Experiment but most importantly do not push your keys on GitHub! :)