Where do security patches come from?

Known vulnerabilities in software is a widely known problem, and was the cause of some of the world’s biggest security breaches, including the Mossack Fonesca (Panama Papers) breach, the VerticalScope breach in which 45 million passwords and IP addresses were stolen from a network of 1,100 websites, and the Ubuntu forums breach in which 2 million usernames and passwords were stolen.

The best solution for known vulnerabilities is to upgrade your software. However, that’s not always an option. There may not be a security upgrade immediately available for the software you rely on. Or, the upgrade may include major functional changes, known as “breaking changes”, which affect the way humans or other integrated systems access and use it. This makes upgrades expensive, and often infeasible.

A next best solution is to patch your software. A security patch is a an update for a piece of software which fixes the specific security issue, while making as few changes as possible to functionality.

For closed source software, the only way to obtain a security patch is to receive it from the software vendor and install it. A well-known example is Windows Update, which commonly pushes security patches to millions of Windows PCs. Managing patches from commercial software vendors is a burgeoning field and much has been written about “patch management”—the process for obtaining, testing and applying security patches for your applications. Numerous tools have been developed that help IT personnel identify that new patches have been released and deploy them on their fleet of computers.

Open source software is becoming the de facto standard for many organizational use cases, and especially as infrastructure for developing new software. Open source is just as vulnerable as closed source, but it is not always clear where you can get a security patch for the latest vulnerability. In addition, many open source maintainers are maintaining the project in their free time, which means that even after a vulnerability is discovered, the software may not be upgraded or patched for some time.

Four ways to find security patches for open source software

1. Upgrade or patch by the open source authors

The obvious place to look for a patch is a new version of the vulnerable open source software. Most often, vulnerabilities are fixed by the maintainers of the library.

2. Pull requests

In some cases open source contributors create a pull request, proposing code that can fix a security vulnerability. But it can take time until (if at all) the pull request is merged with the main software version.

For example, the popular JavaScript markdown parsing library marked had an XSS vulnerability with an open fix pull request for an entire year until it was incorporated into a new release.

If a pull request is open which fixes the vulnerability, users can download the code in the pull request and use it as a new, patched version. There is still the risk that the code changes proposed won’t work as expected or will create regressions in the software. So it’s advisable to check if the new code has been vetted at least by other members of the community, and test it before deploying.

3. Fork and fix

Users who are themselves developers have the option of forking—creating their own version—of the open source software, and fixing the vulnerability themselves. This has the advantage of reliability, because the fixer knows they have a stable version which fits their needs, minus the vulnerability.

The disadvantage is that by forking, users are cutting themselves off from the mainline of software updates and fixes, and may eventually find themselves in a more vulnerable situation. After all new vulnerabilities are discovered all the time.

4. Update feeds

RedHat and Canonical, two companies that support the Linux ecosystem, provide a feed of updates to Linux users, which includes security updates.

Canonical’s LivePatch service applies critical Ubuntu kernel patches without requiring a reboot of the system.

RedHat provides the Yum package manager, which allows you to update any Linux package to the latest available version, which in many cases will include security fixes. The yum check-update command checks which packages are installed that have updates available, and the yum update package command automatically updates them to the latest version.

The Yum security plugin indicates which updates are security-related; the plugin is available from RedHat Enterprise Linux 5.0, and built in with RedHat Enterprise Linux 7.0 and higher.

In addition, package managers such as npm (Node.js) and Maven (Java) can be helpful in keeping packages up to date and installing security updates, although they are not sensitive to updates that are security-related.

5. Snyk

A tool for managing known vulnerabilities should be a requirement in an open source workflow, but it's important to make sure the tool provides patching. That’s why we chose to build patching into our core offering from day one. We maintain our own set of patches in our vulnerabilities database. Most of those patches are back-ports of original fixes to previous versions that are still vulnerable. A few are pull requests, tested and packaged into patches you can readily install. And some are written by the Snyk security research team.

Those patches can be pulled into your automated build process using the CLI, or even submitted to your project in an automated pull request. By reducing the friction of patching, you’re able to quickly test and apply patches as part of your normal workflow.

Conclusion

Most if not all software products will become vulnerable, and will require upgrades or patches. It’s only a question of how quickly you can get your hands on a patch that resolves the vulnerability, and how easy it will be to apply it.

For closed-source software, users are dependent on software vendors, who are gradually becoming more responsive to security issues. For open-source software, an active community of maintainers is the best insurance policy against security vulnerabilities and other flaws. But in many cases, the open source community will not provide the patch you need, when you need it.

You can make the effort of sourcing or building a patch yourself — or turn to providers like Canonical, RedHat, or Snyk to provide an automated fix. With the growing complexity of the open source ecosystem, we predict that tooling will become an essential component of any organization’s security posture.