Communications of the ACM
Software Insecurity
Software vulnerabilities are much more ubiquitous, intractable, and catastrophic than most people realize.
Credit: securityinnovation.com
No matter how many software vulnerabilities are identified, many more remain unpublished. Eighty zero-day vulnerabilities surfaced in 2021, according to Mandiant Threat Intelligence, but the total number is much higher, since we can only count those that criminal hackers exploit or researchers uncover.
Since vendors do not know all the software buried in hardware, applications, and devices, they can't fix all vulnerabilities. Log4J, the Java logging program famous for the critical Log4Shell vulnerability, is one example. It is challenging to unravel every transitive dependency on Log4J; the security community spent months looking for instances of Log4J so they could be patched. They still have not found every last dependency, and the repercussions of the Log4Shell vulnerability may continue for a decade, according to ZDNet.
Many factors, such as technical debt and software complexity, cause vulnerabilities to sprawl. The frequency and effects of these and other elements, such as spaghetti code and misguided code reuse, make it clear how software stays so fragile despite industry efforts to stabilize it.
"Broken!"
Software vulnerabilities are much more ubiquitous, intractable, and catastrophic than most people realize.
The security of a given software can count on some small, seemingly insignificant component, without which it fails. "In a prominent example, the author of the left-pad NPM software package removed it from the NPM registry over a trademark dispute. The missing component, only 11 lines of code, caused massive outages across a wide array of programs that relied on NPM," says Justin Cappos, associate professor of computer science and engineering at the New York University Tandon School of Engineering.
The global outages included broken software deployments such as the NPM software package React, which Facebook and other major websites use. There was "untold billions of dollars in economic damage to the still-nascent startup ecosystem of String Manipulation as a Service," according to the left-pad.io website. Left-pad.io provides left-pad functionality.
Seven tendencies and trends inflate coding errors that expose the software to failures and attacks. Technical debt, a frequent source of vulnerabilities, is work you owe software to fix imperfections you ignored to accelerate delivery. According to Cappos, developers fearful of breaking legacy systems use strange workarounds, which create new vulnerabilities and leave old ones untouched. "The software's creators may have left the organization, and the programming language may be unknown to the current development team, which leads them to avoid modifying legacy code," he says.
Spaghetti code ignores style rules and lacks simplicity and structure. According to Megan Samford, chair of the International Society of Automation (ISA) 's Global Cybersecurity Alliance, spaghetti code can confuse developers and software architects as to what code paths the software executes.
According to Samford, the errant code may make insecure function calls to software libraries with unknown security postures, resulting in unintended dependencies and unknown code execution. There are secure versions of function calls and libraries, but rooting out and replacing the existing code takes time. Developers may have to rewrite some code or remove it, Samford says.
In the meantime, the vulnerabilities invite security events and risks to the associated data's confidentiality, integrity, and availability.
Large codebases harbor increasing vulnerabilities, and their size—millions of lines of code—makes them difficult to refactor. "Large codebases have lots of dependencies. Large dependency chains leave developers unaware of the software their code uses, how developers wrote it, and whether it's secure," says Justin Cappos, one of Popular Science's Brilliant Ten scientists.
The more complex the software, the more likely it will contain coding errors. According to Megan Samford, vice president and Chief Product Security Officer of Schneider Electric, an energy and automation solutions company, overly complex code is complicated for developers to understand. Even its author may have trouble understanding it if too much time has passed since its inception. Intricacy forces mistakes, which multiply technical debt, and vulnerabilities ensue. "Keeping it simple," Samford concludes, "and applying the KISS principle is the best way."
Open source code is freely available, but vulnerabilities are costly. According to Samford, a community of interested developers maintains open-source code. If that interest wanes, maintenance and updates fall behind the latest coding standards, and the vulnerabilities accumulate, she says.
Repositories of software container images and open source code are subject to supply chain attacks, says Samford, adding, "The SolarWinds attack is an example of a software supply chain attack."
Software vulnerabilities can proceed from code reuse depending on how developers repurpose the code. According to Steve McConnell, author of Code Complete and CEO of Construx Software, a software development training and consulting firm, the most significant issues arise when reusing code in unintended environments with unstated software design assumptions. If the developer did input error checking assuming a specific universe of possible inputs, and a team reuses the code in a new environment with unchecked inputs, the software may be vulnerable to errors in that environment, McConnell says. Criminal hackers leverage poor input erro- checking in their attacks.
Pre-baked software security
An essential motto of the DevSecOps movement is baking security into development from the outset. By purging errors early in the development cycle and employing sound coding practices, programmers can minimize errors that engender vulnerabilities.
Said Ian Murphy, founder of U.K.-based cybersecurity training company CyberOff, with many breaches, the technology that failed us would have benefited from baked-in security.
David Geer is a journalist who focuses on issues related to cybersecurity. He writes from Cleveland, OH, USA.
No entries found