Van-Vi Vo, Duc-Tai Le, and Hyunseung Choo 11institutetext: Department of
Electrical and Computer Engineering,
22institutetext: College of Computing and Informatics,
Sungkyunkwan University, Suwon, South Korea, 22email<EMAIL_ADDRESS>

# Minimal Sleep Delay Driven Aggregation Tree Construction in IoT Sensor
Networks

Van-Vi Vo 11 Duc-Tai Le 22 Hyunseung Choo 11

###### Abstract

Data aggregation is a fundamental technique in wireless sensor networks (WSNs)
in which sensory data collected by intermediate nodes is merged by in-network
computation using maximum, average, or sum functions. Because sensors run on
batteries, energy conservation is a critical issue. Duty cycle is a well-known
energy-saving mechanism in WSNs, but it causes data aggregation latency to
increase. As a result, the use of multichannel technology allows more sensor
nodes to send data simultaneously, reducing data aggregation latency. We
investigate the minimum latency aggregation scheduling problem in multi-
channel duty-cycled IoT sensor networks in this paper. We propose a scheduling
scheme that first constructs an aggregation tree based on sensor node sleep
delay, then improves parallel transmissions by scheduling all eligible nodes
in the constructed aggregation tree to enhance data aggregation. Based on
extensive simulation experiments, our proposed approach lowers the aggregation
delay by at most 61% compared to a novel approach.

###### keywords:

Wireless sensor network, internet of things, data aggregation, duty cycle

##  1 Introduction

Wireless sensor networks (WSNs) are becoming more prevalent in Internet of
Things (IoT) applications. A WSN is composed of a number of sensor nodes that
are typically deployed in inaccessible areas, such as undersea, underground,
or within the human body, to collect and measure data, which is then collected
by a sink or base station [1]. Sensors are battery-powered and have limited
computation capabilities. Data communication between intermediate nodes, on
the other hand, necessitates a significant amount of energy. Data aggregation
is an effective method for integrating data to address this issue. This
technique reduces redundancy in sensory data. Furthermore, it has an effect on
data aggregation delay.

While aggregating data, sensors in the network do not constantly send and
receive data. Keeping the network active while not performing any tasks wastes
a lot of energy and shortens the network’s lifespan. To address this issue, a
duty-cycling mechanism is used to convert energy when the sensor nodes are
idle [2]. When sending or receiving data, sensors in the duty-cycling
technique are active, and when idle, they are inactive. When sensors are not
in use, they save energy. Because the inactive period is longer than the wake-
up period, the technique conserves more energy, but the data aggregation delay
increases.

Time and energy efficiency in data aggregation are major concerns in WSNs.
Many studies have been conducted to investigate energy-efficient and time-
efficient data aggregation problems in WSNs [3], [4], [5], [6]. The
researchers of [3], [4], [5] investigate how to improve sensor network energy
while minimizing latency in data aggregation sensor networks. KhadirKumar, et
al [3] propose a data aggregation strategy that produced more efficient data
aggregation, throughput, and lifetime results. In contrast to [4] which
addresses the problem in battery-free sensor networks, the authors propose
three data aggregation algorithms considered energy-collision aware that build
an adaptable aggregation tree that takes into account residual and harvested
energy in each sensor to reduce aggregation latency.

The minimum latency data aggregation (MLAS) problem in duty-cycled WSNs is
first investigated in [5], which has been shown to be NP-hard, and they use
connected dominating set (CDS) to construct the routing structure. The authors
of [6] propose a distributed algorithm using multichannel on an aggregation
tree to reduce latency. The use of multiple channels helps to increase the
number of concurrent transmissions at each time schedule. In this paper, we
propose a time-efficient data aggregation scheduling algorithm for
multichannel duty-cycled sensor networks. One study uses CDS to investigate
reducing latency for data aggregation in multichannel duty-cycled wireless
sensor networks [7]. In this paper, we propose a new method for building the
aggregation tree based on the active time slots of sensor nodes, as well as an
improved scheduling scheme. We conduct intensive simulation experiments to
examine the effectiveness of the proposed scheme with the reference. In terms
of latency, the proposed algorithm outperforms the reference scheme.

The rest of the paper is structured as follows. The network model,
assumptions, and problem formulation are presented in Section 2. Section 3
then goes over our proposed scheme. Section 4 compares the experimental
results of the proposed scheme to the modern approach. Finally, in Section 5,
we wrap up our work and plan for the future work.

##  2 Preliminaries

###  2.1 Network model and assumptions

Consider the undirected graph $G=(V,E)$, where $V$ be a set of sensor nodes
including a sink node $s$ and $E$ is a set of communication links between
nodes. Each sensor node has a uniform transmission range $d$ and is outfitted
with an omnidirectional antenna for wireless communications. According [8], we
employ the interference model, in which sensor nodes, due to their half-duplex
mode, cannot transmit and receive data at the same time. An interference
occurs when a sensor $u$ sends data to a receiver $v$ while $v$ is within the
interference range of another unintended concurrent transmission. The
interference range of a sensor node is denoted by $d_{I}$, $d_{I}\geq d$.
There is a set of $m$ given channels $F={f_{1},f_{2},…,f_{m}}$ can be used to
allocate to sensor nodes. The usage of different channels for sensor nodes
increases interference-free concurrent transmissions. Consequently, the total
aggregation delay is reduced.

To save energy, we assume that sensor nodes use duty-cycled mechanisms like
[9]. The sensor nodes in this mechanism switch between sleeping and active
modes independently. Sensor node network lifetime is split into working
periods with the same length $T$. Each working period is further divided into
$W={0,1,…,(T-1)}$ time slots. Each time slot is assumed to be a sufficient
time for a successful data transmission. Every sensor node has its own
sleeping and active time slots in a working period, and the sleeping and
active patterns of sensors repeat in every working period throughout their
entire lifetimes. The sensors are inactive during their sleeping time slots
and awaken to receive data during their active time slots. Furthermore, they
wake up at any time during the scheduled time slot to transmit data. In this
paper, we assume that during a working period, each sensor node $u$ is active
at random and independently at $\alpha$ time slots. The duty cycle is defined
as the ratio of active slots number $\alpha$ to the length of the working
period $T$, i.e., $\alpha/T$.

###  2.2 Problem formulation

In this paper, we study Minimum Latency Aggregation Scheduling (MLAS) problem
in multi-channel duty-cycled IoT sensor networks. The data aggregation
completes when sink node $s$ collects data from all sensor nodes in the
network. In other words, all nodes in the network except the sink must be
assigned channels and time slots when scheduling completes to transmit data
with interference-free. Data aggregation delay is the number of time slots
needed to aggregate data by the sink from all nodes in the network. The target
of MLAS is to reduce data aggregation delay while also ensuring that all
scheduled transmissions are interference-free.

##  3 Proposed data aggregation scheduling algorithms

The proposed data aggregation scheduling scheme is described in this section,
it is divided into two phases: Aggregation tree construction phase which
determines directional sender-receiver (child-parent) pairs for data
transmissions; and data scheduling phase which determines the time for sensor
nodes to transmit data without interference based on the constructed tree in
the first phase by allocating channels and assigning time slots to sensors. We
define a sleep delay metric is a time interval before a transmission between
sender $u$ and receiver $v$ at active slots $\tau_{u}$ and $\tau_{v}$ in a
working period length $T$ as follows:

$t(\tau_{u},\tau_{v},T)=\begin{cases}\tau_{v}-\tau_{u},&\text{if
}\tau_{v}>\tau_{u}\\\ \tau_{v}+T-\tau_{u},&\text{otherwise.}\end{cases}$ (1)

The sleep delay measures the time for node $u$ to wait until receiver $v$
active so that $u$ can transmit data to $v$. Node $u$ transmits data to $v$ in
the same working period when receiver $v$ is active at later active slot of
$u$ and $u$ must wait for a new working period to send data to receiver $v$ if
receiver $v$ is active before $u$. Intuitively, minimizing sleep delay between
sender $u$ and receiver $v$ also reduces sleep delay waiting for transmissions
of other nodes. As a result, the total latency will be reduced. Consequently,
we define minimal sleep delay between sender $u$ and receiver $v$ as follows:

$d(u,v,T)=\underset{\tau_{u}\in A(u)}{\mathrm{min}}\\{\underset{\tau_{v}\in
A(v)}{\mathrm{min}}\\{t(\tau_{u},\tau_{v},T)\\}\\},\\\ $ (2)

where we select the minimal sleep delay value between sender $u$ and receiver
$v$ after calculating the gaps between the active slots of the two nodes.

We present the minimal sleep delay data aggregation scheduling scheme in
Algorithm 1. As inputs, the communication graph $G(V,E)$ with sink node $s$,
working period length $T$, the set of available channels $F$ and communication
range $d$ are used. The output is all sensor nodes in the network are assigned
time slots and allocated channels with collision-free. The aggregation tree
construction phase is described from lines 1-8. Initially, sink node $s$ is
added into the node set $V_{T}$, the set of transmission links $E_{T}$ is
empty (lines 1-2). Based on the hop distance to the sink, the network is
divided into $R+1$ layers, i.e., ${L_{0},L_{1},…,L_{R}}$. It means that only
the sink is in layer $0$.

Input : $G(V,E)$, $T$, sink node $s\in V,F,d$

// $T$: Working period length

// $F$: Set of channels used for allocating the sensor nodes

// $d$: Communication range of the sensors

Output : All sensor nodes in the network are assigned channels and time slots

// Aggregation tree construction phase

1 $V_{T}\leftarrow\\{s\\}$

2 $E_{T}\leftarrow\emptyset$

3 Divide the network into $R+1$ layers based on their hop distance to the sink
$\\{L_{0},L_{1},...,L_{R}\\}$

4 for  _$i\in[1,R]$_ do

5 for  _$u\in L_{i}$_ do

6 $x\leftarrow\underset{v\in N(u)\cap
L_{i-1}}{\mathrm{argmin}}\\{t_{min}(u,v,T)\\}$

7 $p(u)\leftarrow x$

8 $E_{T}\leftarrow E_{T}\cup\\{(u,x)\\}$

9 $V_{T}\leftarrow V_{T}\cup\\{u\\}$

10

11

// Data scheduling phase

