Why We Patch
Keith 
“The number one rule of software is if it works, don’t touch it.”
—Common IT saying (often attributed to Steve Jobs)
Some Maintenance Required
The common wisdom for software is that if an application works, don’t touch it. Change is risk, and risk comes with costs. Upgrade a dependency and you risk an unexpected outcome.
The reality is that virtually all modern applications have underlying dependencies—operating systems, programming languages, standard libraries, frameworks. All of these change over time, and every day new vulnerabilities are discovered with preexisting systems, some of which have been in place for years.
Letting dependencies go unpatched builds up technical debt, and paying that debt becomes more costly as the stack gets further behind. So with new vulnerabilities found all the time, the challenge is finding the right balance between the conservative “don’t touch it” approach and the need to keep updating to the current version.
What is a CVE?
Industry professionals track publicly-disclosed security vulnerabilities in software through ‘Common Vulnerabilities and Exposures,’ or CVEs. Each identified CVE has a standard ID, allowing governments, security researchers, software developers, and companies to identify and handle these issues. CVEs are evaluated based on a specific level of severity on a scale from 0 to 10, known as the Common Vulnerability Scoring System (CVSS).
Not every CVE merits immediate action. Determining when and whether to immediately apply patches, or when to relegate them to a regular patching cycle, is a matter of understanding the system and the vulnerability surfaces. Part of determining the immediacy of the need for patching is about the level and nature of the vulnerability, and part of it is about the specific exposure given the setup and deployment.
CISA
The US government has an agency tasked with maintaining a catalog of known exploited vulnerabilities, called the Cybersecurity and Infrastructure Security Agency (CISA). Their agency posts updates called the Known Exploited Vulnerabilities Catalog.
Coretechs frequently monitors newly-published CVEs, and uses resources such as CISA as part of a combination of automated and manual reviews to determine when to take immediate action.
Tracking Dependencies
It is easy to lose track of what versions of software an application or a server has deployed, or to miss a CVE or an update. At Coretechs, we monitor versions and keep logs and systems for documenting what versions are deployed. When there is a patch needed, we flag it and use reporting to track that it needs to be updated, so that we can keep track of the vulnerability until we get the updates done in a timely fashion.
Staying In Support
Immediate security vulnerabilities are not the only reason to update software. Operating Systems, programming languages, frameworks, and databases have a defined support lifecycle. While a version is ‘in support’ it has maintainers providing bug fixes, patches, and being vigilant about keeping them patched and upgraded. Eventually, the lifecycle ends and the software’s period of support goes through end of support, commonly called ‘sunset.’
Often the system may still work after the end of support, but there may then be new vulnerabilities and issues that accrue and do not receive patches or fixes. Planning version updates around the support lifecycle is part of keeping a system maintained as a long-term investment. The goal of a good patching and update process is to take steps to anticipate the lifecycle of these third-party systems and to make sure an application is kept upgraded with long term support in mind.
A Practical Approach
At Coretechs, maintaining software means knowing what is being used and how to update it safely. We track what dependencies, frameworks, operating systems, and versions our clients use across all of the systems we maintain on an in-house system just for maintaining software. Some systems are brand new, and others are legacy systems, where getting them updated can be more challenging.
The context matters. A vulnerability facing the internet with a threat surface exposed to the public is more urgent than one that can only be exploited by someone with physical access to a server terminal. Knowing how a system is built and deployed helps us understand that urgency and schedule those updates to work around clients’ schedules and budgets.
We regularly check newly-published CVEs and review them against our actively-maintained systems in detail. We have regular meetings to review and schedule patching and backups, to check that our servers are fully patched against high-risk security vulnerabilities and that all of our updates are run and documented on a regular cadence. We run automated checks against all of our servers and sites, looking for vulnerabilities though the use of automation. We constantly monitor for critical and high level threats.
AI is part of the patching and security landscape as well. AI has valuable tools for tracking and identifying vulnerabilities. On the other side malicious actors are using AI to find and exploit vulnerabilities. AI tools are part of the reason identified vulnerabilities are on the rise.
When to Touch
“If it works, don’t touch it” is an axiom of the software world, but sometimes there is more to it than that. Unnecessary changes introduce risk and can mean extra expenses and possible broken features. Upgrading to the new shiny version just because the version number went up can be bad engineering practice.
The same is true of leaving a system to go stale and rot, afraid to touch it and too risk averse to keep it safe and fully operational.
Good software maintenance is managing that tension. Professional software engineering is knowing when and how to patch and upgrade, and staying ahead of sunsets and evolving threats, and doing so with a particular balance of the needs of the client and the overall deployment in mind.
10400 Connecticut Ave #411
Kensington, MD 20895
