Keep dependencies up to date, to make sure you can quickly apply a patch when it really matters - when there’s a critical security vulnerability.
Shipping more secure code begins with putting developers front and center—and fixing security issues from the start. In this series, we’re exploring big (and small) ways to build security into every step of your workflow. For our first post, GitHub Supply Chain Security Product Manager Maya Kaczorowski takes a closer look at dependencies: why you should keep them up to date and how to make sure you can quickly apply a patch when it matters most.
How many of us have ignored a software update, indefinitely clicking “Remind me later” and never quite getting around to it? Unfortunately, it’s pretty common. Not only are you missing out on the latest features, but you’re also putting yourself at risk if new security issues are discovered.
For dependencies in your code, it’s the same thing. Delaying dependency version updates doesn’t mean the update goes away, unfortunately—it just makes it even harder to address down the line. If an update doesn’t include a security patch, though, is it still okay to delay it? In fact, even when updates don’t address known vulnerabilities, regularly updating your dependencies improves your security.
The primary reason you should regularly update for security is that patches are just that—a bandaid, applied on the top layer, to address an urgent issue. Typically, patches will only come out for the latest version, or the supported versions, of a project. It’s rare for patches to be backported (even when they’re extremely severe) because creating these patches is a lot of work for maintainers. For every version a patch is applied to, a maintainer needs to validate that the patch actually addresses the security issue, and test that it doesn’t cause any other issues.
In rare cases, some patches can’t be applied to existing versions and require an upgrade. For example, this might happen when there’s a breaking change in functionality in order to stem a serious security hole. In that case, you must upgrade to be protected.
Some enterprises need to validate every component in their environment, including every update to those components. That’s fine—in that case, review updates to components on a regular basis, not only when there are critical security issues.
By regularly updating your dependencies, you can be on the latest version; when a patch is released, you know you’ll be able to apply it to your environment. This also follows the site reliability engineering (SRE) principle of applying incremental, gradual changes—it’s far easier to apply one critical security patch than to apply the last seven updates you missed in order to get that patch. Smaller changes to your system means that you’re less likely to cause adverse effects in your environment.
What’s better than applying a security patch? Applying a security patch and not having to roll back.
Expanding on the concept of incremental changes, by continually updating your environment, you’re not only giving yourself the ability to make ongoing changes, you’re also giving yourself the confidence to make ongoing changes. Proving that you can roll out a change to your environment regularly gives you confidence that you’ll be able to do it when it really matters, like a critical security issue.
In addition to lots of practice, testing is key here. We know from the DORA State of DevOps reports that developers can move faster when they have continuous integration and test automation. In DevOps, this matters specifically with mean time to recovery (MTTR) to respond after an outage. In DevSecOps, this matters with mean time to remediate (conveniently, also MTTR). When dealing with a critical 0day vulnerability, your remediation speed is also critical. You need to be able to act in hours, not days. Having sufficient testing in place means that you can very quickly deploy a fix, knowing it won’t break your environment.
Lastly, if you only update when there’s a security patch…well, you’re going to miss some security vulnerabilities. Many large open source projects thankfully have well-established security processes, including to address, fix, and release patches for newly discovered vulnerabilities.
However, in some cases, that doesn’t work as intended:
It’s rare that security patches are made available in updates without explicit disclosure, as once an update is released to an open source project, anyone can examine it, and may find the bug themselves.
You’re probably familiar with Dependabot security updates, a friendly bot that sends your project a pull request to update your dependencies when they have a security vulnerability. Dependabot security updates became natively available on GitHub last November, and we also recently added support for Dependabot version updates. Dependabot version updates check for new versions of your dependencies on a schedule you set, and suggest updates.
To enable version updates, check a dependabot.yml configuration file into your repository. Keeping your dependencies updated is now as easy as reviewing and merging pull requests.
By regularly updating your dependencies, you know you’ll be able to apply the latest security patch, you have confidence that you can make a critical change to your environment in a critical moment, and you can make sure you’re addressing bugs that may also have security impact. On GitHub, use Dependabot security updates to patch dependencies with known vulnerabilities—and now that you know, use Dependabot version updates to keep your packages updated all the time to help improve your security.
Looking for more easy ways to keep your code secure? Stay tuned for upcoming posts in this series or check out our security ebook..
We’ve dramatically increased 2FA adoption on GitHub as part of our responsibility to make the software ecosystem more secure. Read on to learn how we secured millions of developers and why we’re urging more organizations to join us in these efforts.
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
Maya Kaczorowski 