12 Starting time $t_{s}\leftarrow 0$

13 $V_{leaf}\leftarrow\\{u\in V_{T}\setminus\\{s\\}\mid C(u)=\emptyset\\}$

14 while  _$V_{leaf}\neq\emptyset$_ do

15 Apply DAS Algorithm [8] to aggregate the data from all the leaf nodes to
their parents in the tree;

16 Remove scheduled nodes from the tree;

17 Update $V_{leaf}\leftarrow\\{u\in V_{T}|C(u)=\emptyset\\}$

return All nodes in the networks are scheduled

Algorithm 1 Data aggregation schedule

The algorithm then starts in top-down manner, from layer $L_{1}$ to layer
$L_{R}$. At layer $L_{i}$, where $i\in[1,R]$ a node $u$ in the layer $u\in
L_{i}$ is considered to check the minimal sleep delay with its neighbor nodes
in the upper layer using Equation (1), i.e., $v\in L_{i-1}\cap N(u)$. The node
that forms the smallest value of minimal sleep delay with $u$ is selected to
be adopted as parent of $u$ (applying Equation (2)) and it is added into the
aggregation tree (lines 5-8). So on and so forth, the sensor nodes in each
layer are examined one by one. The process of the aggregation tree
construction completes when all sensor nodes except the sink in the network
adopt their parents.

In the data scheduling phase, scheduling time $t_{s}$ is initialized as $0$
(line 9). The algorithm obtains a set $V_{leaf}$ that includes all nodes
having no children in the tree (line 10). In other words, these are called
leaf nodes. This is an enhancement for candidate nodes selection compared to
the data aggregation scheduling scheme in [7] since that scheme only selects
leaf nodes layer by layer at each scheduling round. After that, we apply the
same procedure of data scheduling in [7]. The set of leaf nodes $V_{leaf}$ is
constantly updated at every scheduling round after valid nodes are scheduled.
We achieve the scheduling when all nodes in the network except the sink are
assigned channels and time slots (lines 11-14).

(a) Communication graph

(b) Network layering

(c) Aggregation tree construction process

(d) Complete aggregation tree

Figure 1: Example run for an aggregation tree construction process.

An example of data aggregation tree construction is illustrated in Fig. 1. A
sample communication graph consists of 9 sensor nodes ($S$ is the sink) is
presented in Fig.1(a). Each sensor node is active at two slots at random and
independently during a working period length $T=10$. Then, the network is
divided into layers based on the hop distance of sensors to the sink $S$ as
shown in Fig. 1(b). The aggregation tree is constructed in a top-down manner.
At layer $L_{1}$, nodes $A$, $B$, and $C$ have only one neighbor in layer
$L_{0}$, so that they adopt the sink S as their parent. Then they are added
into the tree. At layer $L_{2}$, the algorithm starts with node $D$. There are
two neighbors in upper layer, i.e., nodes $A$ and $B$ in layer $L_{1}$, node
$D$ takes $B$ as its parent since the minimal sleep delay between them is
smallest (Fig. 1(c)). The algorithm works in same the way for the rest of the
nodes in the network until all nodes adopt their parents, the completed tree
is obtained as shown in Fig. 1(d).

##  4 Experiment results

In this section, we conduct extensive simulations to examine the effectiveness
of our proposed schemes. We compare the performance of our proposed scheme,
sleep Delay Data Aggregation Scheduling – DDAS, in terms of data aggregation
latency, with an existing scheme [7] that proposes a time-efficient data
aggregation scheduling scheme, Novel Data Aggregation Scheduling scheme
(NDAS), in multichannel duty-cycled sensor networks. We also compare the
results to the SPT-DAS scheme, which builds the Shortest Path tree using
Dijkstra’s algorithm and employs the same scheduling scheme. To determine data
aggregation latency, we generate 100 sensor networks randomly for each
parameter variation. The data aggregation delay results in this section are an
average of the 100 network topologies. In a working period length $T$ ranging
from 10 to 70, sensor nodes are active in 1 to 7 slots. The sensor
communication range is $d=20m$. In a $100\times 100m^{2}$ area, the sensor
nodes number can range between 50 and 800. The available channels range from 2
to 7.

(a) Number of active slots

(b) Working period length

Figure 2: Aggregation delay affected by number of active slots and working
period length.

Affect by active slots. We run simulations to see how the number of active
slots affects the data aggregation latency. We deploy 200 sensor node networks
at random in the same size area. The number of active slots of each sensor
node varies from 1 to 7 in a working period length $T=20$. Figure 2(a) shows
how data aggregation delay decreases as the number of active slots increases
for all schemes. As the number of active slots at each sensor node increases,
so does the number of simultaneous transmissions in a single working period.
As a result, the overall aggregation delay is reduced. SPT-DAS appears to
perform worse when compared to NDAS. Meanwhile, when the number of time slots
is set to 2, the aggregation delay is reduced by up to 34% when compared to
DDAS.

Affect by working period. The number of nodes in each network is set to
$N=200$. Sensors operate in two slots over a working period length $T$ ranging
from 10 to 70. The overall data aggregation delay of DDAS, SPT-DAS, and NDAS
increases as the working period length increases, as shown in Fig. 2(b).
Because nodes are designed to sleep for extended periods of time while waiting
for their parents to become active in order to receive data from them. When we
increase the working period length by the same number of active slots, the
duty cycle is approximately 2.86-20%. When compared to NDAS, DDAS achieves at
most 41% lower data aggregation latency at $T=50$, 60, and 70 because more
nodes are scheduled at each scheduling iteration, resulting in more concurrent
data transmissions and less data aggregation latency.

(a) Number of nodes

(b) Number of channels

Figure 3: Aggregation delay affected by number of sensor nodes and number of
channels.

Affect by number of nodes. The effect of node number is depicted in Fig. 3(a),
where the number of nodes is increased from 50 to 800. In a working period
length $T=20$, sensor nodes are active at two slots. The three schemes’ data
aggregation delays increase as the number of nodes increases. Because as the
number of nodes increases, more nodes must send the data to their parents. As
a result, the data aggregation delay increases. At $N=50$, DDAS lowers data
aggregation latency by up to 62% when compared with NDAS. This enhancement is
also influenced by using an improved data scheduling and a different
aggregation tree construction approaches.

Affect by number of channels. The usage of different channels further avoids
interference while transmitting data between nodes. We deploy 200 sensor nodes
the same area, they are active at 2 slots in $T=20$. The number of channels is
changed from 2 to 7. When using from 2 to 4 channels, the aggregation delay of
all schemes reduce because more transmissions occurs simultaneously. However,
with more available channels, the latency remains the same because the network
is sparse, using more channels does not improve the performance. DDAS achieves
better aggregation delay compared with NDAS and SPT-DAS schemes, i.e., at most
39.94% and 33.83%, respectively.

##  5 Conclusion

We propose the sleep Delay Data Aggregation Scheduling scheme (DDAS) in this
paper, in which we use a new method of constructing the aggregation tree based
on sleep delay among sensors, and then schedule all leaf nodes in the
aggregation tree. The nodes that are scheduled, are then removed from the
aggregation tree. We show an example run for the tree-building process. In
addition, we conduct extensive experiments to evaluate the performance of DDAS
to that of a modern scheme in terms of data aggregation delay. When compared
to the start-of-the-art approach, our proposed scheme reduces data aggregation
delay by up to 61% depending on number of nodes, working period length, the
number of active slots, and number of channels. In the future, we apply a
break and joint approach to the current proposed scheme for further improving
the data aggregation delay, which aids in maximizing parallel interference-
free transmissions.

Acknowledgement. This work is partially supported by the Ministry of Science
and ICT, BK21 FOUR, GITRC (IITP-2022-2015-0-00742), ICT Creative Consilience
(IITP-2022-2020-0-01821), and Mid-career (NRF-2020R1A2C2008447).

## References

  * [1] Abbasian Dehkordi, Soroush, Kamran Farajzadeh, Javad Rezazadeh, Reza Farahbakhsh, Kumbesan Sandrasegaran, and Masih Abbasian Dehkordi, “A survey on data aggregation techniques in IoT sensor networks,” Wireless Networks 26, no. 2 (2020): 1243-1263.
  * [2] Wen, Yean-Fu, and Frank Yeong-Sung Lin, “Energy-efficient data aggregation routing and duty-cycle scheduling in cluster-based sensor networks,” In 2007 4th IEEE Consumer Communications and Networking Conference, pp. 95-99. IEEE, 2007.
  * [3] KhadirKumar, N., and A. Bharathi, “Real time energy efficient data aggregation and scheduling scheme for WSN using ATL,” Computer Communications 151 (2020): 202-207.
  * [4] Chen, Quan, Hong Gao, Zhipeng Cai, Lianglun Cheng, and Jianzhong Li, “Energy-collision aware data aggregation scheduling for energy harvesting sensor networks,” In IEEE INFOCOM 2018-IEEE Conference on Computer Communications, pp. 117-125. IEEE, 2018.
  * [5] Yu, Bo, and Jian-Zhong Li, “Minimum-time aggregation scheduling in duty-cycled wireless sensor networks,” Journal of Computer Science and Technology 26, no. 6 (2011): 962-970.
  * [6] Chen, Quan, Hong Gao, Zhipeng Cai, Lianglun Cheng, and Jianzhong Li, “Distributed low-latency data aggregation for duty-cycle wireless sensor networks,” IEEE/ACM Transactions on Networking 26, no. 5 (2018): 2347-2360.
  * [7] Jiao, Xianlong, Wei Lou, Songtao Guo, Libin Yang, Xinxi Feng, Xiaodong Wang, and Guirong Chen, “Delay efficient scheduling algorithms for data aggregation in multi-channel asynchronous duty-cycled WSNs,” IEEE Transactions on Communications 67, no. 9 (2019): 6179-6192.
  * [8] Shi, Yi, Y. Thomas Hou, Jia Liu, and Sastry Kompella, “How to correctly use the protocol interference model for multi-hop wireless networks,” In Proceedings of the tenth ACM international symposium on Mobile ad hoc networking and computing, pp. 239-248. 2009.
  * [9] Chen, Quan, Hong Gao, Siyao Cheng, Jianzhong Li, and Zhipeng Cai, “Distributed non-structure based data aggregation for duty-cycle wireless sensor networks,” In IEEE INFOCOM 2017-IEEE Conference on Computer Communications, pp. 1-9. IEEE, 2017.


