Patch and update management

Bugs occurring in software applications are an almost everyday phenomenon. Small errors often creep in unnoticed during adjustments, which can lead to malfunctions or even to - sometimes serious - security gaps. In the worst case, this can mean that unauthorised third parties can infiltrate the application with malicious code or access personal data such as address, contact or credit card data. We explain below what measures you can take as a shop operator to make such scenarios as unlikely as possible.

Update, upgrade or patches?

If changes are made to software, this is generally referred to as an update. This often has to be actively installed for the changes to take effect. Updates can serve different purposes: Some functionally expand the software, others fix bugs and problems.

Functional updates are also called upgrades. These can be divided into minor versions and major versions, for example. While minor versions are smaller functional enhancements, major versions often make larger changes to improve the user experience or performance.

Patches are usually released by providers to fix problems with bugs or security vulnerabilities in software. Different types of patches are used.

• Bugfix: This type of patch is used to fix technical problems and errors in the source code of the application.
• Hotfix: Hotfixes are time-critical and are used to fix serious problems within the application as quickly as possible.
• Security Patch: This patch type is focused on closing security vulnerabilities.

Less urgent patches that fix minor bugs and problems are often grouped into small update packages, sometimes in combination with functional updates. Hotfixes and critical security patches, on the other hand, require quick action, which is why these types of patches are usually released as individual installation files.

How are bugs and security vulnerabilities identified?

Providers must act quickly to fix bugs and vulnerabilities in the software - ideally before a vulnerability has been actively exploited. If this does not happen, the exploitation of the gap can harm software users. Due to their reputation, software providers have a legitimate interest in ensuring that the use of their software is and remains as secure as possible. To find bugs and security gaps, providers use various sources.

• Software tests: Regular security checks are mandatory for the provider. Those who do not check their software regularly risk being held liable for any damage that occurs....
• Community: Those who cultivate a relationship with their software community can draw on this valuable source of information. Even software users occasionally come across minor or major discrepancies within the software.
• Security Consulting: External security experts can assess the quality of the software, taking into account modern security standards, and provide relevant recommendations for action.
• Penetration test (pentest): In penetration tests, the security of system components and applications of a network or software system is tested. In this process, security gaps are uncovered that make it possible to penetrate the systems without authorisation.
• Bug Bounty: Maintaining a bug bounty programme can be an additional incentive for users or hackers to find bugs in the software and report them to the provider.

How high is the risk of security vulnerabilities occurring?

Security gaps can entail a varying degree of risk. Only a few customers or a large number may be affected. The likelihood that a security vulnerability will be exploited can also vary.

As soon as the provider becomes aware of a security vulnerability in his software, he first starts with the risk analysis. On the one hand, this includes the size and the possible effects of the bug. This involves analysing which software versions are affected, how the gap can be exploited, how likely it is to be exploited and what potential damage could result. On the other hand, it is checked which customers use affected software versions.

Based on all the analysis criteria, the risk of the vulnerability is assessed. This is usually done on a scale of 0 to 10, with 0 as an uncritical value and 10 as an extremely critical value.

Once the provider has assessed the risk of a vulnerability, incident management begins. This is a process that defines how to proceed with the problem and its resolution. Incident management has two goals. On the one hand, it should ensure that the developers can act quickly to find a solution and provide an appropriate patch. On the other hand, affected customers should receive detailed information on how to solve the problem as quickly as possible.

As a rule, a provider proactively informs affected customers as soon as a corresponding patch is available that fixes the problem. Public communication usually takes place later and does not contain as many details, as unaffected users should not be unsettled by the information. In addition, of course, potential attackers should not receive too much information with which they could possibly exploit the gap themselves.

Who is responsible for applying updates and patches?

Software providers regularly release new updates that pay attention to the functionality and security of the software. For the changes to take effect, the update must first be deployed. Who is responsible for this depends on the software's licence model and the provider's warranty.

With open source software, the provider only provides the patch, the download and installation must then be done by the user. With proprietary licensing models, such as those used for SaaS software, the provider often applies the patch automatically or allows the user to choose between automatic and manual updates. It may also be the case that providers install minor updates in the background without notifying the user.

All variants have their advantages and disadvantages. If updates are installed by the provider in the background, the administrator on the user side has less work. However, it is often not transparent which changes occur and what effects they have.

Manual installation gives the user control, but this means that the user has to keep himself informed about which new updates are available and which are required.

