Code Libraries and App Frameworks: You Are What You Eat

The Need for Greater Assurance in Critical System Components

I was thinking about the complexity of our systems today and the need for greater assurance in those systems to support critical missions and business functions—in both the public and private sectors [1]. I started to peel back the onion a bit and decided to focus on software development and the use of code libraries and application development frameworks—and in particular open source software libraries and frameworks that are used in mission critical systems or systems that are part of the United States critical infrastructure. These systems require the highest levels of assurance and must be resilient and survivable from the tactical to the strategic level [2]. System assurance, in this context, is defined as the grounds for justified confidence that a claim has been or will be achieved [3].

Code libraries and application development frameworks have been used for decades in the software development process. They consist of useful reusable code. Libraries can include such items as functions, mathematical or logical operations, procedures, classes, values or type specifications, scripts, configuration data, help data, documentation, message templates, pre-written code, and subroutines. Code libraries also provide opportunities to interact with operating systems through the use of “system calls.” Library code is organized so it can be used by multiple independent programs. This is an example of “code sharing” that occurs routinely in software development processes, including DevOps and agile software development processes.

How Vulnerable Are Code Libraries?

Given that code libraries find their way into our most critical systems, how much trust can we place in that code? Moreover, what is the current “state-of-the-state” in code libraries and application frameworks across the software development community? A 2014 article in ComputerWorld by Lucian Constantin, addressed some of the concerns related to the use of code libraries. Turing Award winner, Ken Thompson, famously stated in a very succinct and cogent 1984 paper, “You can't trust code that you did not totally create yourself.” Many of these concerns still exist today. Code libraries and application frameworks can be a target rich environment for hackers and nation-state adversaries [4]. Why? Because libraries run with the full privilege of the applications they are supporting. In essence, code from libraries can do anything the application can do. That’s a very tempting target for adversaries.

Embedding malicious code in a code library is not that difficult and it can be anonymous. Moreover, with complex systems containing millions of lines of code, hundreds of thousands of components, and ubiquitous network connectivity, code libraries represent a significant part of the system and ecosystem attack surface. As my colleague Jeff Williams noted in his 2017 presentation at the OWASP AppSec USA Conference, although a small percentage of executing code comes from libraries, it can still represent significant risk to application users. While some vulnerabilities in code libraries are known, the vast majority are latent, yet to be discovered.

Several years ago, security researchers did an experiment where they built 5000 Java libraries from their source code repositories. When comparing the binary files from the researcher’s versions and the versions in the public repository, 11% of binaries didn’t match the source code. The potential causes could be malicious code insertions or a process failure at the source. Without further information, we are left with a great deal of uncertainty—we don’t know what we don’t know. What we do know is that the opportunity for another SolarWinds through this part of the supply chain is extremely concerning. Just imagine the insertion of a Trojan Horse in a commonly used utility such as “Log4j.” The adversaries would be running essentially as superusers with “root access” in many government and corporate data centers around the world in less than a year. There is very little attention paid to the threat of “malicious developers” and the significant risk it poses to organizations.

Providing appropriate levels of assurance for code libraries and application frameworks is enormously challenging. Currently, the primary focus on assurance in code libraries involves checking the libraries for known vulnerabilities. There is virtually no independent verification for any of the millions of open source software components in use in critical systems today. We know very little about the provenance of such code—including who wrote code, how the code was tested, what security functions were employed, the type of development environment and compilers used, and how the code is maintained.

In the systems security engineering process, a “system” is made of up a well-defined set of system elements—including hardware, software, and firmware components [5]. Many of those system elements represent code libraries. Systems security engineers are concerned about every system element and the interactions among all system elements. It is imperative that security engineers have sufficient evidence to determine the level of assurance for all system elements so they can make credible, risk-based design decisions with respect to the potential adverse impact or negative consequences of a particular component on the overall behavior and performance of the system. Code libraries and application frameworks certainly fall within the “area of concern” for system developers and security professionals.

An Opportunity for DevSecOps

The community of software developers needs an established process for defining the “quality” of code libraries and application frameworks and a method to determine if such quality has been achieved. We label ingredients in commercial food and drug products to give consumers more information so they can make informed decisions. Users of code libraries and frameworks need similar information that is readily obtainable and can provide key metrics for measuring the quality of code and artifacts. As we enter into the brave new world of DevSecOps, there is a great opportunity to bring some “assurance” to the wild, wild west of code libraries and application frameworks. It might be an appropriate time to start a national dialog on a supply chain problem that affects all organizations—large and small—in every sector—and in every industry. Here’s a brief set of questions to start the discussion:

• Should quality standards be established for code libraries and application development frameworks?
• How should code library and framework quality be measured?
• Should there be a certification process for code libraries and frameworks?
• Should there be a trusted distribution system for code libraries and frameworks?
• How do we make security attributes visible to the consumers of code libraries and frameworks?

Code libraries are everywhere—in supercomputers, weapons systems, power plants, servers, and IoT devices. It’s the code our critical infrastructure relies on. Software developers use libraries and application frameworks to bring software to market faster. They import a lot of risk along with these libraries, but they don’t have any effective way to deal with this risk. So many developers simply ignore it—effectively passing the risk on to consumers [6].

Now is the time to get serious and take action regarding code library and application framework assurance [7]. It is both a national and an economic security issue. We need greater transparency in code libraries so software developers can tell the difference between libraries that are secure and ones that may contain malicious code. Alternatively, if we do nothing, this just might be a problem for Clint Eastwood. Are you feeling lucky today?

[1]  R. Ross, “Securing the Ecosystem”

[2]  R. Ross, “Protecting the Nation’s Critical Assets”

[3]  International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 15026-1:2013, “Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary”

[4]. R. Ross, “The Adversaries Live in the Cracks”

[5]  NIST Special Publication 800-160, Volume 1, R. Ross, M. McEvilley, J. Oren, “Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems”

[6]  Zurkis, K. “The Truth About Vulnerabilities in Open Source Code”

[7]  R. Ross, “Time to Get Serious About Assurance”

A special note of thanks to Jeff Williams and Mark Winstead, long-time cybersecurity and SSE colleagues, who graciously reviewed and provided sage advice for this article.