# Mitigating Java Supply Chain Exploits with a Runtime Permission Model

Anonymous author(s)  Paschal C. Amusuo
Purdue University  Kyle A. Robinson
Purdue University  Santiago Torres-Arias
Purdue University  Laurent Simon
Google  James C. Davis
Purdue University

# Next-JSM: Preventing Java Supply Chain RCE Exploits via a Usable Package-
level Permission Manager

Anonymous author(s)  Paschal C. Amusuo
Purdue University  Kyle A. Robinson
Purdue University  Santiago Torres-Arias
Purdue University  Laurent Simon
Google  James C. Davis
Purdue University

# Next-JSM: Preventing the next Log4Shell in Java with a Supply-chain Aware
Permission Manager

Anonymous author(s)  Paschal C. Amusuo
Purdue University  Kyle A. Robinson
Purdue University  Santiago Torres-Arias
Purdue University  Laurent Simon
Google  James C. Davis
Purdue University

# Preventing Supply Chain Vulnerabilities in Java with a Fine-Grained
Permission Manager

Anonymous author(s)  Paschal C. Amusuo
Purdue University  Kyle A. Robinson
Purdue University  Santiago Torres-Arias
Purdue University  Laurent Simon
Google  James C. Davis
Purdue University

### Abstract

Integrating third-party packages accelerates modern software engineering, but
introduces the risk of software supply chain vulnerabilities. Vulnerabilities
in applications’ dependencies are being exploited worldwide. Often, these
exploits leverage features that are present in a package, yet unneeded by an
application. Unfortunately, the current generation of permission managers,
such as SELinux, Docker containers, and the Java Security Manager, are too
coarse-grained to usefully support engineers and operators in mitigating these
vulnerabilities. Current approaches offer permissions only at the
application’s granularity, lumping legitimate operations made by safe packages
with illegitimate operations made by exploited packages. This strategy does
not reflect modern engineering practice — we need a permission manager capable
of distinguishing between actions taken by different packages in an
application’s supply chain.

In this paper, we describe Next-JSM, the first fine-grained (“supply chain
aware”) permission manager for Java applications. Next-JSM supports permission
management at package-level granularity. Next-JSM faces three key challenges:
operating on existing JVMs and without access to application or package source
code, minimizing performance overhead in applications with many packages, and
helping operators manage finer-grained permissions. We show that these
challenges can be addressed through bytecode rewriting; appropriate data
structures and algorithms; and an expressive permission notation plus
automated tooling to establish default permission. In our evaluation, we
report that Next-JSM mitigates 11 of the 12 package vulnerabilities we
evaluated and incurs an average 2.72% overhead on the Dacapobench benchmark.
Qualitatively, we argue that Next-JSM addresses the shortcomings of the
(recently deprecated) Java Security Manager (JSM).

##  1 Introduction

The Software Supply Chain in Java has become a devastating vector for Remote
Code Execution (RCE) and other critical vulnerabilities [17]. These supply
chain vulnerabilities give malicious actors access to alter a program’s
execution, execute shell scripts, or exfiltrate sensitive files [17, 31, 53,
16]. Within the last 2 years, critical vulnerabilities in popular Java
packages such as Log4J, Spring, and Apache commons-text have exposed millions
of Java applications to malicious exploits [41, 45, 28]. We need systems that
enable engineers and operators to protect their applications from
vulnerabilities in their software supply chains.

Software supply chain vulnerabilities cannot easily be mitigated by the
current generation of permission managers. This class of software, embodied in
access control systems [50, 26, 52, 39] and sandboxes [14, 35, 49, 30, 23], is
a popular approach for mitigating the impact of application vulnerabilities.
However, existing systems for Java applications enforce permissions at an
inappropriate granularity, e.g., at the granularity of an application [7] or a
Docker container [13]. They are unable to enforce the Principle of Least
Privilege within an application’s dependencies, which is required to prevent
supply chain vulnerability exploitation.

We posit that the insufficiency of existing permission managers is due to
their design at a wrong granular level (the application level). We believe a
fine-grained (“supply-chain-aware”) permission manager, i.e.,, with
permissions at the granularity of packages, is necessary to protect modern
applications. A permission manager at the package granularity should improve
an application’s security by enforcing the least privilege principle on the
application’s supply-chain components (dependencies). This goal introduces
three challenges: (C1:) It needs to operate on existing JVM and function
without access to the source code of Java applications or their dependencies;
(C2:) It needs to minimize performance overhead in applications with many
dependencies; and (C3:) It needs to help operators identify and manage these
finer-grained permissions.

We propose Next-JSM, the first supply-chain-aware permission manager for Java
applications. Next-JSM allows specifying permissions that are scoped to
specific dependencies in an application. It features an extendable bytecode
rewriting engine that intercepts classes within the JDK and instruments their
security-sensitive methods to monitor API usage and enforce the specified
permissions (C1). Next-JSM uses appropriate data structures and algorithms to
facilitate efficient retrieval of a package’s permissions in constant time
with respect to the number of packages (C2). For permission management, Next-
JSM supports tracing to determine the default minimum permissions of an
application as well as an expressive permission notation (C3).

We evaluated Next-JSM in several ways. Next-JSM can prevent many real-world
supply chain vulnerability exploits (11/12 protected). Next-JSM incurs
substantial performance overhead on microbenchmarks, but low performance
overhead on the Dacapobench (average 2.72% overhead). Next-JSM achieves
constant-time overhead regardless of the number of packages being monitored.
Using Next-JSM’s capability tracing system, we show that several real
applications use packages that can make use of more security-sensitive
operations than the applications need — our expressive permission language
allows application engineers to deny those behaviors in their context. We
compared Next-JSM to the nearest related tool, the Java Security Manager
(JSM), and report greater usability along the dimensions for which JSM was
deprecated in 2021.

In summary, our main contributions are:

  * •

We designed Next-JSM, the first software supply chain-aware permission manager
for Java. Next-JSM offers permissions on a dependency basis rather than an
application basis, and addresses usability flaws of the deprecated JSM.

  * •

We demonstrated Next-JSM’s defense capabilities on a collection of real-world
supply chain vulnerabilities in Java packages and evaluated its performance
overheads.

##  2 Background

In this section, we review the general concept of software supply chain
vulnerabilities (section 2.1) and the specific case of the Log4J/Log4Shell
vulnerability (section 2.2).

###  2.1 Software supply chain vulnerabilities

The software supply chain involves a collection of resources (hardware and
software), storage, and distribution mechanisms that contribute to the
development of a final software product [12]. From an application’s
perspective, its supply chain is the set of software packages included as
dependencies and the various channels through which it obtains its
dependencies [40].

In modern commercial software development, supply chains are the norm. Large
portions of a typical software project are implemented by combining third-
party components. For example, in 2023 Synopsis analyzed 1703 commercial
software projects across 17 sectors of industry [47]. They reported that 96%
of the surveyed projects contained third-party (open-source) software, with an
average of 595 open-source components imported as dependencies per project.
Similarly, Kumar et al. reported that over 90% of the top one million Alexa-
ranked websites rely on external dependencies [33]. Modern software projects
depend, directly or indirectly, on hundreds or thousands of distinct packages
developed and maintained by different engineers.

Beyond the risk posed by vulnerable dependencies, these vulnerable
dependencies persist in the supply chain long after patches are available.
This increases the exposure timeline of the affected applications. For
example, in 2023 Synopsis reported that, despite the publicity received by the
Log4J vulnerability, 11% of the Java codebases they scanned contained
vulnerable versions of Log4J one year after the patch was available [47].
Corroborating this finding, Zhang et al. [54] measured patch lag across Java’s
Maven ecosystem. In the case of Log4J, they found it took 308 days for 50% of
Log4J dependents to get patched, and after 15 months of exposure, newly
affected Log4J dependents were still being published, with 94% importing
gLog4J transitively. Similar behaviors were reported across other vulnerable
Maven packages. They attributed this cause of persistent vulnerabilities to
the failure of direct dependents to either update or release patched versions
of their packages. Given the risks of vulnerable dependencies and the
challenge of vulnerability patch propagation, our work is directly in line
with industry experts’ call for “zero trust” for software dependencies [25].

###  2.2 Overreach in Dependency Behavior: The Case of Log4Shell

Our thesis is that many software supply chain vulnerabilities result from a
gap between the integrator’s expectation of a package’s behavior, and the
package’s potential behavior. We term this phenomenon dependency behavioral
overreach. Here we illustrate it through the Log4J vulnerability, based on the
analysis conducted by the US CISA [18].

The Log4J vulnerability, CVE-2021-44228, was published in 2021. Nicknamed
Log4Shell, the vulnerability occurred in the popular Log4J logging library. It
allowed remote code execution, enabling malicious actors to take control of
affected systems. The severity of the vulnerability was compounded by its
ubiquity — Log4J was used, directly or indirectly, by thousands of other
packages and millions of applications worldwide.

The Log4J vulnerability was caused by Log4J’s support for the JNDI lookup
functionality while logging externally-supplied data. JNDI allows a Java
application to interact with and retrieve data from an LDAP server. Given an
attacker-controlled LDAP or RMI server, JNDI has the capability to execute
malicious code returned by the LDAP server. The Log4J library is usually used
for logging attacker-controlled data, such as components of an HTTP request
header or usernames of an application’s users. Hence, if such data contains a
JNDI URL, the Log4J library accesses the URL and can execute any code returned
by the library.

Our key observation about the Log4J vulnerability is that many users did not
need the JNDI functionality — and the corresponding code execution behavior —
in their logging library. Such functionality could be disabled without adverse
effect on the application’s functionality. However, preventing the application
from issuing any network accesses would be too aggressive, since other
components of the application might rely on the network. Unfortunately,
existing permission managers for Java do not permit application engineers and
operators to distinguish permissions at the package level of granularity. We
discuss this and related work next.

##  3 Related Works

###  3.1 Sandboxing and Permission Managers

Sandboxing, Process Isolation, Permission Managers, and Access Control Systems
is a well-studied area that has contributed to the security of operating
systems, web and mobile systems, programming languages, and other software
systems. Figure 1 summarizes different types of permission managers based on
their targets.

