Security Measures to Restore Reliability in the Open-source Software Supply Chain

The need to strengthen open-source software security for improved safety

—What research are you conducting?

Much software relies on open-source software (OSS), which is developed and released by an unspecified number of developers (Fig. 1). When development companies create programs, they naturally develop their own unique functions in-house; however, for other general-purpose functions, they often combine various OSS libraries. The value of such OSS is said to be equivalent to $8.8 trillion [1], and it is now inefficient to implement even general-purpose functions in-house without using OSS. Even if developers don’t intend to use OSS themselves, many OSS libraries are included in non-open-source operating systems (OSes) and applications such as Windows and macOS; in other words, there is no escaping OSS.

Fig. 1. Numerous libraries and OSS make up a program.

The problem with OSS is that it could potentially contain malicious source code. In February 2024, it was discovered that the open-source library liblzma, included in Linux-based OSes, contained a backdoor by one of the developers (not the original author) with malicious intent. Ideally, it would be best to thoroughly assess the risks of all such open-source libraries. However, a single program often depends on hundreds of libraries, so it is practically impossible to assess the risk posed by each one. The source code included in a single piece of OSS can be quite substantial. Source code is a text file that can be described as the “blueprint” of a program. Although it is not easy to determine what kind of operation source code describes, determining whether the code is malicious is even more difficult. The proliferation of generative artificial intelligence (AI) has led to an explosive increase in the amount of source code due to the automation of dependent-library selection and code generation. Such an increase has made it difficult even for experienced developers to assess the code. Ensuring the security of the OSS supply chain has thus become even more important.

With the above issues in mind, I’m researching how to protect computers from malicious code, specifically focusing on methodologies and security measures.

—Would you explain the three-layer structure of the “sandbox method”?

As shown in Fig. 1, a single program may use a variety of OSS, and while it is theoretically possible to assess the risk of each individual source code, it is not practical. Given this impracticality, I’ve proposed (i) a method for assessing risk by analyzing the technical and social characteristics of OSS, preventing attacks before they occur, and (ii) a method for mitigating damage in the event of an unpreventable attack by confining the program to a “sandbox”^*1 beforehand. This mitigation method involves three layers: a library sandbox, container, and virtual machine (VM) (Fig. 2).

Fig. 2. Security using a three-layer structure and sandboxing.

(1) Library sandbox

A library is a collection of pre-built program components. Using a library makes it possible to avoid having to reimplement program functions, thus reducing development costs. However, the library may contain backdoors. My research aims to establish and promote a method for mitigating damage in the event of an embedded backdoor by confining the library to a sandbox, restricting system-call invocations, and prohibiting the execution of system calls in the case of unintended file access, network access, or attempts to execute commands.

While similar to the method using containers, which I’ll discuss later, this method uses a finer-grained sandboxing approach in a way that makes it possible to handle attacks that were previously impossible to handle. By analyzing not only the system-call operation of the library but also its social characteristics, such as who developed and reviewed it, it becomes possible to assess the risks before deciding to adopt the library. The library ecosystem varies greatly depending on the programming language, and it is difficult to support all the languages. Since the Go^*2 language is widely used in the Cloud Native ecosystem, I’m proposing a sandbox mechanism called “gomodjail” that targets Go libraries (Fig. 3). I plan to eventually support libraries in other languages as well.

Fig. 3. How the “gomodjail” sandbox mechanism works.

(2) Container

A container creates a separate execution environment from the main OS by pulling out a portion of resources, such as the file system and process tree. Enclosing programs within containers offers advantages such as preventing unauthorized interference between programs. Although a container is similar to a VM, it offers superior performance but inferior security compared with a VM.

(3) VM

A VM is a technology that makes a single computer look like multiple computers virtually. While a VM is slower than containers in terms of performance, it is superior in terms of security. VMs and containers are not necessarily competing technologies and are often used in combination. Using a VM also has advantages such as being able to run different types of OSes simultaneously.

By implementing sandbox-based security measures across the three layers—libraries, containers, and VMs—it thus becomes possible to strengthen security. While containers and VMs are now widespread, the idea of applying sandbox-based security measures to libraries is a pioneering effort by NTT and is still in its early stages.

—Would you tell us about the results of your research thus far?

I’ve been involved in the development of Docker (also known as Moby), the most well-known container implementation, from an early stage, and have served as a maintainer (development committee member) since 2016. I also maintain Docker-related projects such as BuildKit, containerd, runc, and the Open Container Initiative Runtime Specification. My most significant contribution in these projects is the implementation of “rootless mode,” which allows containers to be run securely without root privileges (administrator privileges). Even if there is a vulnerability in the container runtime and a malicious process escapes from the container, the damage can be mitigated using rootless mode (Fig. 4).

Fig. 4. Conceptual diagram of rootless mode.

I also launched “nerdctl” (contaiNERD ConTroL) as a Docker-compatible project based on containerd. The reason I launched this new compatible project was that Docker as OSS was temporarily stalled at that time, so it became difficult to incorporate the security and performance improvements that were being made on the containerd side. However, Docker as OSS has since regained its momentum.

