When it comes to software patches, expectations and reality are often two different things.
The misconception starts with the very terminology businesses use to describe the practice and the expectations they attach to it.
TechTarget calls a patch “a quick-repair job for a piece of programming designed to resolve functionality issues, improve security, or add new features.” But beyond the 30,000-foot overview, there is no one accepted definition of what a patch is.
That’s a real problem in the business tech world, where stakeholders tend to regard patching as the end-all-be-all solution to emergent performance and security problems. Getting no results from the solution a company expected to be a silver bullet is one thing; making the situation worse when the dust clears is another, much larger, concern.
Understanding the problem with patch-first thinking requires a grasp of the landscape modern IT leaders must navigate.
Every company’s situation is different, but two factors sit at the foundation of many serious technology blockers.
First, supply chain attacks have become a weapon of choice for cybercriminals. They effectively negate the primary victim’s ability to directly defend itself and can come from components that make up some of the company’s most important systems. An affected business can do everything right, tick every box, and apply every patch, and still end up with huge risk and liability due to cybercrime.
Second, with software playing a central role in nearly every business activity imaginable, even minor performance issues or outages can create negative experiences with customers on one side of the counter and poor productivity for staff on the other.
Moreover, these concerns can express themselves in an endless array of negative business outcomes, such as lengthy, resource-intensive migrations and security issues. Having to work in a scene like that, where any number of things inside or outside the company’s control can turn sour, it’s hardly any wonder IT stakeholders are losing sleep and breaking out the Tums.
Now pair the notion above with a simple, but highly telling statistic: as many as 82% of reported breaches occur as the result of human error or oversight, such as misconfiguration.
A substantially high percentage of potential issues that can be addressed to an acceptable level are fixable before patching becomes necessary.
Because there is no international definition of a patch, one may be used to automate configuration to address an oversight that could leave a product vulnerable on initial deployment. However, this vulnerability may not be obvious to the user. Additionally, self-configuration allows the technology owner to ensure no unintended impact on operations. If the required skills are not available, this can be done with the help of a non-OEM entity, such as a third-party software maintenance (TPSM) provider.
Beyond internal errors and misconfigurations, the way megavendors approach patching introduces another set of challenges.
Instead of considering every possible variable when problems arise, a software megavendor’s default goal is volume. After all, remediating the issue for the broadest number of users possible (with the least amount of impact) makes business sense when a software vendor serves huge tracts of customers.
In other words, the standard patching process inherently leaves customers’ unique deployments and situations by the wayside.
A one-size-fits-all fix such as a patch can never consider a company’s unique context, but technological context is a core differentiator and driver of growth for most companies. An OEM patch developed exclusively for a mass-market idealized audience must by its very nature avoid deployment wrinkles that companies include as a basic function of business.
All these factors point to an environment in which an OEM’s fundamental goals for patching might not align with a customer’s needs or growth plan at all. Yet patches are presented as the primary vehicle to fix problems, even when they aren’t needed. That can lead to misconceptions and avoidable issues.
A patch, if available, is only one part of an effective vulnerability management and cybersecurity program.
Now let’s return for a moment to the problem of attacks on third-party components within an enterprise. Of these, breaches involving open-source libraries and components rose 650% in 2021 alone, highlighting a huge source of opportunity for cyberattackers.
A perfectly secure digital environment is impossible to achieve. But even if a company did somehow build an impenetrable product based on 100% secure proprietary code, the moment they introduce an outside component, such as an API or open-source library, their overall ability to secure the product is diminished.
In 2021, for instance, researchers rang the bell on a 10/10 “worst of the worst” security vulnerability within Log4j, a ubiquitous open-source library used in countless enterprise solutions. The exploit that arose from this vulnerability, known as Log4Shell, sent shockwaves through the cybersecurity, technology, and business communities when discovered.
In many situations, megavendors only check the interoperability of the open-source components they use. When a security issue within one of those components arises, OEMs might not possess the required technical skills in-house, so responsibility for the fix can shift to the person or entity maintaining the component.
And in other cases, a vendor may have to—or choose to—drag its feet on deploying a proper patch while it waits for more information or for the situation to develop. If that product has reached end of life, it might make little to no business sense for the vendor to address issues within its third-party components.
That means a business might not know when a fix is coming, or who is ultimately responsible for its development. And as famously covered by beloved webcomic XKCD, niche component breakdowns can lead to large technological consequences.
It can even create situations where customers aren’t certain whether the systems they rely on are vulnerable, or what they should do next. Instructions and documentation relating to open-source components are famously sparse. Combined with the challenges above, there’s no shortage of ways the standard patching process can leave valid customers behind.