Figure 1:  Selected Permissions Managers at the operating systems,
applications, and package granularity. The red bars with question marks
demonstrate the gap this project fills. While Javascript has techniques
combating supply-chain vulnerabilities, there are no corresponding techniques
in Java.

Operating Systems-level isolation and access control techniques restrict an
application’s access to the file system and system call access in the
operating system. SELinux [8] and AppArmor [1] involves using policy files to
define what resources an application should access. Containers such as Docker
[13] build on these OS-level mechanisms to offer similar guarantees. These
approaches do not have insight into application internals, limiting the
enforcement of the least privilege principle on the dependencies.

Several other sandboxing mechanisms create an isolation layer between the
application and third-party code. The Firefox renderer [37] uses RLBox to
isolate third-party libraries to render audio, video, images, and other
content. NativeGuard [46] isolates native libraries of Android applications
into a second application where unnecessary privileges are eliminated. Gama et
al. [27] proposed a self-healing sandbox for executing third-party code.
Cage4Deno [14] and Sandcrust [35] isolate the execution of subprocesses and
untrusted C programs within the Deno and Rust runtime respectively. These
techniques are all designed for C/C++ codes and are tailored to protect the
application from C/C++-related vulnerabilities such as crashes and memory
corruptions.

More recently, intra-process isolation techniques have been applied to
non-C/C++ codes. BreakApp [49] decomposes a Javascript app and runs each
library in its own sandbox, following defined policies. This is conceptually
related to Next-JSM, but differs substantially in detail. Another family of
approaches for JavaScript prevent the introduction of new functionality at
runtime [50, 26, 39], but are inappropriate when an exploit depends on
functionality built into the application. Next-JSM’s dynamic analysis approach
allows it to support finer-grained permissions and is tailored to use cases
where there is a legitimate but unused functionality in a Java package that
can be exploited.

For Java applications, the Java Development Kit (JDK) provides the Java
Security Manager (JSM) to restrict the access of Java applications to
sensitive lower-level APIs. Like other application-level sandboxing
techniques, the JSM’s design makes it unsuitable to enforce the least
privilege principle on an application’s dependencies or protect it from its
supply chain vulnerabilities. Unfortunately, this JSM was recently deprecated
due to its lack of use and insufficiency in protecting against relevant
vulnerabilities. We compare our approach qualitatively to JSM in section 6.3.

###  3.2 Automated Policy Generation

Once a permission model is established, a policy must be developed and
maintained for an application. Various automated approaches have been proposed
for generating policies for sandboxes. The Linux Systrace functionality
monitors system call executions and generates a policy based on the observed
system call invocations. Wan et al. [51], Jamrozik et al. [32], Pailoor et
al., and Bapan et al. [15] applied similar methods to monitor system calls and
generate policies for various other software systems such as Android
applications and containers. Monitoring processes at the system call level is
effective for generating policies for operating systems-level sandboxing
approaches. However, information about the application’s third-party
dependencies is unavailable at the operating system or application level
(“semantic gap”). Hence, the available automated policy generation approaches
are insufficient for generating policies for a supply-chain-aware permission
manager.

To automatically generate policies for intra-application sandboxing, MIR [50],
Ferreira et al. [26] and Ohm et al. [39] employ static analysis to identify
usage of sensitive APIs by the individual packages. Such techniques are
unsuitable for Java, where third-party dependencies’ source code is
unavailable. Our work proposes instead a runtime policy generation approach to
specify the capabilities that Java dependencies exhibit in the context of the
application.

###  3.3 Other Supply Chain Security Approaches

Beyond privilege reduction, many other approaches have been proposed to reduce
the risk from vulnerable or malicious components of the software supply chain
[40]. As discussed by Okafor et al. [40], these works focus on promoting
transparency [11, 10, 4, 6], validity [38, 48, 34, 29], and separation [24,
20] within the supply chain. These techniques reduce the risk of introducting
malicious or vulnerable dependencies. However, they cannot protect the
application from zero-day vulnerabilities in their current packages. By
enforcing a least-privilege principle on dependencies, Next-JSM helps
application engineers mitigate their zero-day risk.

##  4 Motivation and Threat Model

###  4.1 Vulnerabilities in the Java Ecosystem

We assessed the prevalence of supply chain vulnerabilities by vulnerability
growth trend within the last 20 years. Figure 2 shows a graph of CVEs
disclosed against Maven packages, based on CVE publication year. We observe a
jump of vulnerabilities in the Java supply chain within the last 4 years. The
actual risk faced by applications is greater still, as many vulnerabilities
are not disclosed as CVEs [36, 44, 12].

Figure 2:  Annual CVEs in Maven packages, until Aug. 2023.

###  4.2 System and Threat Model

Our system model is that an application depends on a vulnerable package,
either directly or transitively. User-supplied data from the application is
input to the vulnerable package. The vulnerable package has the built-in
capability to perform some security-sensitive operation(s) on the host system,
such as accessing the local file system, connecting to a remote server, or
executing executable files, shell commands, or arbitrary functions located in
the classpath. The package can either perform such action directly (such as
invoking the responsible APIs to execute the action) or indirectly (e.g.,
calling another package to do so). The input received by the vulnerable
package from the application is able to influence the conduct of any of these
sensitive operations.

Given this system model, our threat model is that a malicious actor can
interact with the application and control the data passed to the vulnerable
package.

This model is realistic, occurring regularly when applications depend on
third-party packages. For example, in the Log4J case, applications either
depend on Log4J for logging or on a packages that uses Log4J. Log4J, through
its use of the JNDI APIs, can connect to a remote server and instantiate
arbitrary classes returned by the server. The server URL it connects to can be
controlled by the log message the application sends to it. Applications
commonly log externally supplied data, such as HTTP header fields and form
entries. Hence, given all these properties, The Log4J vulnerability represents
a threat vector that can be mitigated by Next-JSM. However, this threat model
does not consider native libraries written in lower-level languages, such as
C/C++, which a package may use directly to perform sensitive operations. This
is not a conventional programming practice in Java, as the Java Development
Kit provides a vast set of APIs for interacting with operating system
resources. Furthermore, this threat model doesn’t include threats posed by
intentionally malicious packages. As discussed in section 3, the software
supply chain community has proposed many approaches for preventing the
introduction of malicious packages to the supply chain.

Next-JSM shares a similar threat model with other analogous works designed for
the Javascript ecosystem [49, 50]. It assumes vulnerable packages in the
application’s dependencies and the package’s capability to perform security-
sensitive operations. However, the granularity of protection it provides to
the application is a significant difference. BreakApp [49] and MIR [50] block
access to specific Javascript APIs and do not consider the arguments of these
APIs. Hence, if a package has access to read a single file, it gets access to
read all files. Next-JSM provides a fine-grained granularity such that it can
still protect access to specific files even when the package has access to
some other files.

##  5 Next-JSM: Design and Implementation

###  5.1 Design Requirements

In addition to supply chain vulnerability protection, a supply-chain-aware
permission manager should also be usable. Here, we identify and discuss four
vulnerability protection and usability requirements that such a permission
manager should meet. While the first three requirements address challenges and
concerns introduced by a finer-grained supply-chain-aware Permission Manager,
the last two requirements directly address the reported usability flaws [43]
of the deprecated Java Security Manager.

  1. 1.

Stable and Acceptable Performance Overhead (section 6.2): A Supply-chain-aware
permission manager should introduce only an acceptable worse-case impact on an
application’s latency and throughput. Such an impact should be stable relative
to the number of packages in the application.

  2. 2.

Package Capability Inference (section 5.3): A Supply-chain-aware permission
manager should be able to infer a package’s capabilities and help the
application maintainer understand the consequence of restricting a specific
package’s permissions.

  3. 3.

Non-fatal Enforcement Option (section 5.4.3): A Supply-chain-aware permission
manager should provide a safe (non-fatal) enforcement option to ensure
application availability. In such a mode, access violations are reported to
the application maintainer without interrupting the application’s execution.

  4. 4.

Easy Programming Model (section 5.2.2): To mitigate the _difficult programming
model_ flaw of the JSM, a supply-chain-aware Permission Model should not
require the explicit specification of permissions for all packages in an
application in order to guarantee a successful application runtime.

  5. 5.

Flexible Permission Model (section 5.2.3): To mitigate the _Brittle Permission
Model_ flaw of the JSM and ensure usability, A supply-chain-aware permission
model should support partial security and negative permissions. An application
maintainer should be able to enforce only the set of permissions he deems
necessary. They should also have the option to grant permissions for all but
specifically unwanted operations.

Next we discuss relevant aspects of our design.

Figure 3:  Overview of the design of Next-JSM, a supply-chain-aware
Permissions Manager for Java. It comprises two components. The Capability
Tracing component monitors an instrumented application’s usage of sensitive
APIs and generates a Capabilities Specification (CS) file. The CS File aids
the specification of a permissions file. The Permissions Enforcement component
uses the Permissions file to authorize access to sensitive operating systems
resources.

###  5.2 A Supply Chain Aware Permission Model

Next-JSM aims to protect applications from the exploitation of vulnerabilities
in the packages they depend on. At its core is a permission model expressing
the permissions that should be granted to each package in the application. The
model comprises specific properties that simplify its specification and
improve its usability.

####  5.2.1 Components of the Permission Model

Following the Access Matrix terms defined by Sandhu et al. [42], Next-JSM’s
permission model comprises four components that enable it to clearly specify a
package’s permissions - Permission Subject, Resource Types, Resource
Operations, and Resource Objects. Hence, each permission consists of a
subject-operation-object tuple, while the resource types define the properties
of the objects and specify the set of operations allowed on them. The
relationship between these components is shown in the abstract permission
model section of Figure 3.

##### Permission Subjects:

Permission Subjects refer to the packages that an application depends on. In
Java, the names of classes are prefixed by the name of the packages they
belong to. For example, Log4J’s Logger class handles logging and has its fully
qualified name as _org.apache.logging.log4j.Logger_. The package name is
_org.apache.logging.log4j_ , and the class name is _Logger_.

##### Resource Types:

Resource Types refer to the different kinds of operating systems resources
that an application or package can access. They also determine the set of
permissions that can be enforced by Next-JSM. Next-JSM currently supports 3
types of resources: File System, Network, and Runtime. These resource types
are _configurable_ , allowing an application maintainer to enforce only the
set of permissions he considers necessary. They are also _extendable_ as Next-
JSM can be extended to support and enforce new permissions.

##### Resource Objects:

These are the individual items the subject aims to access. They include files
or directories, Network URLS, or shell commands.

##### Resource Operations:

This refers to the various actions that can be performed on the individual
resource types.

####  5.2.2 A Context-sensitive Permission Model

Figure 4:  Permission verification operation. Permissions are checked for all
classes in the stacktrace. Authorization requires $\geq$1 class be permitted
and no class be restricted.  ⬇ \parfun checkPermission(resourceType,
resourceObject,  operation):  \parpackagePerms = {}  hasPermEnabled = False
hasPermRestricted =False \parcallStack = getCallStack()  \parfor class in
callStack:  packageName, perms = getPackagePermissions(class)
packagePerms[packageName] = perms \parfor packagePerm in packagePerms:
hasPerm = packagePerm.contains (resourceType, resourceObject, operation)  if
(hasPerm == 0)  hasPermEnabled = True else if (hasPerm == 1)
hasPermRestricted = True \parif hasPermEnabled and not hasPermRestricted
return True \parreturn False \par\par

Next-JSM exhibits a context-sensitive permission model. This means that a
package’s access to a specific resource depends on its set of permissions and
the permissions of its callers. This is achieved through two properties of
Next-JSM’s permission verification process, as demonstrated in Figure 4.

##### Callstack-based Permission Verification:

Next-JSM’s permission model requires that all packages involved in an attempt
to perform an operation on a controlled resource must have the appropriate
permissions to perform the operation on the specific resource object. Hence,
as shown in the permission verification algorithm, Next-JSM walks the stack at
the point of invocation, performs verification checks on each class’s package,
and denies the permission request if any package fails the verification.

##### Package Permission Inheritance:

To prevent the need to grant explicit subject-operation-object permission
tuple to each package, Next-JSM’s permission model supports permission
inheritance. The permissions defined for a package are inherited by all
transitive dependencies used by the package, except the transitive dependency
has its own overriding set of permissions defined. Hence, as shown in Figure
3, P3 is able to access the specific file when invoked by P1, even though it
has no explicit file permissions. On the other hand, the operation is denied
when P2 invokes P3.

Permission Inheritance may have the unwanted consequence of enabling a
confused deputy attack, where a vulnerable package uses an authorized package
to access a sensitive resource. However, it is still necessary to enable
Permission Inheritance as the set of transitive dependencies, which will
require permission specification, exponentially grows. To mitigate the risk of
confused deputy attacks, Next-JSM Permission Inheritance property can be
configurable.

####  5.2.3 Permission Specification

Next-JSM’s permission model supports the use of a reader-friendly format for
specifying permissions. Figure 5 shows a sample permissions file with
permissions specified for a single package. The provided format supports 3
levels of permissions specification, with varying granularity.

Figure 5:  Permission Specification file. It supports three levels of
permission granularity - resource type level (e.g.,’fs’), resource operation
level (e.g.,’fs.read’) and resource object level (e.g.,’fs.allowedPath)  ⬇
\par{  "com.foo.baz": {  "fs": false,  "fs.read": true,  "fs.write": false,
"fs.allowedPaths": [],  "fs.deniedPaths": [],  "net": false,  "net.connect":
false,  "net.accept": false,  "net.allowedUrls": [],  "net.deniedUrls": [],
"runtime": false,  "runtime.exec": false,  "runtime.allowedCommands":
["whoami"],  "runtime.deniedCommands": []  },  …  }  \par\par

  * •

Resource-type level: A package can be granted total access or total
restriction to a specific resource type. In Figure 5, package _com.foo.baz_
has no access to the network system.

  * •

Resource-operation level: A package is granted access to perform specific
operations on a resource type. In Figure 5, package _com.foo.baz_ can read
files but can not write to any file.

  * •

Resource-object level: In the most fine-grained level, the specific items a
package can or cannot access are specified. This enables the use of both
positive and negative permissions, as defined by Sandhu et al. [42]. In Figure
5, package _com.foo.baz_ can only execute the _whoami_ command at runtime.

###  5.3 Capability Tracing

Next-JSM’s capability tracing component is designed to aid system
administrators and security personnel in the specification of appropriate
permissions to protect their applications. The output of capability tracing is
a Capability Specification file. This file contains the specific resource
objects accessed by each package and the operations carried out on the item.
The file can either be used as a permissions file for permissions enforcement
or can be used as a source of data to understand consequences and guide
decision-making on permission restriction. The Capability Tracing operation
comprises three stages.

##### Monitoring:

Capability Tracing uses the instrumentation hooks attacked by Next-JSM on
controlled APIs to monitor these APIs’ usage and corresponding capabilities.
It collects information about the resource object being accessed and the
packages in the stack trace at the point of invocation. This data is first
stored in an in-memory buffer to optimize performance and routinely written to
a file for long-term storage.

##### Merging:

Next-JSM’s Capability Tracing component maintains a single and simple
representation of an application’s recorded capabilities by merging each new
recording with the existing capability specification file. This stage is
triggered immediately after the API usage recording is written to a file. It
takes the new API usage recording and the existing capability specification
file, and for each package in the new API usage recording, it updates the
package’s capabilities in the Capability Specification File.

##### Minimization:

To support long-term capability tracing and avoid excessive usage of disk for
storing the capability specification document, Next-JSM’s Capability Tracing
component features an optional minimization stage that performs file path
reduction on the various file and directory paths in the Capability
Specification file. When enabled, if a package accessed up to _k_ files from
the same directory, this stage replaces these files with the directory path in
the capabilities specification file. This aims to reduce the size of the
capabilities specification file when there are packages making frequent and
unique file accesses in the application.

###  5.4 Permission Enforcement

Next-JSM is designed to enforce the set of permissions specified for each
package in an application. Similar to other permission managers, Next-JSM
intercepts access to instrumented methods and uses a security monitor to
verify if access is permitted. For each resource type, we refer to the class
in the core JDK library that provides access to the protected resource as a
security-sensitive class. We refer to the APIs in the specific classes the
package interacts with as instrumented methods due to the presence of
instrumentation. Table 1 shows the instrumented classes and methods for each
resource type and operation pair.

Table 1:  Sensitive classes and instrumented methods used to enforce different permissions.  Operation |  Sensitive Class |  Instrumented Method
---|---|---
File Read |  FileInputStream |  <Constructor>
File Write |  FileOutputStream |  <Constructor>
Network Connect |  Socket |  connect()
Runtime Execution |  ProcessBuilder |  start()

Next-JSM permission enforcement approach is in three phases.

_Bytecode Transformation:_ At an application’s startup, Next-JSM intercepts
security-sensitive classes as they are being loaded into the JVM and uses its
bytecode rewriting engine to instrument the methods performing sensitive
operations with calls to its permission verification component.

_Permission Context Generation:_ Also, at startup, it reads the provided
permissions specification file and builds a permissions context for the
application comprising the packages and the set of permissions they own.

_Permission Verification:_ At runtime, during the invocation of any
instrumented method, Next-JSM performs the verification of permissions
following the algorithm described in Figure 4.

####  5.4.1 The Bytecode Rewriting Engine

Next-JSM instruments the sensitive methods using its Bytecode Rewriting Engine
(BRE). The BRE is designed to be configurable and extendable and comprises the
following stages.

##### Setup and Configuration:

The set of permissions enforced by Next-JSM is designed to be configurable. An
application maintainer may choose to enforce only the Runtime execution
permission while delegating the file and network access permissions to other
complementary permission managers at the operating systems level. As a result,
Next-JSM configures the BRE to instrument only the classes and methods related
to the configured set of enforced permissions. To configure, BRE requires the
name of the Class and method to instrument, as well as some details about the
properties of the class that will aid its instrumentation.

##### Interception of Security-Sensitive Classes:

The BRE intercepts classes as they are loaded into the JVM and checks if the
intercepted class is a security-sensitive class It passes the bytecodes of
security-sensitive classes to the bytecode transformer subcomponent for
instrumentation. The instrumented bytecode is then loaded into the JVM in
place of the original bytecodes.

##### Bytecode Transformation

For each security-sensitive class, the BRE identifies the set of configured
methods in the class. For each method, it locates the position of the method
argument representing the resource object using the information provided at
the configuration stage. Finally, it adds a sequence of bytecodes representing
an invocation of the Permission verification component at the top of the
method. It passes the located method argument as an argument to the permission
verification component, together with arguments specifying the resource type
and resource operation.

####  5.4.2 The Permissions Context

Given a Permission Specification document containing the set of permissions
specified for each package, we create a permissions context that aids the
efficient retrieval of a package’s permission during the permissions
verification stage. This is necessary as a packaged Java application does not
contain mapping information between the classes in its dependencies and the
packages they belong to. Instead, as discussed in section 5.2.1, the names of
classes in the bytecode are prefixed by their package names. As shown in
Figure 6, we store each package’s permission at the leaf node of a modified
trie data structure, where each node on the path to that leaf node represents
a dot-separated component of the package’s name.

Figure 6:  Illustration of permission context, indicating how package
permission sets are stored for efficient retrieval.

During permission verification, we attempt to retrieve the set of permissions
for each class on the stack trace. We use the dot-separated components of the
class name to search for the permission set defined for the class’s package.
Due to our use of the modified trie data structure, the search time complexity
for package set of permissions is constant with respect to the number of
packages used by the application. This is because the permission verification
operation does not need to iterate through the list of packages in the
application to map a package to a class name or to search for the package’s
set of permissions. In Figure 6, the permission set for the class
_com.foo.bar.ClassA_ in the _com.foo.bar_ package can be retrieved in at most
3 steps - searching for com, foo, and baz through the tree and, if they are
all present, retrieving the permission set saved at baz. It is linear on the
number of dot-separated components in the class name. In our threat model
(section 4.2), the attacker sends a malicious payload that exploits an
existing package and so does not control static properties such as the class
name.

####  5.4.3 Permission Verification and Enforcement