How do software users find out about security patches?

As already mentioned, most providers proactively notify affected users as soon as a security patch is available. However, there are other ways for users to find out about software updates. Many providers post changelogs, release logs and information about bug fixes on their website. Some also publish newsletters on relevant changes to the software. Major updates are often announced in advance on a public roadmap.

Other sources of information include community forums or relevant social media groups. Here, however, it should be checked how reliable the source really is and whether the information corresponds to reality.

When does it make sense to install a software update?

In general, the principle applies that software applications should always be up to date. Nevertheless, it is not always advisable to install the latest version of a software immediately after its release.

In the case of critical security gaps or functional bugs that affect the productive operation of the software, users should update their software as soon as possible, unless this is done by the provider. Although security patches are usually relatively small, they are usually subjected to a functionality test. This often includes destructive tests with false data, huge orders or access to other users. Normally, the installation of security patches is therefore relatively uncritical.

The situation is different with minor or major upgrades. These often result in major functional adjustments, so it is possible that older functions are no longer supported, or plug-ins and third-party software can no longer be connected reasonably. The more complex the technological set-up, the more caution is required.

In such a case, it may be worthwhile to first test the new upgrade under real conditions in a stage environment before taking it into live operation. It is also important to note that new software versions can also result in new bugs and security vulnerabilities.

How often are new updates released?

This question cannot be answered in a general way, as it varies greatly from provider to provider. Bug fixes, hot fixes and security patches are normally always published promptly after vulnerabilities or bugs become known in order to minimise the security risk.

With open source software, the support cycles are usually quite short and the density of updates is significantly higher than with proprietary software. This is possible because popular open-source solutions have a large community in the background that actively develops the product. However, short support cycles also mean that users have to update their software more frequently in order to continue to benefit from security updates from the respective provider.

Proprietary software, on the other hand, is supported for longer periods of time. However, since the provider's developer teams do not have access to a large community, the development of updates and patches often takes longer than with open source software.

Successful patching - this is how it works

Patch management, as a part of technology management, pays for ensuring the security and up-to-dateness of deployed software. Just like the software provider when creating the patch, shop operators should also define a process that includes the actual state of deployed software, an ongoing risk analysis and clear responsibilities when applying patches. The following tips can help shape the process and take into account all important aspects:

1. Survey the status quo: Get an overview of all software systems that are in productive use in your company at regular intervals. This includes not only shop, PIM or ERP systems, but also programming languages, web server and operating system technologies as well as other tools. Also keep an eye on the software versions. 2.
2. Weakness identification: Regularly analyse your software with regard to vulnerabilities and check to what extent security vulnerabilities reported by the provider apply to your software version. You can use an appropriate diagnostic tool to help you do this.
3. Risk assessment: Being affected by a vulnerability does not necessarily mean having to patch immediately. The risk can be measured on the basis of various aspects in order to assess the need for action. 4 Test the patch: Before applying the patch in your production environment, carry out load tests in advance in a stage environment. This will ensure that the patch does not have a negative impact on your existing system, interfaces or plug-ins.
4. Install patch: If the tests were successful, your team can start installing the patch. However, ensure through backups that you can return to the previous state if problems occur.

What to do if software is no longer supported?

If a software reaches End of Life (EOL) status, it is no longer supported by the official provider. This can have various reasons. On the one hand, there may already be a more modern software successor that replaces the previous product. However, the discontinuation of support can also be due to corporate decisions, insolvencies or company acquisitions.

Since such software is no longer provided with updates, its use in live operation becomes increasingly uncertain over time. Prompt migration to another system is therefore recommended for security reasons.

Particularly in the case of open-source software, however, it is sometimes the case that support is taken over by a third-party provider or the community. In such a case, one speaks of long-term support (LTS). This measure often gives software users the time they need to carefully prepare for migration to another system.

Conclusion

Continuous update management strengthens the security of your software ecosystem. In this way, you not only protect your own data, but also that of your customers. It is worthwhile to keep yourself constantly informed about changes and updates for software that you use in your company.

It is not necessarily necessary to install every security patch that is published by the provider. With a standardised process, you simplify the analysis and evaluation of possible risks and increase your productivity during testing and installation.

You should also keep an eye on the further development of software in use. If a software is no longer actively supported, it is advisable to look for alternatives at an early stage in order to exclude possible security risks.

Published on 05.09.2023 | DR, JHi