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 “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.
Patches are far from the silver bullets the megavendors would have you believe they are. Instead, they’re one part of a security process that must consider many other factors to keep the business fully and truly safe.
THE BACKDROP: SECURITY AND PERFORMANCE MATTER MORE THAN EVER
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.
A DEEPER DIVE INTO BUSINESS CYBERSECURITY CONCERNS
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.
In other words, a substantially high percentage of potential issues are fixable before patching becomes necessary. If X server had been properly configured, or if Y recruit had decided not to open a sketchy email attachment, only 18% of all reported cyberattacks would actually need to be reported.
A patch can technically be used to fix security issues that arise from configuration oversights, but it’s far from necessary. Companies only tend to go to this extent in unusual or high-risk circumstances.
To the contrary, in the overwhelming majority of cases, users can manage misconfigurations on their own or with the help of a non-OEM entity, such as a third-party software maintenance (TPSM) provider.
MEGAVENDOR PATCH GOALS CAN RUN CONTRARY TO BUSINESS NEEDS
Instead of considering every possible variable when problems arise, a 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 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.
The fix that works just fine for a base-level install could break key components of a modified implementation; the same patch developed for out-of-the-box deployments might not have the same (or any) positive effect in a custom environment.
All these factors point to an environment in which an OEM’s fundamental goals for patching a given product might not dovetail with the customer’s needs or growth plan at all. But patches are presented as the primary vehicle to fix problems, even if a patch isn’t needed. That can lead to misconceptions and issues that could be completely avoided with a different outlook.
PATCHING AND THIRD-PARTY COMPONENTS
Now let’s return for a moment to the problem of supply chain attacks in the enterprise. Of these, breaches involving open-source libraries and components rose 650% in 2021 alone, indicating 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.
And the supply chain attacks cybercriminals carry out are typically far from small-scale.
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 utilized in countless solutions at the enterprise level and below. 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 utilize. Security cannot or will not be considered for a broad number of reasons. When a security issue within one of those components arises, responsibility for a fix tends to shift to the person or entity maintaining the component.
And in other cases, a vendor might have to – or choose to – drag its feet on deploying a proper patch as 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 the issues within their third-party components.
That means a business might not know where a fix is coming from, who will ultimately be responsible for it, or when it will come down the pipeline. And as famously covered by beloved webcomic XKCD, that results in situations where niche component breakdowns can lead to large technological consequences.
It can even create situations in which 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 problems above, there are no shortage of ways in which the standard patching process can leave valid customers behind.
HOW THIRD-PARTY SOFTWARE MAINTENANCE PROVIDERS CHANGE THE PATCH-FIRST NARRATIVE
By contrast, TPSM providers make sure things work, no matter what goes wrong.
In some cases, the solution rendered might be an actual patch. When issues arise within the code of open-source components, for example, code changes can be implemented.
In others, the TPSM provider might partner with outside security services to obtain a fuller view of system health. By keeping a list of constantly updated definitions and checking against the customer’s software estate, the company can provide an overview that primarily focuses on the estate’s security by going beyond sharply defined OEM walls.
Practices that actively consider and shore up the entire system’s security, broadly defined as “hardening,” trump stand-alone patching in terms of overall security outlook. They enhance the business’s ability to work in its own interest, because they consider the business’s unique context. And perhaps most importantly, they give the business the ability to stay technologically proactive, freeing them from the reactivity inherent to the patching process.
Software is ubiquitous in business. When attempting to fix issues that touch some of the most crucial systems a company has, what’s more important — ticking a box that says you’re secure or actually achieving a holistic level of security that cares about your entire system’s health and operations?
As the average tech stack evolves away from harmful conventional thinking, it’s high time the industry at large reconsiders what patches are, what they do, and their dubious role as the best way to fix software problems.