Permission verification and enforcement occur when an instrumented method is
invoked. The instrumentation invokes the Permissions Verification component,
using the name of the resource being accessed and the intended resource
operations as arguments. The Permissions Verification component is implemented
following the algorithm described in Figure 4. It verified that every class in
the stack trace is from a package that has the required permission to perform
the intended operation. If any class’s package lacks the necessary permission,
the violation is flagged, and the access is denied.

To limit the disruption of an access denial to an application’s execution, the
enforcement component provides two configurable modes. In the block mode, the
enforcement component is designed to throw an exception that the calling
package is expected to have handled. In Java, programs attempting to interact
with the operating system are forced to catch and handle specific exceptions
that the operation may throw. Next-JSM’s enforcement component is designed to
throw one of these safe exceptions during an access violation. In the report
mode, the enforcement component does not interfere with the application’s
execution and, instead, invokes a callback that the application would have
configured.

####  5.4.4 Implementation

Next-JSM is implemented as a Java agent [3] with 2,284 lines of Java code. It
is supplied as a command-line argument when running the Java application. As a
result, Next-JSM does not require a modification of the application or the
Java Virtual Machine, which ensures its portability and usability. Next-JSM’s
arguments determine the capability tracing or permissions enforcement choice.

We use Java’s instrumentation API to intercept and transform security-
sensitive classes as they are being loaded into the JVM. We implemented the
Bytecode Rewriting Engine using the ASM library. Compared to other bytecode
transformation libraries like Javassist and ByteBuddy, ASM provided us the
flexibility that Next-JSM required. Finally, our instrumentation in the core
JDK classes uses the reflections API to invoke the permissions verification
method, as the core JDK classes can not directly invoke application methods.

##  6 RPM: Evaluation

Using the following research questions, we evaluate Next-JSM’s utility,
effectiveness, and performance.

  * RQ1

Does Next-JSM prevent real-world Java RCE exploits?

  * RQ2

How does Next-JSM impact an application’s performance?

  * RQ3

Does Next-JSM address the shortcomings of the Java Security Manager?

###  6.1 RQ1: Protection against Supply Chain Vulnerabilities

We evaluate Next-JSM’s effectiveness in mitigating the exploitation of RCE
vulnerabilities in Java packages.

####  6.1.1 Methodology

We evaluated Next-JSM’s capability to protect applications from supply chain
vulnerabilities using a sample of 12 vulnerabilities selected from the supply
chain vulnerabilities analyzed in section 4.1. We first sorted the
vulnerabilities according to their year of publication and severity score
(CVSSv3). Starting from the top, we selected the first 12 vulnerabilities for
which we could find publicly available exploits on GitHub. We believe this
sample represents the characteristics of vulnerabilities that are recent, have
critically severe consequences, and are easily exploitable. We built a sample
application for each selected vulnerability that uses the vulnerable
dependency. We first exploited each application by executing the available
exploits. Then, we tried performing the same exploits while running the
application with Next-JSM.

####  6.1.2 Results

Table 2:  Summary of Next-JSM’s performance in mitigating supply chain vulnerability exploits. It prevented the execution of sensitive Java APIs during each failed exploitation attempt. It mitigated exploits of 11/12 critical and recent vulnerabilities.  CVE ID |  Vulnerable Package | Severity |  Exploit Medium |  Capabilities Required | Exploit Mitigated
---|---|---|---|---|---
CVE-2023-38889 |  Alluxio | 9.8 |  Bash command |  Shell Execution | ×
CVE-2022-23221 |  H2 Console | 9.8 |  SQL Init Script |  Network Access & Shell Execution | ✓
CVE-2023-39021 |  Wix-embedded-mysql | 9.8 |  Executable file |  Shell Execution | ✓
CVE-2023-26119 |  HtmlUnit | 9.8 |  XML file |  Shell Execution | ✓
CVE-2023-39020 |  Stanford Parser | 9.8 |  Executable File |  Shell Execution | ✓
CVE-2022-33980 |  Apache Commons-Configuration | 9.8 |  Java code |  Code Execution | ✓
CVE-2022-22963 |  Spring Core | 9.8 |  Http Request data field |  Code Execution | ✓
CVE-2022-22963 |  Spring Cloud | 9.8 |  Http Header containing Java code |  Code Execution | ✓
CVE-2022-25914 |  Jib-core | 9.8 |  Executable file |  Shell Execution | ✓
CVE-2022-36944 |  Scala-library | 9.8 |  Serialized byte stream |  File Write | ✓
CVE-2022-42889 |  Apache Commons-text | 9.8 |  Java code |  Code Execution | ✓
CVE-2021-44228 |  Log4J | 10.0 |  LDAP URL providing Java class file |  Network Access & Code Execution | ✓

Table 2 shows the results of our exploitation of the selected vulnerabilities.
The fourth column indicates the channel through which a malicious code can be
delivered to the application, the fifth column indicates the capabilities
required for the exploit to succeed, and the last column shows if an exploit
was successfully mitigated by Next-JSM.

As shown in the table, these vulnerabilities provide attackers with code
execution, either through the execution of shell commands, executable files,
or Java code, network access, and file write capabilities. Next-JSM is
designed to prevent these exploitations by controlling access to the APIs the
attacker will depend on.

Our results show that Next-JSM can effectively block the execution of 11/12
exploits. We are unable to prevent the exploitation of CVE-2023-38889. The
package inherently requires the capability to execute the _bash_ command with
externally provided arguments. The exploit involves a code injection attack
where a malicious shell command is inserted into the expected _bash_ command
as an argument. Next-JSM does not process the contents of the bash command
being executed and does not detect the presence of the injected malicious bash
command.

###  6.2 RQ2: Next-JSM Performance Overheads

We report the performance cost of Next-JSM on various microbenchmarks and
profiling measurements.

####  6.2.1 Performance — Methodology

Cost by operation: We measured the cost of each security-sensitive operation
with and without Next-JSM’s instrumentation. We used the Java
Microbenchmarking Harness (JMH) library [5], a popular microbenchmarking
library developed and maintained by OpenJDK to address many microbenchmarking
pitfalls [22].

Predicted performance trends: We measured the performance impact when
increasing the number of packages in the class (expected: constant) and the
depth of the call stack during method invocation (expected: linear).

Real applications: To investigate the impact of our permission model on a real
application, we conducted profiling measurements on the applications in the
Dacapobench suite. For each application, we measured the load time and runtime
overhead introduced. We ran each application 10 times and returned the average
measurement.

Table 3:  Microbenchmark of security-sensitive operations. Uncertainty is reported over 5 warmup runs, 5 measurement runs, and 3 forks, with each run executing for 10 seconds and the average execution time returned.  Operation |  Without Next-JSM (us) |  With Next-JSM (us)
---|---|---
File Read |  $7.66\pm 0.07$ |  $24.15\pm 0.50$
File Write |  $31.4\pm 0.50$ |  $30.51\pm 0.50$
Socket Connect |  $76.73\pm 6.00$ |  $78.71\pm 5.80$
Shell Execution |  $304.33\pm 1.76$ |  $353.66\pm 2.27$

Figure 7:  Microbenchmarking results for the permission verification function,
varying the number of packages in the application and the call stack sizes. As
predicted, the execution time is constant with respect to the number of
packages, and linear with respect to the call stack lengths.

####  6.2.2 Performance — Results

##### Cost by operation:

Table 3 shows the results of our microbenchmark tests on the file read, file
write, socket connection, and shell execution operations. The results show
that the overhead introduced by the instrumentation is significant for
operations with very short durations. As it is a constant overhead, the
overhead is negligible for operations with longer durations, usually not
differentiable from the JVM noise.

##### Predicted performance trends:

Figure 7 shows the microbenchmark results of Next-JSM’s permission
verification function. The execution time is constant with the number of
packages and lines with the depth of the call graph.

Table 4 shows the runtime results of our profiling results on applications
from the Dacapobench suite. The runtime overhead on most applications is
negligible, with an average runtime overhead of only 2.72%. Eclipse is the
only outlier, with an overhead of 51% due to intensive file system access. We
measured a start-up cost of $\sim$250ms for a small permission file. This is
the overhead incurred when parsing the permissions file, building the
permissions context, and modifying the bytecodes of the configured classes.
This overhead does not depend on the size of the applications nor the
frequency of their usage of sensitive permissions.

Table 4:  Execution time overheads (Dacapobench-Java). The fourth column indicates overhead with Next-JSM configured for permission enforcement. The final column indicates overhead when monitoring only shell execution. These measurements include noise indicated by the “performance benefits” of Next-JSM on several applications. Only Eclipse had overhead substantially beyond this noise, related to its heavy use of file system operations.  App Name |  # of Perms |  Without Next-JSM (s) |  Overhead (With Next-JSM) |  Overhead (With exec-Next-JSM)
---|---|---|---|---
avrora |  6 |  10223.7 |  0.01% |  -0.32%
batik |  16 |  3936.8 |  -0.69% |  -1.30%
biojava |  6 |  11560.5 |  -0.93% |  -1.21%
eclipse |  23852 |  24464.5 |  51.28% |  0.31%
fop |  94 |  2988.2 |  3.27% |  -0.07%
graphchi |  97 |  14936.1 |  2.22% |  0.77%
h2 |  10 |  25890.7 |  -8.02% |  -2.93%
jme |  14 |  8326.3 |  0.07% |  0.14%
jython |  1570 |  10581.2 |  5.15% |  -0.09%
kafka |  182 |  10059.5 |  1.09% |  0.28%
luindex |  11 |  30184.5 |  0.00% |  5.68%
lusearch |  6142 |  7468.1 |  -2.13% |  -2.43%
pmd |  12 |  4986.5 |  -0.61% |  0.82%
sunflow |  13 |  4385.7 |  1.26% |  0.75%
tomcat |  1196 |  8377.8 |  1.78% |  0.92%
tradebeans |  42 |  30699 |  -0.21% |  -0.06%
tradesoap |  37 |  22345.4 |  0.87% |  1.01%
xalan |  8718 |  2240.8 |  -0.22% |  -3.37%
zxing |  2505 |  3246.6 |  -2.60% |  -4.85%
Medians |  40 |  — |  0.01% |  0.01%

###  6.3 RQ3: Addressing the JSM’s Shortcomings

