The Gauge Approach to Magento Security Patches
Keeping your online store secure should always be a top priority. According to the 2017 U.S. State of Cybercrime Survey, the number of security breaches decreased in 2017, but the overall financial impact did not. And security threats are becoming harder to detect.
Just one security breach can cost your business a lot of time and money to repair. Perhaps even more importantly, a breach erodes the trust you’ve worked hard to build with your customers. With digital security, an ounce of prevention is truly worth a pound of cure.
If you’re on the Magento platform, you can significantly reduce your risk by keeping your site up to date with the latest security releases. I recently sat down with Gauge’s lead developer, Chris Roach, to talk all things security. Today we’ll cover Gauge’s approach to security patches, why they matter, and what you should know about them.
This interview has been edited for clarity and readability.
Kali: What are security patches and why are they important?
Chris: Security patches are basically code updates to fix vulnerabilities that can be exploited to steal data. Magento releases a patch or update when a security vulnerability has been found and it needs to be fixed. Vulnerabilities can happen because something was overlooked in the initial Magento release, or just because systems have changed over time.
Technology, languages, and systems are living things and they change constantly. Those changes can cause holes in a site’s security. You can build something that’s secure when it’s launched, but if you don’t keep it updated as technology changes, it will eventually become outdated and vulnerable. Security patches prevent that.
Kali: How does Magento find vulnerabilities? Do they fix problems as developers report them, or do they have tools they use to find vulnerabilities?
Chris: Both. Some holes they find on their own when something large changes in the digital environment. They also pay people to help them find vulnerabilities.
Magento does have a bounty for reporting security problems — if you find a vulnerability and report it, they’ll pay you. It’s easy to do. You open up a ticket with them and they’ll investigate the issue. If they find that it’s a legit vulnerability, they’ll give you cash. So there’s incentive.
Another way, for example, is NGINX, which is an operating system that we basically use to run Magento and it’s constantly getting updated. Some of the functions that it uses become outdated and when they become outdated, Magento has to go in and tell us when we need to change ours to use the newly updated service. If NGINX isn’t configured correctly, the site could be at risk for a breach. If an NGINX update creates a vulnerability, Magento alerts us to make the appropriate configuration changes to keep the client’s data safe.
The Gauge Approach to Security
At Gauge we take security seriously, so we want to make sure that every client’s site has the latest security patches. When Magento releases a patch, we start a process of assessing it and then applying it to affected sites.
First, we examine the patch and the vulnerability it addresses. We take painstaking care as we review how this particular patch could affect each unique site. Then we notify our clients, explain how it affects them, and communicate our plan for applying it to their site. Finally, we install it and run tests to make sure everything works correctly.
Because our developers are intimately familiar with the unique nature of each site, we’re able to be efficient and exact. I spoke with Chris to better understand the technical side of this process.
Kali: Does the Gauge development team have a standard approach for installing security patches, or is the process different for each client?
Chris: For Magento sites it’s pretty much the same across the board. We find what the vulnerability is, see which files the patch changes, and then determine whether that site has any custom modifications to Magento.
If a site has few or no customizations, it could be just a straightforward installation. But because we make modifications on top of Magento, when we add a patch we have to see if that affects our modifications as well.
Sometimes the patch only involves a couple of files, so assessment and installation are easy. Sometimes it’s a lot more than that, which can make it pretty difficult.
Kali: So if your site is highly customized, are security patches harder to apply?
Chris: No, I wouldn’t say that necessarily. It’s not more difficult; you still follow the same process every time. But it does typically take more time for customized sites.
Kali: How long does it typically take to install a patch, from start to finish?
Chris: Well again, it depends on whether the site’s been modified. Typically it takes between 3 to 10 hours, but it really depends on the patch and the site.
If a patch only requires a couple of file changes, it can be done super quickly. But most of the time Magento patches tend to affect anywhere from 50 to 100 files.
Security patches need a lot of testing and quality assurance. It’s important that we check them thoroughly. Sometimes Magento may create a patch that’s incorrect, or they’ve overlooked something, or it just doesn’t work with your customizations. If that isn’t caught, the patch breaks the site. Then we have to go in and fix it.
If a patch affects a customization or a function that’s used often, it can be a lot more time-consuming. We have to go through every single file and make sure those changes are made across the board. For instance, say you’re creating custom collections of products in the backend. If a patch changes the way you’ve been doing that, we would have to make sure that change is applied to every single instance where you’ve created those collections.
Kali: Does any patch stand out in your mind as especially challenging, or do they all present different challenges?
Chris: We’ve definitely had easier ones and harder ones. We just finished installing the most recent patch and that one was pretty easy. It becomes easier with repetition. The more familiar you get with the process, the more you know what to look for and how to handle it.
You have to really make sure that whatever you’re changing, you make that change to all of your customizations as well. If you miss one, that vulnerability is still there, and then what’s the point of adding a patch? It’s like an inner tube. If your tube has five holes, patching three of them may help, but in the long run, it still won’t keep you afloat.
So applying security patches isn’t overly complex or difficult necessarily, but it can be tedious work. You really have to do your due diligence.
Security for Magento 1 vs. Magento 2
Kali: The end of support for Magento 1 is approaching and Magento 2 is structured a bit differently. Can you explain the difference between security patches for Magento 1 and the newer security updates for Magento 2?
Chris: Magento 1 patches simply fix the vulnerability. Magento 2 security updates convert your entire platform to the newest version of Magento.
For Magento 1, every time Magento releases a patch, they release one for every version of Magento that hasn’t reached its end of support date. So to address the same vulnerability, they’ll release a patch for Magento 1.13, and another one for 1.14, etc. They’re releasing a bunch of different patches at once.
When you apply a patch, you’re still on version 1.13 or 1.14; you’ve only fixed that vulnerability. Then Magento also builds that patch into future versions. So if you were to upgrade to version 1.15, the new installation would automatically include that patch.
With Magento 2, Magento only addresses security vulnerabilities by releasing a new version. You don’t “patch” at all; you just upgrade the system to the newest version every single time. So if Magento finds a vulnerability in 2.0, they’d fix it by releasing 2.1.
Kali: Would you say the Magento 2 upgrade process is easier than the Magento 1 patch process?
Chris: Again, it depends. From a technical standpoint, I would say it’s just different. Overall, I do think the Magento 2 approach is better because it forces retailers to upgrade to the latest version. I think that’s smart.
Kali: But security updates are different than patches. Is it easier to update to a newer version on Magento 2 than it was on Magento 1?
Chris: It’s easier and better for the retailer, which is why they do it that way.
The End (of Support) is Nigh
Kali: We’ve heard that the end of support for Magento 1 Enterprise is 2020. For Community, the end might come sooner than that. They haven’t released an end of support date for Community, but Magento has promised to notify retailers at least 18 months before they discontinue support. What does that mean for retailers on Magento 1?
Chris: Basically, “end of support” means Magento will stop finding and fixing security vulnerabilities for that version of the platform. That’s one reason why Magento 1 retailers need to upgrade to Magento 2 or move to another platform. It won’t be safe to stay on the older versions past the end of support date.
If retailers stay on an unsupported version, their site will develop security vulnerabilities. It’s a guarantee. Once Magento stops looking for vulnerabilities and stops paying bounties, there will be little you can do. You won’t know what those vulnerabilities are so you won’t be able to fix them. You could pay a security expert to look for them on your site. But that will have to be done often and it will be expensive.
Moving to Magento 2 is the smartest option because it’s continuously updated to address vulnerabilities. Like I said before, technology is constantly changing. The longer you wait, the worse it’s going to get as languages evolve and best practices change. So now is the time to make a plan.
Kali: According to their service terms, Magento is also ending support for the first few versions of Magento 2. That’s a big change; they supported Magento 1 versions for a much longer timeframe. What’s your take on this change?
Chris: I think Magento is just trying to keep its customers up to date. They want retailers to upgrade because the newest version has (a) additional tools and features and (b) the latest security updates.
From a development standpoint, working with an older site on Magento can be pretty horrible. When a site is outdated, updating it involves a lot more than adding new features. We first have to fix any existing problems, resolve the technical debt, and make sure the code conforms to current best practices.
Updated versions of Magento are easier to develop on, more secure, and just better overall. They create a better shopping experience too. I think Magento recognizes that. By having shorter support timelines, they’re motivating people to upgrade.
The eCommerce landscape is a never-ending parade of flashy new tools and exciting new technology. Amid the marketing flair and sassy corporate Twitter accounts, it can be easy to lose sight of basics like ironclad security. But its importance can’t be overstated.
Magento is constantly working to maintain and improve security. My chat with Chris illuminated the reasoning behind some of Magento’s most recent improvements, and he underscored the urgency of strong security.
At Gauge, our goal is to deliver value and whole-business partnership that you can rely on. One way we do that is by including all security patches and updates in our Monthly Partnership Agreements. Keeping your site up to date is a critical part of site maintenance. But security releases are unpredictable, time-consuming, and expensive. Too often clients are hit with surprise bills after a patch is released.
But Gauge doesn’t bill by the hour. Because our service agreements are always fixed-price, our clients can sleep easy knowing their site will stay up-to-date and locked down, without any additional cost.
If you’ve got a question about Magento security patches or updates, leave a comment below. If you’re ready to talk about upgrading, replatforming, or ditching the hourly support model, drop us a line. We’d love to build a partnership with your business.