Secure at every step: Show your dependencies some love with updates

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.

Security patches are generally only made available for the latest version(s) of a package

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.

Regularly updating means you know you can actually update when it matters

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.

Security vulnerabilities, unfortunately, aren’t always disclosed

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:

• A security patch is shipped as part of a bigger update (like a minor or major update). In this case, you need to update to a new version anyways in order to get the patch. This may happen, as noted earlier, if a patch is not backward compatible.
• A security vulnerability is not disclosed, or revealed later. In this case, a bug may not have initially been noticed to have security implications, or the maintainer isn’t aware of how to specifically note security issues. Reading release notes helps.
• A security patch isn’t available, but a mitigation is. In this case, there isn’t necessarily a fix for the entire issue, but there may be a new flag, feature, or other behaviour you can take to limit your risk. That’s not strictly a security patch, so not always marked as such.

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.

On GitHub, use Dependabot version updates

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..

Written by

Maya Kaczorowski

@mayakacz