Table 5:  Usability comparison between Next-JSM and the (deprecated) JSM.  Usability Properties |  JSM |  Next-JSM
---|---|---
Permission Model |  Brittle |  Flexible section 5.2.3
|  Must grant all permissions types |  Can enforce specific permission types
|  Must specify all accessible objects |  Supports negative permissions
Programming Model |  Difficult |  Easy section 5.2.2
|  Application require’s package’s permissions by default |  Application requires only its own permissions
|  Package inherits all application’s permissions |  Package has its own permissions
|  All classes require explicit permission |  Support for Permission inheritance
Capabilities Inference |  Not Available |  Available section 5.3

We assessed Next-JSM’s abilities to address the reported flaws of the Java
Security Manager. Our analysis is qualitative. We depend on Next-JSM’s design,
our analysis of the JSM source code, and official documentation of the JSM
flaws.

####  6.3.1 Vulnerability Mitigation

The JSM is designed to mitigate the exploitation of Java vulnerabilities by
preventing an application’s access to dangerous Java APIs. These capabilities
depend on the application’s policy. To prevent supply chain vulnerabilities
with JSM, the policy must prevent dependencies from accessing capabilities
they do not need (without restricting the capabilities they do need). Hence,
permissions must be restricted to the various classes performing each
operation. With access to the source code, this is a hard problem as the
application maintainer must know the classes in his dependencies and the
resources they access. Without access to the source code, achieving this level
of precision requires inspecting JAR files. As a result, JSM users typically
fall back to specifying application-level permissions or granting all
permissions [43, 21], which do not protect against supply chain
vulnerabilities. Next-JSM’s supply-chain-aware permission model enables
package-level permission specification that prevents packages from possessing
permissions they do not need. By enforcing this least privilege on the
application’s dependencies, Next-JSM can protect against supply chain
vulnerability exploitation.

####  6.3.2 Usability

Table 5 shows a usability comparison between the deprecated JSM and Next-JSM.
The comparison characteristics were collected from the JSM deprecation
document JEP 411 [43] We have referenced the relevant sections where we
discussed how Next-JSM satisfied each requirement.

As shown in the table, The JSM possesses many flaws that make crafting
adequate policies challenging. Application maintainers are forced to specify
permissions for all permission types and objects, even when they do not pose
any threat to the application. The absence of library-specific permissions
implies the code in dependencies runs with the full permissions granted to the
application by default, violating the least privilege principle. In addition
to these, the absence of a capability tracing mechanism implies that an
application maintainer requires knowledge of a package’s implementation to
specify the necessary permissions.

A supply-chain-aware permission model allows Next-JSM to mitigate most of
these flaws in its design. The application maintainer can enforce only the
permission types he considers necessary, reducing the performance overhead
introduced. Furthermore, the capability tracing component serves as a helpful
aid in specifying the permissions needed by the packages. By mitigating these
flaws, Next-JSM is positioned to replace the Java Security Manager adequately.

##  7 Discussion and Future Work

###  7.1 Limitations

Next-JSM is the first Permission Manager designed to prevent the exploitation
of Java supply chain vulnerabilities. Our evaluation in section 6.1 shows that
Next-JSM effectively protects typical supply chain vulnerabilities. However,
we acknowledge several limitations in the approach.

  * •

If exploit leverages necessary functionality: Our thesis is that supply chain
exploits often leverage package functionality that an application does not
need. This permits the application owner to disable that functionality with no
negative effect. However, some exploits may make use of package functionality
on which the application depends. This was the case in CVE-2023-38889, in
which a package’s main use case involves shell execution, and the attacker
injects shell commands into the string. While permission management systems
can in principle be extended to consider not just the system call issued but
also the arguments to it, doing so entails substantial per-call implementation
and a more complex permission language. Alternatively, the application
engineer may determine that the benefit of disabling the functionality
outweighs the cost, e.g., if they have appropriate error handling for failures
in the package.

  * •

If indirect exploit: Our design assumes that the exploit will be conducted
within the execution context of the vulnerable package. It is possible that an
attacker could propagate the exploit to another thread or process, e.g., via
inter-process communication or a side channel. Next-JSM does support — to a
limited degree — the case of asynchronicity (e.g., as supported natively by
Java file system APIs). The current approach restricts the use of the
Thread.create() API. A more advanced implementation would propagate
permissions to the new Thread.

  * •

If application-level sensitive operations: Next-JSM is focused on security-
sensitive system calls, as these are the primary exploit of current software
supply chain vulnerabilities. However, if an attacker has knowledge of the
target application, then there may be application-specific APIs that would be
similarly harmful (e.g., debiting a bank account). As Next-JSM uses binary
rewriting, our design would allow an application engineer to add arbitrary
classes and function calls to the permission scheme.

###  7.2 Emergency Permission Restriction

Several research studies have shown the time gap between vulnerability
discovery, the availability, and propagation of patches [54, 19] (cf. section
2.1). With the discovery of the Log4J vulnerability, many application
maintainers were reported to have shut down their applications while waiting
for a patch, resulting in customer dissatisfaction and revenue loss.
Furthermore, application maintainers may hesitate to install a patch
immediately as it may be incomplete. Next-JSM can be _emergency first-aid_ in
this scenario. Permissions can be immediately specified to restrict the
vulnerable package’s access to sensitive resources, reducing the possibility
of exploitation.

Other forms of commercial _emergency first aid_ exist to protect applications
from zero-day vulnerabilities. For example, Chainguard [2] and Snyk [9] offer
patched versions of packages. However, the patches take time to develop, and
they are usually provided only for popular packages or high-impact
vulnerabilities. While Next-JSM does not fix the vulnerability, it ensures
that the vulnerability is not exploitable.

###  7.3 Integration with Java Security Manager

Next-JSM uses its Bytecode Rewriting Engine to insert hooks that enable its
permission manager to interact with the Java application. However, until
recently, such hooks were provided by the core Java classes as part of the
Java Security Manager. We suggest that the Java team deprecate only the Policy
and AccessController classes, which represent their implementation of a
permission manager, and leave the Security Manager APIs and the hooks as a
framework that supports the use of custom permission managers. When
implemented this way, Next-JSM can be refactored to rely on the JSM’s already-
existing hooks while providing a permission manager that protects against
supply chain vulnerabilities.

Beyond supporting integration with the JSM, the presence of hooks in the core
classes of other JVM-based languages will also enable Next-JSM’s support for
these languages. Due to Next-JSM’s compatibility with the Java Virtual
Machine, the Capability Tracing and Permission Enforcement component will also
be compatible with JVM-based languages like Scala, Groovy or Kotlin.
Applications built using these languages can invoke Next-JSM to prevent the
exploitation of supply chain vulnerabilities.

The use of Bytecode Rewriting provides an additional performance benefit. It
enables the selective instrumentation of sensitive methods depending on the
configured permissions. This avoids the overheads due to an application’s use
of a controlled resource, in the event that the application maintainer deems
it not security-sensitive.

###  7.4 Integrate Permissions into Supply Chains

If package-aware permission managers such as Next-JSM were widely adopted,
Software Bills of Materials (SBOMs) could become more powerful. SBOMs are a
first step toward greater visibility into an application’s dependencies and
supply chain. At present, an SBOM for a package or application informs
downstream users only of the upstream dependencies involved. Application
engineers may be unaware of a package’s full range of functionality and the
risks entailed, because SBOMs omit descriptions of potential capabilities.
Supported by automated capability tracing, package developers could document
the minimal set of permissions they require, possibly coupled to
configurations that enable more powerful features with richer permission sets.

##  8 Conclusion

Existing defenses for Java do not allow an application engineer to control the
security-sensitive system calls accessed by the application’s dependencies. We
argue that in the modern era of software development, engineers need to be
able to manage the accesses made not only by their business logic but also by
the third-party components they have integrated. To address this need, we
evaluate the feasibility of a package-granularity permission management scheme
for Java. We design, implement, and evaluate Next-JSM, the first package-
granularity permission manager for Java. Our evaluation shows that Next-JSM is
effective at mitigating CVEs (11/12 tried), offers low performance overheads
(average $\sim$3%), and supports permission management through automation and
a flexible permission language.

The software supply chain accelerates engineering, but requires supply chain-
aware security management tools. Next-JSM fills this gap for Java
applications.

