How to apply security patches without the risk of exposing vulnerabilities

The conventional method for implementing changes in public repositories involves creating a pull request from our branch to either the main or feature branch. Subsequently, we request a code review, engage in discussions via comments, and once all concerns are addressed, we proceed with the merge.

Given that most of our web applications are publicly accessible on GitHub, applying security patches in the same manner may expose vulnerabilities to the public. Imagine creating a pull request that serves as a security patch, fixing a vulnerability in your web application. Naturally, you’d want to ensure the correctness of your approach. Typically, you’d request a code review, asking someone to thoroughly check and test it before making a decision to merge. However, this process takes time, and during this period, a malicious user could exploit the publicly available fix in your pull request, knowing the exact details of the security vulnerability.

In the case of security patches, a different approach is essential. Fortunately, GitHub provides a solution known as security advisories.

From the GitHub documentation on security advisories, we understand that they are used to privately discuss, fix, and publish information about security vulnerabilities in your repository. Let’s delve into how this system operates.

Security advisories are accessible in the Security tab of your repository. Click on the “Advisories” item in the left sidebar.

Only individuals with admin permissions for the repository can view its security advisories. Admins can add collaborators to security advisories (more on that below), and collaborators possess write permissions for the security advisory. You can find further details about permissions for security advisories in the corresponding section of the GitHub docs here. For those who are not repository admins or security advisory collaborators, this is what they will see when they open the Security tab:

The green button stating Report a vulnerability will be displayed if the privately reporting security vulnerabilities feature is enabled on the repository. If not enabled, the button will say Suggest a policy instead, making it impossible to report a security vulnerability. To learn how to enable this feature, refer to the official docs here. This means individuals who are not admins or security advisory collaborators can’t view any security advisories but can only report a new security vulnerability (assuming the feature is enabled).

To discover more about reporting a vulnerability on GitHub, please read the docs here.

Once a vulnerability has been reported, a maintainer of the repository will receive a notification and can either accept or reject it. Upon acceptance, a new security advisory is created, and the reporter is automatically added as a collaborator. A maintainers can add more collaborators to the security advisory if needed.
A maintainer or collaborators can then initiate a temporary private fork on the security advisory to address the security issue. A temporary private fork is precisely what its name implies – a private fork of the repository visible only to maintainers and collaborators of the current security advisory. It’s also temporary, created solely for a particular security advisory, and removed as soon as the required changes are applied. To create a temporary private fork, click on the button shown here:

A temporary private fork should be used to address the security issue. This means individuals involved (maintainers and collaborators) need to clone it and push their changes to it. After pushing a local branch, a PR can be created targeting the main branch of the main repository. This PR will not be visible to anyone else except the maintainers and collaborators of the security advisory. While you can create more than one PR on a temporary private fork, only one targeting the main repository’s main branch can be merged. Temporary private fork PRs will not run your GitHub CI actions, nor will they trigger any webhooks (meaning demo links will not be generated). You’ll have to run CI actions and conduct testing locally. Discussions can take place both in PRs and in the security advisory via the comments section, similar to other PRs on GitHub. However, these discussions are visible only to repository maintainers and security advisory collaborators.

When the change has been approved, and the PR is ready to be merged, proceed to click Merge pull request from the security advisory. Only after merging the PR will the commits appear in the commit history of the main branch of the original repository. This way, you ensure that any details about the security vulnerability were not exposed to the public until it has been fixed.

Good luck!

Last updated 1 year, 4 months ago.