I have also launched a project called “Lima” (Linux Machine), which is a tool designed to facilitate the convenient use of VMs (Fig. 5). Although Lima was originally created to demonstrate Linux environments, including containerd and nerdctl, on macOS easily, its growing popularity and expanding user community have led to it supporting a wide range of use cases and OSes. It has been gaining attention as a tool for safely running “AI coding agents”^*3. Since any file modifications proposed by the AI are not applied to actual files until the user reviews and approves them, users need not be concerned even if the AI were to go out of control. Lima is also not cumbersome. Users do not need to review and approve changes for every modification; instead, they can conduct a single batch review when the AI finishes its task.

Fig. 5. Example of Lima in action.

The Lima project has garnered approximately 20,000 “stars” (or “likes”) and around 180 contributors on GitHub^*4, while the nerdctl project has garnered about 10,000 stars and approximately 200 contributors. Both Lima and nerdctl have achieved a scale unprecedented for OSS originating from NTT. Not only used within the NTT Group, they have also been incorporated into products from other companies, such as AWS (Finch) and SUSE (Rancher Desktop), and are widely used across the industry.

—Would you tell us about the difficulties you encountered during your research and the challenges that you face?

A common challenge facing all OSS activities is the difficulty of getting proposals accepted. While facing opposition to a proposal is not particularly distressing, a lack of any response at all can make me anxious. Even for a proposal involving a change of just a few lines of source code, it is common for the acceptance process, from submission to approval and release, to take months or even years.

As a maintainer, I’m both a proposer and recipient of a large volume of proposals, and I feel sorry when I am unable to respond promptly to proposals from other developers. I understand the need for caution when considering changes to a program that is already functioning correctly. I believe that structural changes to the development community are necessary to ensure the quality of the open-source project while alleviating the burden on maintainers.

Ensuring high security by further strengthening security of OSS

—Would you also explain what your research makes possible, its potential applications, and future initiatives?

My research enables the safe utilization of high-value yet high-risk OSS by mitigating those risks. I envision applications such as AI coding agents. In the coming months or years, executing AI-generated code without manual review will likely become the norm. Even if an AI generates harmful code, whether due to hallucinations or being misled by malicious web-search results, sandboxing may mitigate the damage.

Regarding specific future initiatives, in 2026, I plan to fundamentally redesign the library sandbox to incorporate static analysis or source-code transformation during program compilation. By eliminating runtime overhead and enhancing practicality, I aim to drive widespread adoption across a broad range of OSS. From 2027, I will strive to implement library sandboxing for a diverse range of programming languages, extending beyond just Go.

Regarding containers and VMs, I aim to strengthen integration with AI coding agents and develop technology to mitigate the impact of vulnerabilities. I will also continue to explore other technologies that contribute to assessing and mitigating security risks associated with OSS.

I also endeavor to apply these technologies to NTT’s Innovative Optical and Wireless Network (IOWN) initiative. The IOWN initiative relies on hardware and software from a diverse range of vendors, including over 170 companies and organizations in the IOWN Global Forum, many of which depend, directly or indirectly, on OSS.

In particular, Data-Centric Infrastructure involves the flexible combination of products from multiple vendors that results in a vast number of OSS dependencies. I anticipate that bolstering security across the entire OSS supply chain will enable the safer, widespread deployment of IOWN.

When enhancing security through these technologies, it is necessary to ensure that performance and usability are not compromised. For example, the aforementioned “rootless containers” initially suffered from an 87% drop in network performance (TCP (Transmission Control Protocol) throughput), making them unsuitable for an All-Photonics Network environment. However, it was later improved to deliver performance comparable to normal containers.

—What you value most when conducting your research.

“Unusable security is not security.” That phrase appeared at DockerCon (a developer-focused event hosted by Docker, Inc.) in 2015. It is pointless to create security technologies in a vacuum if they are not actually adopted by users. I interpret this phrase to mean that rather than blindly pursuing stronger security, we can achieve more-robust protection by keeping measures within reasonable limits and considering their impact on user convenience. I aim to create technologies that naturally enhance security without requiring conscious effort from the user.

—Tell us about NTT Software Innovation Center, where you work.

NTT Software Innovation Center (SIC)^*5, to which I belong [as of the time of the interview], handles everything from fundamental research to practical development regarding the computing infrastructure supporting new services such as IOWN and “tsuzumi” (a large language model). SIC not only conducts technical research but also plays a role in cultivating processes that create shared value for both society and the company through collaboration with the OSS community and external vendors. The competence regarding shared value creation cultivated at SIC will undoubtedly prove useful to other organizations as well.

—Finally, would you share a message for researchers and students?

While technical expertise is certainly important regarding OSS research, negotiation skills are the most crucial factor. Even if you have devised a working code, unless you can persuade developers to adopt it, it will not be used in the real world. Accompanying the recent rapid advancement of AI coding agents, it is becoming increasingly difficult to assess a contributor’s technical proficiency; as a result, it is likely that OSS communities will increasingly evaluate contributors on the basis of factors beyond technical skills. Therefore, if you are interested in OSS, it would be advantageous to pay attention to skills such as negotiation and marketing. We at NTT will also be considering how best to conduct ourselves to enhance our influence within rapidly evolving OSS communities, so let us continue to strive for progress together.

Reference

[1]	M. Hoffmann, F. Nagle, and Y. Zhou, “The Value of Open Source Software,” Harvard Business School Working Paper, 2024.