## References

  * [1] AppArmor.  https://apparmor.net/.
  * [2] Chainguard Images: Reduce your attack surface.  https://www.chainguard.dev/chainguard-images.
  * [3] java.lang.instrument (Java Platform SE 8 ).  https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html.
  * [4] Open Source Insights.  https://deps.dev/.
  * [5] OpenJDK: jmh.  https://openjdk.org/projects/code-tools/jmh/.
  * [6] OSV - Open Source Vulnerabilities.  https://osv.dev/.
  * [7] The Security Manager (The Java™ Tutorials > Essential Java Classes > The Platform Environment).  https://docs.oracle.com/javase/tutorial/essential/environment/security.html.
  * [8] SELinux Wiki.  http://selinuxproject.org/page/Main_Page.
  * [9] Snyk patches to fix vulnerabilities.  https://docs.snyk.io/scan-applications/snyk-open-source/manage-vulnerabilities/snyk-patches-to-fix-vulnerabilities.
  * [10] Software Bill of Materials (SBOM) | CISA.  https://www.cisa.gov/sbom.
  * [11] Supply-chain Levels for Software Artifacts.  https://slsa.dev/.
  * [12] Threat Landscape for Supply Chain Attacks.  https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks.
  * [13] Docker: Accelerated Container Application Development, May 2022.  https://www.docker.com/.
  * [14] Abbadini, M., Facchinetti, D., Oldani, G., Rossi, M., and Paraboschi, S. Cage4Deno: A Fine-Grained Sandbox for Deno Subprocesses.  In Proceedings of the 2023 ACM Asia Conference on Computer and Communications Security (New York, NY, USA, July 2023), ASIA CCS ’23, Association for Computing Machinery, pp. 149–162.
  * [15] Bapat, D., Butler, K., and McDaniel, P. Towards Automated Privilege Separation.  In Information Systems Security (Berlin, Heidelberg, 2007), P. McDaniel and S. K. Gupta, Eds., Lecture Notes in Computer Science, Springer, pp. 272–276.
  * [16] Bier, S., Fajardo, B., Ezeadum, O., Guzman, G., Sultana, K. Z., and Anu, V. Mitigating Remote Code Execution Vulnerabilities: A Study on Tomcat and Android Security Updates.  In 2021 IEEE International IOT, Electronics and Mechatronics Conference (IEMTRONICS) (Apr. 2021), pp. 1–6.
  * [17] Biswas, S., Sohel, M., Sajal, M., Afrin, T., Bhuiyan, T., and Hassan, M. M. A Study on Remote Code Execution Vulnerability in Web Applications.
  * [18] Board, C. S. R. Review of the december 2021 log4j event.  Tech. rep., Cyber Safety Review Board, July 2022.
  * [19] Chinthanet, B., Kula, R. G., McIntosh, S., Ishio, T., Ihara, A., and Matsumoto, K. Lags in the release, adoption, and propagation of npm vulnerability fixes.  Empirical Software Engineering 26, 3 (Mar. 2021), 47.
  * [20] Cloud Native Computing Foundation.  CNCF paper defines best practices for supply chain security, May 2021\.  https://www.cncf.io/announcements/2021/05/14/cncf-paper-defines-best-practices-for-supply-chain-security/.
  * [21] Coker, Z., Maass, M., Ding, T., Le Goues, C., and Sunshine, J. Evaluating the Flexibility of the Java Sandbox.  In Proceedings of the 31st Annual Computer Security Applications Conference (New York, NY, USA, Dec. 2015), ACSAC ’15, Association for Computing Machinery, pp. 1–10.
  * [22] Costa, D., Bezemer, C.-P., Leitner, P., and Andrzejak, A. What’s Wrong with My Benchmark Results? Studying Bad Practices in JMH Benchmarks.  IEEE Transactions on Software Engineering 47, 7 (July 2021), 1452–1467.  Conference Name: IEEE Transactions on Software Engineering.
  * [23] De Groef, W., Massacci, F., and Piessens, F. NodeSentry: least-privilege library integration for server-side JavaScript.  In Proceedings of the 30th Annual Computer Security Applications Conference (New York, NY, USA, Dec. 2014), ACSAC ’14, Association for Computing Machinery, pp. 446–455.
  * [24] Ellison, R. J., Goodenough, J. B., Weinstock, C. B., and Woody, C. Evaluating and Mitigating Software Supply Chain Security Risks.  Tech. rep., CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, May 2010.  Section: Technical Reports.
  * [25] Enck, W., and Williams, L. Top Five Challenges in Software Supply Chain Security: Observations From 30 Industry and Government Organizations.  IEEE Security & Privacy 20, 2 (Mar. 2022), 96–100.  Conference Name: IEEE Security & Privacy.
  * [26] Ferreira, G., Jia, L., Sunshine, J., and Kästner, C. Containing Malicious Package Updates in npm with a Lightweight Permission System.  In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) (May 2021), pp. 1334–1346.  ISSN: 1558-1225.
  * [27] Gama, K., and Donsez, D. A Self-healing Component Sandbox for Untrustworthy Third Party Code Execution.  In Component-Based Software Engineering (Berlin, Heidelberg, 2010), L. Grunske, R. Reussner, and F. Plasil, Eds., Lecture Notes in Computer Science, Springer, pp. 130–149.
  * [28] Goldman, J. Time-Consuming Remediation: Assessing the Impact of Text4Shell, Oct. 2022.  https://www.esecurityplanet.com/threats/text4shell-vulnerability/.
  * [29] Goswami, P., Gupta, S., Li, Z., Meng, N., and Yao, D. Investigating The Reproducibility of NPM Packages.  In 2020 IEEE International Conference on Software Maintenance and Evolution (ICSME) (Sept. 2020), pp. 677–681.  ISSN: 2576-3148.
  * [30] Gudka, K., Watson, R. N., Anderson, J., Chisnall, D., Davis, B., Laurie, B., Marinos, I., Neumann, P. G., and Richardson, A. Clean Application Compartmentalization with SOAAP.  In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, Oct. 2015), CCS ’15, Association for Computing Machinery, pp. 1016–1031.
  * [31] Holm, H., Sommestad, T., Franke, U., and Ekstedt, M. Success Rate of Remote Code Execution Attacks : Expert Assessments and Observations.  Journal of universal computer science (Online) 18, 6 (2012), 732–749.  Publisher: J.UCS consortium.
  * [32] Jamrozik, K., von Styp-Rekowsky, P., and Zeller, A. Mining sandboxes.  In Proceedings of the 38th International Conference on Software Engineering (New York, NY, USA, May 2016), ICSE ’16, Association for Computing Machinery, pp. 37–48.
  * [33] Kumar, D., Ma, Z., Durumeric, Z., Mirian, A., Mason, J., Halderman, J. A., and Bailey, M. Security challenges in an increasingly tangled web.  In Proceedings of the 26th International Conference on World Wide Web (2017), pp. 677–684.
  * [34] Lamb, C., and Zacchiroli, S. Reproducible Builds: Increasing the Integrity of Software Supply Chains.  IEEE Software 39, 2 (Mar. 2022), 62–70.  Conference Name: IEEE Software.
  * [35] Lamowski, B., Weinhold, C., Lackorzynski, A., and Härtig, H. Sandcrust: Automatic Sandboxing of Unsafe Components in Rust.  In Proceedings of the 9th Workshop on Programming Languages and Operating Systems (New York, NY, USA, Oct. 2017), PLOS’17, Association for Computing Machinery, pp. 51–57.
  * [36] Machiry, A., Redini, N., Camellini, E., Kruegel, C., and Vigna, G. Spider: Enabling fast patch propagation in related software repositories.  In 2020 IEEE Symposium on Security and Privacy (SP) (2020), IEEE, pp. 1562–1579.
  * [37] Narayan, S., Disselkoen, C., Garfinkel, T., Froyd, N., Rahm, E., Lerner, S., Shacham, H., and Stefan, D. Retrofitting Fine Grain Isolation in the Firefox Renderer.  pp. 699–716.
  * [38] Newman, Z., Meyers, J. S., and Torres-Arias, S. Sigstore: Software Signing for Everybody.  In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, Nov. 2022), CCS ’22, Association for Computing Machinery, pp. 2353–2367.
  * [39] Ohm, M., Pohl, T., and Boes, F. You Can Run But You Can’t Hide: Runtime Protection Against Malicious Package Updates For Node.js, May 2023.  arXiv:2305.19760 [cs].
  * [40] Okafor, C., Schorlemmer, T. R., Torres-Arias, S., and Davis, J. C. SoK: Analysis of Software Supply Chain Security by Establishing Secure Design Properties.  In Proceedings of the 2022 ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses (Los Angeles CA USA, Nov. 2022), ACM, pp. 15–24.
  * [41] Qualys Research Team.  Infographic: Log4Shell Vulnerability Impact by the Numbers | Qualys Security Blog, Mar. 2022.  https://blog.qualys.com/vulnerabilities-threat-research/2022/03/18/infographic-log4shell-vulnerability-impact-by-the-numbers.
  * [42] Sandhu, R., and Samarati, P. Access control: principle and practice.  IEEE Communications Magazine 32, 9 (Sept. 1994), 40–48.  Conference Name: IEEE Communications Magazine.
  * [43] Sean Mullan.  JEP 411: Deprecate the Security Manager for Removal.  https://openjdk.org/jeps/411.
  * [44] SHEN, M., PILLAI, A., YUAN, B. A., DAVIS, J. C., and MACHIRY, A. An empirical study on the use of static analysis tools in open source embedded software.  arXiv preprint arXiv:2310.00205 (2023).
  * [45] Sumeet Wadhwani.  16% of Organizations Impacted by Spring4Shell Exploitations, Europe Worst Hit.  https://www.spiceworks.com/it-security/vulnerability-management/news/spring4shell-impact/.
  * [46] Sun, M., and Tan, G. NativeGuard: protecting android applications from third-party native libraries.  In Proceedings of the 2014 ACM conference on Security and privacy in wireless & mobile networks (New York, NY, USA, July 2014), WiSec ’14, Association for Computing Machinery, pp. 165–176.
  * [47] Synopsys.  2023 OSSRA Report.  Tech. rep., 2023.  https://www.synopsys.com/software-integrity/engage/ossra/rep-ossra-2023-pdf.
  * [48] Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, R., and Cappos, J. in-toto: Providing farm-to-table guarantees for bits and bytes.  pp. 1393–1410.
  * [49] Vasilakis, N., Karel, B., Roessler, N., Dautenhahn, N., DeHon, A., and Smith, J. M. BreakApp: Automated, Flexible Application Compartmentalization.  In Proceedings 2018 Network and Distributed System Security Symposium (San Diego, CA, 2018), Internet Society.
  * [50] Vasilakis, N., Staicu, C.-A., Ntousakis, G., Kallas, K., Karel, B., DeHon, A., and Pradel, M. Preventing Dynamic Library Compromise on Node.js via RWX-Based Privilege Reduction.  In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, Nov. 2021), CCS ’21, Association for Computing Machinery, pp. 1821–1838.
  * [51] Wan, Z., Lo, D., Xia, X., Cai, L., and Li, S. Mining Sandboxes for Linux Containers.  In 2017 IEEE International Conference on Software Testing, Verification and Validation (ICST) (Mar. 2017), pp. 92–102.
  * [52] Wang, W., Lin, X., Wang, J., Gao, W., Gu, D., Lv, W., and Wang, J. HODOR: Shrinking Attack Surface on Node.js via System Call Limitation, June 2023.  arXiv:2306.13984 [cs].
  * [53] Xiao, F., Yang, Z., Allen, J., Yang, G., Williams, G., and Lee, W. Understanding and Mitigating Remote Code Execution Vulnerabilities in Cross-platform Ecosystem.  In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, Nov. 2022), CCS ’22, Association for Computing Machinery, pp. 2975–2988.
  * [54] Zhang, L., Liu, C., Chen, S., Xu, Z., Fan, L., Zhao, L., Zhang, Y., and Liu, Y. Mitigating Persistence of Open-Source Vulnerabilities in Maven Ecosystem, Aug. 2023.  arXiv:2308.03419 [cs].