# SoK: A Defense-Oriented Evaluation of Software Supply Chain Security

Eman Abu Ishgair
Purdue University  Marcela S. Melara
Intel Labs  Santiago Torres-Arias
Purdue University

###### Abstract

The software supply chain comprises a highly complex set of operations,
processes, tools, institutions and human factors involved in creating a piece
of software. A number of high-profile attacks that exploit a weakness in this
complex ecosystem have spurred research in identifying classes of supply chain
attacks. Yet, practitioners often lack the necessary information to understand
their security posture and implement suitable defenses against these attacks.

We argue that the next stage of software supply chain security research and
development will benefit greatly from a defense-oriented approach that focuses
on holistic bottom-up solutions. To this end, this paper introduces the AStRA
model, a framework for representing fundamental software supply chain elements
and their causal relationships. Using this model, we identify software supply
chain security objectives that are needed to mitigate common attacks, and
systematize knowledge on recent and well-established security techniques for
their ability to meet these objectives. We validate our model against prior
attacks and taxonomies. Finally, we identify emergent research gaps and
propose opportunities to develop novel software development tools and systems
that are secure-by-design.

##  1 Introduction

The software supply chain has gained increased attention in light of recent
high-profile attacks that subverted the creation process of a piece of
software (e.g., [68, 118, 27, 44, 42, 55, 63]). According to the 2022 Anchore
survey of software and IT professionals across the United States and Europe,
62% of organizations saw minor to significant impacts by software supply chain
attacks, and 54% of respondents indicated that software supply chain security
was a significant or top priority at their organization [26].

In response, efforts led by major software vendors, open-source software
professionals, and standards organizations have proposed multiple frameworks
to audit the software development lifecycle (SDLC) and validate open-source
and proprietary software (e.g., [69, 73, 102, 107, 32, 106, 89, 123, 124,
126]). Recent U.S. government regulation requiring vendors to adopt specific
software supply chain security practices by Fall 2023 [132, 146] has applied
additional pressure to address the problem.

However, despite pressure from regulators and security professionals, these
mechanisms are yet to experience widespread adoption. For instance, continuous
integration and continuous deployment (CI/CD) practices have become central to
automating and hardening software production in over 50% of vendors’ SDLCs
[109, 143]. On the other hand, signing software artifacts and generating
metadata like Software Bills of Materials (SBOM), are practices that only up
to 25% of vendors have adopted [143].

The academic research community has gained valuable insights on software
supply chain security through studies on attack classes and developer
practices (e.g., [103, 75, 77, 80, 79, 47, 148, 65, 33]). The lag in adoption
of techniques [92] that achieve specific security goals needed to mitigate
these attacks indicates a gap in how these research findings translate into
practical defenses that industry practitioners can adopt to defend their
software supply chain.

We argue that attack-oriented studies are only one side of the software supply
chain security “coin”, and observe two important limitations. First, this top-
down approach requires anyone seeking to design or implement suitable supply
chain defenses to infer desired security objectives. That is, attack
taxonomies such as Ladisa et al. [79] and Ohm et al. [103] highlight attack
vectors in specific software supply chain settings, but they do not provide
explicit information to assess security gaps in existing individual defenses
or entire supply chain architectures.

Second, attack-oriented studies tend to take a compartmentalized view on the
software supply chain by enumerating security problems in individual
operations or actors in the chain. Thus, this approach overlooks the inherent
causal properties of software supply chains when assessing risk.

To address these crucial limitations, our paper systematizes knowledge about
software supply chain security objectives and fundamental defense techniques
that can meet these objectives. Taking a bottom-up, defense-oriented approach,
we seek to answer four fundamental research questions:

RQ3: How do we represent all elements in a software supply chain while
capturing its transitive, recursive nature?

RQ2: What are the fundamental security objectives for mitigating common
software supply chain attacks?

RQ3: What are the classes of defenses that meet these security objectives?

RQ4: What are salient future software supply chain security research
opportunities?

To this end, we develop the AStRA model, a _holistic_ graph-based
representation of the four core elements of a software supply chain—Artifacts,
Steps, Resources, PrincipAls—which captures their inherent causal
relationships. We then use our model to identify core security objectives
needed to mitigate common supply chain attacks and taxonomize possible defense
techniques.

By evaluating existing approaches from a breadth of computer science domains,
we describe their ability to meet these objectives from a _bottom-up_
approach. To validate the generality and completeness of the AStRA model, we
apply our model to case study software supply chain architectures and attacks
against them, and map attacks from the IQT Labs dataset [121] to our model.

Our ultimate goal is to provide a preliminary objective-driven framework that
enables software vendors and security researchers alike to reason about their
threat model and security posture when adopting or developing new software
supply chain defense techniques. As such, we include a comparative analysis
between our security objectives and the Ladisa  _et al._ SoK [79]—the current
state-of-the-art attack taxonomy—establishing an explicit mapping between
attack classes and desired security objectives to mitigate each class of
attacks. As such, this paper builds upon methods in [105] and complements
attack-oriented work [79, 103].

In summary, our main contributions are:

  1. 1.

the AStRA model, a graph-based conceptual framework for holistically
representing a software supply chain (§2);

  2. 2.

identification of security objectives for each AStRA element, and a taxonomy
of defense approaches (§3-§7);

  3. 3.

an in-depth validation of the AStRA model (§8);

  4. 4.

a discussion of research gaps and future directions (§9).

##  2 Systematization Model and Methodology

To reason about different defense approaches’ ability to meet specific
software supply chain security objectives, we must first develop a holistic
conceptual framework (towards RQ1). Thus, we begin by defining the core
elements of a software supply chain, and use these to describe a model that
represents these elements as well as their relationships in a supply chain.

###  2.1 Core Software Supply Chain Elements

Fundamentally, a software supply chain can be described in terms of four core
elements:

1) Principals: Broadly, any organization, institution or individual involved
with any aspect of the software supply chain. Human principals are often
identified via _digital credentials_ such as cryptographic keys, access
tokens, or certificates. For the sake of simplicity, we consider a principal
and her credentials to be equivalent.

2) Artifacts: A software artifact refers to a unit of digital information that
is required for the creation, configuration and evaluation of a piece of
software.

An artifact is typically represented as a file, immutable object, or a
collection thereof, such as Debian package, a Docker image, a source code
file, or a series of translation files. Artifacts are created either manually
(e.g., source code) or generated through software (e.g., Docker image).

3) Resources: A resource is any software component, service or hardware
component used in the creation, configuration, or evaluation of an artifact.
Resources may be implemented or configured by first-party principals or third-
party service providers. Examples of resources include source control
management systems like Git [129], CI/CD services such as GitHub Actions [59],
or the operating system on a machine used to build an artifact.

4) Steps: A step refers to a specific task or operation that creates,
evaluates or distributes a software artifact (per Torres Arias  _et al._
[69]). In other words, we consider steps to be the logical units in the
software supply chain. Individual steps are usually performed within a given
administrative domain, i.e., a single organization. In practice, principals
use resources to carry out steps.

###  2.2 AStRA model

Identifying the fundamental elements of a software supply chain allows us to
describe an abstract model which enables principled reasoning about the
security of individual elements. Yet, evaluating each element in isolation is
not sufficient to understand how the causal relationships between these
elements impact the overall security of a software supply chain.

To reason about software supply chain defenses, we introduce a the AStRA
model, a conceptual framework that includes a representation of supply chain
_topology_. That is, our model represents a specific software supply chain
structure as a directed acyclic graph (DAG) in which Artifacts, Step,
Resources and principAls are vertices and the edges between them represent
their relationships.

Fig. 1 shows a simple example. Our model captures three types of causal
relationships between supply chain elements:

  1. 1.

Principals, identified by credentials, _use_ resources;

  2. 2.

Resources _carry out_ steps;

  3. 3.

Steps _consume_ and _produce_ artifacts.

These abstract elements of the AStRA model allow us to capture two intrinsic
properties of the software supply chain that have an effect on risk. First,
this model makes explicit all dependency relationships between the
participants, components, and operations in the software supply chain.
Including these dependencies in our analysis of security objectives for the
individual AStRA elements then enables us to identify the scope and
limitations of possible defenses.

Second, the AStRA model enables us to express the causal nature of the
software supply chain. That is, by including ingress and egress relationships
between artifacts and steps, the model allows us to make explicit not only the
transformations of material artifacts into products, but also to capture the
transitions over time of _stateful_ artifacts (e.g., version-controlled code
repositories).

Note that our model treats a artifacts that evolve over time, such as a source
code repository under version control, as two distinct artifacts each
capturing its state at time $t$ before and $t+1$ after a step (e.g., a commit
step). Making such causal properties explicit enables us to preserve the
acyclic property of the supply chain DAG.

Figure 1: The supply chain DAG for a single version control commit step.

###  2.3 Systematization Methodology

Complementing prior attack-oriented systematization and survey work [79, 103],
this paper aims to evaluate approaches that _defend_ against a broad set of
software supply chain threats.111We note that concurrent work in Ohm  _et al._
[104] focuses on defenses against a single class of risks pertaining to
malicious packages. To this end, our systematization leverages the AStRA model
and groups defenses by each component of the software supply chain in
dedicated sections.

For each component, as well as the DAG topology as a whole, we identify
various security objectives that are needed to mitigate common attacks
(towards RQ2), and discuss different academic and industry approaches that
seek to meet these objectives (towards RQ3).

Table 1 summarizes our evaluation. As the primary interface to the software
supply chain, our systematization begins with defenses for principals (§3).
Next, as the unit of information passed between steps, we discuss defenses for
artifacts (§4), As resources, in practice, encompass both tool artifacts as
well as services, our evaluation of defenses for resources (§5) builds upon
the evaluation of artifacts. Similarly, reducing risks to steps (§6) and the
topology (§7) requires a number of unique approaches on top of defenses
discussed in prior sections.

Evaluation Scope. Studies like Ladisa  _et al._ [79] also highlight human-
factor based attacks such as bribery and typosquatting. Thus, understanding
practical adoption considerations associated with specific defense approaches
is crucial. Yet, due to the limited number of usability studies for software
supply chain defenses, we leave the study of human-centered approaches such as
developer education to address this class of attacks as future work.

Table 1: Evaluated software supply chain defense approaches mapped to security
objectives.

Technique | Example | Security Objectives
---|---|---
_Principals_ |  | P1 | P2 | P3 | P4 | P5
usage-limited credentials† |  OTP [114] |  | - | - | - | -
ephemeral credentials† |  Fulcio [88] |  | - |  | - | -
credential transparency† |  CONIKS [91] | - |  | - | - |
role separation |  GH roles [61] | - | - |  | - | -
multi-factor authentication† |  2FA [111] |  | - |  | - | -
separation of principal privilege |  2-P Code Review [39] | - | - | - |  | -
threshold authorization† |  | - | - |  |  |
_Artifacts_ |  | A1 | A2 | A3 |  |
hashing† |  Subresource Integrity [35] |  | - | - |  |
artifact signing† |  Microsoft Authenticode [127] |  | - | - |  |
metadata signing† |  The Update Framework [117] |  |  | - |  |
artifact transparency† |  Sigstore [123] |  |  | - |  |
ledger-based systems† |  Contour [24] |  |  | - |  |
static analysis† |  Bandit [31] | - | - |  |  |
dynamic analysis† |  HARP [138] | - | - |  |  |
_Resources_ |  | R1 | R2 | R3 |  |
discretionary access control† |  Linux file permissions [140] |  | - | - |  |
mandatory access control† |  AppArmor [1] |  | - | - |  |
filtering† |  eBPF [49] |  |  | - |  |
virtualization† |  cgroups [5] | - |  |  |  |
_Steps_ |  | S1 | S2 | S3 |  |
Formal verification† |  Verifiable Compilers [85] |  | - | - |  |
Deterministic steps† |  DetTrace [97] |  | - | - |  |
Step transparency |  SBOMs [126] | - |  | - |  |
Auth. Step Transparency† |  in-toto [7] | - |  |  |  |
Step Consensus† |  CHAINIAC [6] | - |  |  |  |
_Topology_ |  | T1 | T2 | T3 | T4 | T5
supply chain layout integrity† |  in-toto layouts [8] |  | - | - |  |
resource replication† |  Mirrors [2] | - |  | - | - | -
dependency reduction |  Bootstrappable builds [41] | - | - |  | - | -
supply chain reproducibility† |  Reproducible builds [81] | - | - | - |  |

= objective met;  = implementation-dependant objective-met; - = objective not
met; $\dagger$ =has academic publication

##  3 Defending Principals

Incidents like the first stage of the SolarWinds hack [55], targeted the
principal element of a software supply chain by exploiting compromised
credentials. Ultimately, this allowed an attacker to plant backdoors in the
networks of thousands of companies and government agencies [18].

Thus, a primary objective for defending principals is to address weaknesses in
_authorization_ – the process that uses credentials to grant a principal the
permissions to trigger a step. That is, assuming authorization is in place,
defenses aim to make it more difficult to abuse credentials.

###  3.1 Principal Security Objectives

P1 - Credential reuse limited: Limits how often a principal can use the same
credential to perform a step. This is achieved by ensuring credentials are
used within a time frame or count, which reduces the window for compromise.

P2 - Credential compromise detected: Provides mechanisms to detect compromised
credentials. This reduces the impact of a compromise by providing means to
check whether credentials were misused.

P3 - Credential authority limited: Reduces the level of authority a single
credential can give to a principal. This increases the effort needed to
compromise a step, and can be accomplished by requiring multiple _credentials_
to authorize a principal or by restricting the types of operations a
credential may be used for.

P4 - Multiple principals required: Requires multiple principals to carry out a
step. This is stricter than P3 as it reduces the risk of misbehaving
principals.

P5 - Minimum security properties preserved: Within a certain threshold of
compromise, core security properties are maintained. That is, this can be met
if a sufficiently large set of authorized principals behave honestly.

###  3.2 Defense Approach Evaluation

To support the evaluated principal defense approaches, we assume an underlying
_authentication_ mechanism to verify the validity of a credential.

####  3.2.1 Restrictions on compromise impact

Defenses in this category aim to contain the impact of compromising a
principal or a credential.

_Usage-limited credentials_ restrict the number of times a given credential
may be used to authorize a principal. This implies that an attacker has a
limited number of opportunities to exploit a given credential once compromised
(P1).

A commonly implemented mechanism is one-time passwords, or OTP, (e.g., [114,
52]), which are only valid for a single authorization session. Implemented via
combinations of pseudorandom functions, cryptographic hash functions, and
encryption schemes [52, 114, 82], this technique has been in use for about
four decades [82] to address user authentication and authorization risks in
distributed systems.

_Ephemeral credentials_ constrain the window of vulnerability by limiting the
time frame during which a credential is valid. In the case of the SolarWinds
hack, this approach might have restricted how long the attackers had access to
the system. One form of ephemeral credentials are cryptographic keys, referred
to as “ephemeral keys” [95] or “session keys” [38], which are newly generated
for each key exchange or communication process.

Another form are short-lived certificates [133, 113], digital certificates
used to authenticate a remote party that have a short validity period, i.e.,
they expire after a short period of time (e.g., a few minutes [29] to a few
days [133]). To address P1 in the software supply chain, Fulcio [88] provides
a framework for generating short-lived X.509 certificates to curb the impact
of compromised credentials. In implementations such as SPIFFE [131], short-
lived credentials may also describe the purpose of the credential constraining
the authority granted to a principal (P3).

_Credential transparency_ enables principals and steps to detect whether a
credential compromise has occurred (P2). This approach typically relies on a
database backed by a Merkle tree [93] referred to as a _transparency log_ ,
which makes any changes to the contents of the log easily detectable. Many
implementations also preserve some security properties so long as there is one
honest principal, providing additional reliability in the face of compromise
(P5).

This approach was first realized through certificate transparency [84], a
framework and protocol for publicly logging and auditing the validity of web
certificates. CONIKS [91] was the first credential transparency approach
tailored specifically for end-user encryption keys. Similar efforts building
upon these lines of work have emerged since (e.g., [83, 115, 67, 34]).

_Role separation_ reduces the authority of any given principal (and their
credentials) to a specific set of steps or operations a principal can perform
(P3). Taking a more preventative approach than the other approaches in this
category of principal defenses, the principles of _least common mechanism_
[110] and _least privilege_ [116] underpin role separation. The former reduces
the functions shared between different principals to reduce the risks of
interference, while the latter reduces the authority of a given principal to
the minimum needed _degree_ for her to perform a desired step.

In practice, these principles are used to group principals by the type of
function they fulfill in an application [39]. Common roles in open- and
closed-source software development settings include project leads,
maintainers, and software developers and contributors, as well as project
managers, product security engineers, system administrators, policy
administrators, software testers and project auditors, and customers (i.e.,
product consumers). 222We derive this set of common software supply chain
roles from academic [103, 80, 33] and industry [39, 125] sources.

To achieve role separation, many software supply chain resources and tools
provide mechanisms for assigning users to different roles and assigning
different levels of authority and control over a given step or resource [61,
100, 101]. One such implementation is GitHub’s repository roles [61], that
allow organization owners to grant members and outside collaborators different
levels of access permissions to code repositories based on their role in the
organization.

####  3.2.2 Redundancy in authorization

Such defenses increase the efforts an attacker must spend to gain unauthorized
access to a step. This can be accomplished by requiring multiple credentials
or principals to successfully carry out a step.

_Multi-factor authentication (MFA)_ relies on a principal using at least two
different _categories_ of credentials: something a principal knows (e.g., a
password), something they have (e.g., a hardware token), or something they are
(e.g., their physical fingerprint) (P3). Service providers for software supply
chain resources such as package managers [111] and version control systems
[108] have begun to adopt this approach. This approach could have made it
harder for SolarWinds attackers to impersonate principals upon accessing the
build system. Many MFA implementations leverage OTPs (e.g., [147, 46, 48]),
providing additional risk mitigation (P1).

_Separation of principal privilege_ requires multiple separate principals to
authorize a step [116], preventing the authority for a given step from lying
in a single principal (P4). As an important security mechanism in various
types of systems (see §5), this approach may show promise as a software supply
chain defense as well.

One notable application of this approach in the software supply chain is two-
person code review,which requires at least two independent reviewers with
sufficient privilege and expertise to authorize source code changes before
merging them into the main codebase [39]. This practice helps improve the
reliability of human code reviews by reducing the risks of undetected problems
in a codebase, especially through contributions made by untrusted principals
[64].

_Threshold authorization_ increases the difficulty of an attacker gaining
unauthorized access by dividing the credential needed to perform a step
amongst $n$ authorized principals (P3-P5). This approach might have helped
narrowing the impact of SOLARBURST, or prevented the attackers from performing
building steps. Threshold authorization has its roots in $(t,n)$ threshold
cryptography, where $t$ out of $n$ credential shares are needed to decrypt
data (e.g., [120]).

Threshold schemes have also been applied in other use cases such private
information retrieval (e.g., [141]) and peer-to-peer membership control (e.g.,
[94]). However, to our knowledge, the application of threshold schemes in the
software supply chain has yet to be studied.

###  3.3 Discussion

Table 1 reveals that no one approach is sufficient for reducing the possible
risks to principals. Practical defenses have combined multiple approaches to
provide stronger security properties. One interesting combination of
approaches are usage-limited credentials (e.g., OTPs [114]) with multi-factor
authentication (e.g., two-factor authentication [108]) reducing risks in two
key areas (P1 and P3). Despite the highly collaborative, multi-party nature of
today’s software development practices, this widely adopted defense
combination primarily reduces risks for individual principals, who represent
single points of failure. Providing additional security properties requires
layering this approach with others, to make it more difficult to compromise an
entire supply chain through a single principal.

Another promising combination of approaches are short-lived credentials like
those provided by Sigstore’s Fulcio [88] and credential transparency: indeed,
Fulcio relies on CT [4] for compromise detection and added reliability for
issued short-lived credentials [29], reducing risks in three key areas (P1-P3,
and P5). To simplify usability, Fulcio additionally relies on OpenID Connect
[15] and timestamping services (RFC 3161) [21] for credential generation and
discovery. Based on our evaluation, layering this defense combination with an
additional approach to address P4 would potentially not significantly impact
adoption costs.

Research gaps. Several approaches in our evaluation have potential for
addressing software supply chain risks, although they have been studied only
in other application domains. Threshold schemes, for instance, meet several
principal security objectives (P3-P5); their applicability to improving the
reliability of authorization in the software supply chain seems a worthwhile
direction for future research.

Further, credential transparency is a promising approach for active detection
of credential compromise. However, its limited adoption for software supply
chain security warrants further study into its practical applicability to
address the problem. Similarly, understanding how other principal defenses may
be combined with credential transparency remains an open question.

##  4 Defending Software Artifacts

Artifacts are the unit of exchange in the software supply chain. As a result,
supply chain attacks targeting artifacts often focus on surreptitiously
modifying or replacing an authentic artifact with a compromised one.

###  4.1 Security Objectives

A1 - Artifact changes detected: Tampering with artifacts at rest, in transit
or in memory can be detected.

A2 - Artifact non-equivocation: All principals have the same view of the
artifacts produced, and consumed by a given step.

A3 - Expected artifact behavior enforced: Ensures that artifacts exhibit the
expected functionality or behavior.

###  4.2 Defense Approach Evaluation

####  4.2.1 Detection of artifact tampering.

Such defenses provide mechanisms for detecting tampering with the integrity of
an artifact in transit or at rest.

_Hashing_ relies on a cryptographically-strong hash function such as SHA-256
[96] to ensure that any bit-level changes to an artifact are detected. The
central property of a cryptographically strong hash function that makes it
suitable for artifact tamper detection is that the likelihood of two different
input artifacts having the same resulting checksum is extremely low. In the
software supply chain, hashing is used to enable artifact content matching in
settings such as source code repositories [57], packages published online
[43], and even credentials [145].

However, hashing alone only partially meets A1 as this approach has security
limitations [135, 23]. For instance, an attacker that is able to replace a
published artifact on a website is likely able to also replace the checksum.
In fact, given that these checksums are distributed through the same channel
as the software artifact, any compromise of such a channel subverts the
integrity guarantees of hashing.

_Artifact signing_ consists of generating a digital signature over the
contents of a software artifact (e.g., a package) [43]. In practice, a variety
of signing algorithms and protocols are used to sign artifacts. Microsoft
Authenticode [127] employs x.509 certificates, while Debian and Maven packages
are signed with GPG [43, 56]. Similarly, version controlled source code (e.g.,
GitHub-hosted code) also commonly relies on GPG signing [58, 71].

Thus, the added authenticity properties provided by crytographic signatures
overcome many of the limitations of hashing, providing stronger tamper
detection properties because the trust information (i.e., signing key) is
generally delivered through a separate channel. Nevertheless, studies like
Cappos et al. [33] and Torres-Arias et al. [135] have shown how selectively
tampering with artifact metadata can alter the integrity of a software
artifact (or collection thereof) even if it is signed. This approach therefore
only partially meets A1.

_Metadata signing_ applies the same principles to defend artifact metadata
(e.g., file creation time) against tampering as artifact signing. Such
defenses prevent the use of metadata as an additional vector to attack signed
software artifacts.

A widely used artifact metadata signing implementation is The Update Framework
(TUF) [117], which is used to sign package repository metadata. At the core of
this design, separation of privilege (through “ _signing roles_ ”) among
metadata types provides both tamper detection as well as a degree of non-
equivocation through publicly visible “freshness claims” [117].

Similarly, signing Docker container manifests help ensure a container’s
authenticity and integrity [70]. Indeed, this mechanism transitively signs it
contents (by means of a cryptographic hash) as well as its metadata, such as
container layers (i.e., dependent artifacts), size, and checksum. Metadata
signing together with artifact signing therefore achieves A1 and conditionally
A2.

_Artifact transparency_ leverages transparency logs to provide a verifiable
history of an artifact’s changes over time. This makes changes to artifacts as
well as surreptitious or compromised releases detectable (A1). Since we
consider credentials to be a special type of artifact, we view this approach
as a generalization of credential transparency (see §3.2).

One example is Firefox’s Binary Transparency [11] used to publish Firefox
binaries in a publicly-verifiable log. Another notable example is Sigstore
[98], which treats artifact signatures themselves as artifacts, logging them
in the Rekor transparency log [130]; Rekor additionally supports logging other
types of artifacts such as in-toto attestations [7], software bills of
materials, and other arbitrary binary blobs [130]. Because artifact
transparency defenses often include a public service, this approach partially
meets A2 as well.

_Ledger-backed systems_ leverage distributed ledgers (DL) to provide a global
view of artifacts as a means of deterring surreptitious tampering and
omissions of security-relevant artifact information. The append-only
properties of a DL together with a consensus-based mechanism for adding new
entries help ensure tamper detection (A1) and a consistent global view (A2).

Bandara et al. [30] propose a mechanism similar to Sigstore [98] but use a DL
as a backend data store rather than a transparency log. Further, Contour by
Al-Bassam et al. [24] is a binary transparency system that leverages the
Bitcoin blockchain to proactively help prevent users from installing malicious
software.

####  4.2.2 Enforcing Normal Behavioral Properties

Such defenses typically follow one of two general strategies: studying an
artifact’s normal behavior to distinguish it from the malicious case; or
identifying abnormal behavior.

_Static analysis_ approaches are widespread in computer security. In the
context of software supply chain, these are often used to identify suspicious
artifact components such as installed packages (e.g., by detecting a
vulnerable dependency), or to detect vulnerabilities that may be introduced
transitively (e.g., a statically compiled vulnerable library). At the core of
these approaches lies a mechanism for evaluating an abstract representation of
an artifact, such as its abstract syntax tree (AST) or bytecode.

Techniques such as [77] trace so-called “taints” throughout PHP web
applications to identify critical code execution paths that may lead to
abnormal behavior. Feature-based analysis mechanisms such as Jarhead [119] for
Java and Bandit [31] for Python trace through an artifact to evaluate and
collect information about abnormal program features, which can be later used
to rate or classify an artifact’s behavior. Since static analysis techniques
tend to be very domain-specific and require a separate enforcement mechanism,
however, this approach only partially achieves A3.

_Dynamic analysis_ evaluates an artifact’s behavior during its execution. The
execution may be emulated or performed in a controlled environment to reduce
the influence of external factors in the analysis. In the context of software
supply chains, this approach is used to detect maliciously behaving artifacts
before their utilization as a resource (see §5). The goal of this approach is
twofold: to avoid maliciously-injected malicious behavior, and to reduce the
number of vulnerabilities introduced as dependencies in the software supply
chain.

TaintCheck [37], for instance, employs taint analysis to identify and mitigate
specific vulnerabilities in x86 binaries through binary rewriting. Solutions
like Aftersight [99] perform a two-stage analysis in which full VM system
behavior is recorded, and then nondeterministic features (e.g., file system
interactions) are analyzed separately.

Machine learning (ML) based approaches are emerging in this space as well.
Jarhead [119], for instance, combines static analysis with ML to classify Java
applets as benign or malicious. HARP [138] uses Active Learning and
Regeneration (ALR) to detect application behavior with potentially abnormal
side-effects (e.g., file system changes, global variables, modules, process
arguments, etc). To detect these, HARP models an artifact’s functional
behavior in a controlled environment such that malicious behaviors are not
learned during inference. The inferred model can then regenerate
vulnerability-free versions of string libraries in JavaScript and C/C++.

While all of these mechanisms may achieve A3, rewriting or regenerating
binaries as in TaintCheck and HARP may directly conflict with other objectives
such as A1.

###  4.3 Discussion

Much like Principals, Table 1 shows that there is no one-stop-shop to achieve
all desired objectives, nor are several single approaches enough to achieve
individual properties. Artifact and metadata signing, for instance, are both
needed to fully achieve A1. Static and dynamic analysis techniques are often
combined for improved results to identify and enforce expected artifact
behavior (A3).

While composing systems to achieve all artifact security objectives may be
feasible, (e.g., by means of dynamic analysis and metadata signing), there is
no established best practice for doing so, nor have the security implications
of such combined systems been studied. This is a stark contrast with other
elements of the model (e.g., see resources below), which have garnered
significant industry interest in establishing guidance in the software supply
chain.

Another salient point is that of _conflicting properties_ in dynamic analysis
approaches, which may provide a particular A3 at the expense of other
objectives. This highlights the need for an approach to establish a cross-
property strategy.

Research gaps. Some of the evaluated approaches have seen varied degrees of
adoption. This is evidenced by the low uptake in solutions such as artifact
and metadata signing in critical areas such as package management [78, 16].
For hashing, for instance, research on mechanisms such as subresource
integrity html tags [35] may address known usability issues [36], but more
usability studies on a wider variety of artifact defenses are needed to
understand barriers to adoption.

Establishing better mental models about trust in artifacts like packages
through the properties above is also lacking. In particular, security policies
for software trust in different ecosystems are ad-hoc, and do not follow a
principled definition based on white or gray literature. That is, systems such
as GPG have provided mechanisms for developers to sign packages, but they
rarely develop infrastructure and processes to verify that the right developer
signed for the right package. Further, there is very little software
engineering research exploring the usability and process challenges to
appropriately define and enforce these policies.

Approaches such as ledger-backed systems face performance and efficiency
tradeoffs introduced by consensus algorithms used to help achieve A2. Given
that these approaches can provide availability and privacy properties [32, 24]
in addition to meeting objectives (A1, A2), and these mechanisms provide a
strong deterrent to attackers, more research is needed to reduce the
deployment costs of defenses.

##  5 Defending Resources

As described in §2.1, resources are themselves software components, i.e., they
are created through their own software supply chains. This means that many
security objectives that apply to resources may be met by artifact defenses
(see §4). At the same time, because resources are used to carry out (parts of)
a particular supply chain step, we identify additional security objectives
specific to resources, which pertain to mitigating execution-time risks.

For a resource to operate, it typically requires auxiliary resources and
artifacts, which we generally refer to as the _execution environment_.
Depending on the type of resource, it execution environment may be defined at
various levels of granularity ranging from an intra-process unit (e.g., thread
or domain), to an application, to a virtualized environment (e.g., container
or VM), to an entire system running on a hardware platform. Reducing risks to
resources thus involves protecting different aspects of execution
environments.

The Log4j vulnerability highlight the software supply chain risks associated
with widespread use of open-source dependencies as resources. In December
2021, security researchers discovered a vulnerability that enables remote
attackers to inject and remotely execute code through the messages that are
logged by Log4j utility. After its discovery, millions of attempted exploits,
many of which turned into successful denial-of-service (DoS) attacks [12,
136].

###  5.1 Resource Security Objectives

R1 - Resource privilege limited: Limits the operating privileges a resource is
granted to only those needed to carry out a step _within_ its execution
environment. This objective is equivalent to P3 aiming to reduce risk within
the context of an authorized step.

R2 - Environment interfaces restricted: Restricts the access points to and
from a resource’s execution environment.

R3 - Environment boundaries enforced: Explicitly defines and enforces the
boundaries of a resource’s execution environment. This objective aims to
prevent any interference between different resource environments, even in the
face of any fault or compromise.

###  5.2 Defense Approach Evaluation

####  5.2.1 Restrictions to resources

At a high level, such defenses regulate which resources can interact with
which parts of their operating environment. This goal is commonly achieved by
enforcing the _least privilege_ [116] property. That is, these approaches
limit the authority or permissions a given resource has to perform specific
operations, such as accessing local files, communicating over a network, or
calling certain functions.

_Discretionary Access Control (DAC)_ relies on the notion of ownership of
artifacts to determine which operations a resource is allowed to perform on
them [116]. In other words, DAC mechanisms (e.g., Linux file permissions
[140]) restrict access by resources based on the identity of their owner and
the access permissions the owners of target artifacts or resources have
granted other users (R1). A typical usage of DAC in software supply chain
resources is in container and VM images used for CI/CD operations [60, 62],
which provide software developers and maintainers with a legacy, highly
customizable operating environment.

_Mandatory Access Control (MAC)_ enforces a non-discretionary, global access
policy which enforces multiple levels of security for operations resources
perform [116]. As such, MAC can be used to meet objective (R1) as a
compromised resource can be prevented from performing an unauthorized
operation by default.

One way these defenses may help reduce software supply chain risk is by
running a kernel-level MAC system like AppArmor [1] or SELinux [17] to control
which operations (e.g., read(), mount()) a CI/CD or build resources may
perform on artifacts [39].

Other access control approaches. For brevity, we focus on the two main models
that meet resource security objectives. Specific access control strategies
mostly vary by granularity and types of policy rules, but they may be used to
enforce DAC or MAC models. Examples include Role-Based Access Control (RBAC)
[53], Attribute Based Access Control (ABAC) [19], and History-Based Access
Control [51].

####  5.2.2 Limiting compromises in execution environments

Defenses in this category aim to limit external access out of or into an
execution environment, or completely prevent interactions altogether.

_Filtering_ techniques intercept accesses at a particular environment
interface controlling the level of interactions between internal and external
resources. At one end of the range, approaches such as the netfilter [142]
restricts the network connections that a resource like a CI/CD system may
establish with remote resources (R2) [39].

Defenses such as eBPF [49] provide programmable filtering of a variety of
kernel-level interfaces (e.g., network, system calls), which also enables
enforcement of MAC policies for specific resources running on a system (R1,
R2).333While eBPF [49] executes within an isolated environment within the
kernel, we do not consider this sufficient to meet R3 because boundaries are
only enforced around the defense mechanism itself. One example usage of eBPF
in the software supply chain is for monitoring compiler execution during
builds according to a security policy [74].

Virtualization creates an abstract execution environment in which resources
share common underlying hardware and software components without needing to be
aware of other environments [50]. Software virtualization techniques establish
boundaries based on specific common properties or conditions shared by
resources that are typically enforced by privileged software (R3). For
example, Linux namespaces [13] and cgroups [5] are used to implement container
environments, in which the kernel enforces boundaries between named groups of
processes based on hardware resource access constraints, while sharing the
same underlying kernel resources.Hardware virtualization approaches (e.g.,
[137, 20]), on the other hand, are designed to enforce strong boundaries and
controlled I/O interfaces using dedicated CPU features (R2, R3). Virtual
machines are very commonly used in the software supply chain to implement
strongly isolated execution environments for resources such as CI/CD runners
[65, 60].

###  5.3 Discussion

As with prior supply chain elements, defense approaches for resources are
complementary. Yet, unlike other areas of the software supply chain, we argue
that the longstanding history of security research on computer systems has led
to better compatibility between the evaluated approaches.

For instance, access control mechanisms are capable of operating at various
levels of granularity depending on a resource’s operating environment. While
implementations such as AppArmor [1] provide application-level MAC, DAC can
provide system-level defenses. At the same time, filtering mechanisms such as
netfilter [142] can provide system-level protection in addition to DAC and MAC
within the system. Virtualization then provides an additional level of
isolation on top of access control and filtering.

We observe that resource defense approaches more commonly appear in industry
security best practices documents that have been authored in response to
recent supply chain compromises. Most notably, the Cloud Native Compute
Foundation’s Software Supply Chain Best Practices [39] and the Secure Software
Development Framework (SSDF) by NIST [125] both describe a set of
recommendations for configuring and implementing more secure software supply
chain resources that rely on defense approaches including MAC, filtering and
virtualization. The Supply-chain Levels for Software Artifacts (SLSA) [124],
which provides a framework for incrementally implementing a hardened build
pipeline, also includes requirements for resource isolation to ensure that
build steps are performed without any external influence to meet higher
security levels.

Research gaps. Academic research analyzing the security of software supply
chain resources thus far taken primarily an attack-oriented view (e.g., [76,
47]). While the design and application of access control and resource
isolation techniques have been widely studied in the academic systems
community, research dedicated to applying these defense mechanisms in context
of software supply chain security is still uncommon; we see ample
opportunities to build upon defense-oriented academic studies such as Gruhn
_et al._ [65] and Ohm  _et al._ [104].

For brevity, we do not extensively evaluate resource defense approaches such
as bounds checking (e.g., [139]), or more recent hardware-based techniques
such as trusted execution environments (e.g., [90, 25, 72, 22]). Yet, we
observe in existing best practices guides that such approaches are under-
explored in supply chain settings.

The focus on reducing risks to build and packaging resources [65, 104, 124]
leaves an opportunity for future research to explore existing and novel
approaches for other software supply chain use cases. Further research is also
needed around the adoption of industry best practices.

##  6 Defending Steps

Steps represent software development actions or operations that principals
carry out on artifacts with the help of resources. Generally, step risks
depend on whether risks to the principals, resources and artifacts involved in
a particular step have been addressed. For example, compromise of a principal
who is authorized to carry out a step leads to a compromised step.

Yet, even with reduced risks to principals, artifacts and resources, steps may
still face risks related to the invocation or operation of the step.

###  6.1 Step Security Objectives

S1 - Expected step behavior enforced: The expected step behavior is well-
defined and cannot be altered once triggered. Ensuring correct step behavior
may also be achieved by the correctness of the underlying resource(s) used to
carry out a step.

S2 - Step operation recorded: The identities of involved principals, artifacts
used and produced, and resources used, are recorded. Further, a step provides
faithful information about its operation.

S3 - Interference with step detected: Detects attempts to tamper with or
otherwise interfere with the expected behavior of a step. Detecting attempts
to present different versions of the same step to different principals provide
the stronger global non-equivocation property.

###  6.2 Defense Approach Evaluation

Several mechanisms exist to reduce risks to carrying out steps. While most of
the approaches we evaluate target build and packaging steps, their design
principles and properties can be applied to other steps in the software supply
chain. These mechanisms fall within two major categories: Preventative and
detection approaches.

###  6.3 Limiting step risk through resources

Preventative approaches aim to ensure the correct behavior of a step from
within, proactively reducing risks to steps through careful choice or
configuration of the underlying _resources_ used to carry out a step.

_Formal verification_ mechanisms leverage mathematical principles, such as
discrete logic, to check whether an algorithm or design meet specific
properties or behavior. Typically, this approach may be used to reduce risks
to steps by checking the behavioral correctness of the resources used to carry
out a step (S1).

One instance is CompCert [86], a functionally verified optimizing C compiler.
The use of verifiable and formal languages also fall within this category.
Work such as Rustan and Leino’s dafny [85], for example, enable software
developers to validate the behavioral correctness of the programs they write
at the source development step.

_Deterministic steps_ follow configuration patterns that prevent sources of
entropy from influencing the behavior or outcome of a step (S1). For instance,
Courtès  _et al._ [40], describes how GUIX ensures correctness by using
source-to-binary mapping.

Navarro-Leija et al. proposed DetTrace [97], a reproducible container
abstraction that enables reproducible software builds, among other use cases.
To this end, DetTrace controls the influence of a system’s behavior, such as
naturally noisy system calls (e.g., clock_gettime) that would introduce
nondeterminism into a step (S1).

“This works well for large companies with leverage (e.g. forcing third-party
developers to use analysis tools, specific languages, specific compiler flags,
and other elements). Mandates can also come from management within a company
(e.g., forcing all developers to run a static analysis tool). Clients, system
vendors, and others can also mandate the use of security tools.”

###  6.4 Enabling step risk detection

Techniques that facilitate detection of compromises, while being less
proactive, enable relying parties to evaluate and make decisions about the
risk of a step after-the-fact.

_Step transparency_ provides information about any aspect of a step’s
operation to provide visibility into all aspects of a step (S2). An
increasingly prominent type of step metadata are Software Bills of Materials
[128] for their use in software supply chain compliance [146]. Their main
goal, while not authenticated, is to convey information about artifact
composition, software “pedigree”, and quality, complementing other step
operational metadata such as SLSA Provenance [124].

One of the earliest proposals to capture step operational metadata was in-toto
[134] via a primitive referred to as Links. in-toto Links are _authenticated_
documents describing the input and output artifacts to a step, the command
executed during a step, and any step byproducts such as return value or error
messages. Using principal and artifact defense mechanisms allows in-toto to
also detect tampering with any aspect of the step (S3).

_Step consensus_ relies on the repeatability and/or visibility of a step to
enable multiple parties to determine jointly if a step has been tampered with
(S3). That is, if different parties obtain different metadata or results for a
given step, then the step is assumed to have been tampered with.

Approaches such as the IETF Supply Chain Integrity Transparency and Trust
(SCITT [32]) framework and Ferraiuolo  _et al._ [54] provide global (S2) and
(S3) properties using mechanisms like distributed ledgers and transparency
logs to expose policy decisions as part of the metadata recording and
publication process. Bandara  _et al._ [30] propose a similar mechanism based
on a blockchain as a backend data store to provide a globally-visible
representation of the state of the software supply chain.

Nikitin  _et al._ proposed CHAINIAC [6], for instance, provides strong tamper-
detection guarantees for software updates through a novel data structure
called a skipchain (i.e., the merging of a skiplist and a blockchain).
CHAINIAC detects step tampering in two stages. First, a group of build
services re-runs a particular build step. Then, they validate the resulting
binary, and only commit it into the skipchain if the builders reach consensus
over the binary.

As CHAINIAC skipchains contain a cryptographically verifiable log of all
released binaries, the approach also helps different parties ensure that they
all have the same view of the software updates over time (the stronger non-
equivocation property of S3). Similar approaches were proposed by Hof  _et
al._ [66] and Linderud [87].

###  6.5 Discussion

The majority of step defenses developed and studied thus far has focused on
mechanisms for recording step metadata to detect tampering. Xia  _et al._
[144], for instance, conducted a study that focuses on current SBOM practices,
tooling and concerns from SBOM practitioners’ perspectives. The study shows
lack of SBOM adoption and problems in enabling SBOMs benefits, due to various
concerns regarding SBOM generation, distribution, consumption processes.

Given these concerns, the study suggests three prerequisites to increase SBOM
adoption and SBOM enabled benefits: higher quality SBOM generation, clearer
benefits and use cases in SBOM consumption, and lower barriers in SBOM
sharing.

Research gaps. In both academic and gray literature, we observe a general lack
of studies on preventing or reducing risks that affect the correct execution
or operation of software supply chain steps. Formal verification, for
instance, has been widely explored by the programming language and software
engineering communities, though, its application in the context of the
software supply chain remains under-explored. Furthermore, the adoption of
formally verifiable systems as resources for steps presents an opportunity for
further research.

While the design of consensus-based step defense mechanisms has been the focus
of an increasing number of academic studies, their practical applicability and
adoption costs remain relatively under-explored. Similarly, the design,
development and adoption of step containment approaches at large, is an area
that warrants further study.

##  7 Defending Supply Chain Topology

While the previous sections cover risks and defenses for individual elements
in a software supply chain graph, these defenses most often do not capture the
federated and transitive properties inherent _across_ a series of
interdependent steps. These effects may become more pronounced depending on
the number of organizations and principals involved in carrying out these
steps using a multitude of resources which may not always be cross-compatible.
The left-pad incident is a good example of the transitivity of the software
supply chain risk, such that unpublishing the package, and removing it from
the topology, broke the build steps that use it as a dependency, which broke
many topologies that uses this step.

Since attacks that modify a supply chain topology at large impact downstream
steps and artifacts, we separately evaluate risks and defenses that affect a
topology in order to reason about transitive software supply chain risk.

###  7.1 Topology Security Objectives

Software supply chain topology defenses usually focus on providing improved
integrity to identify and detect topology changes, ensuring that a set of
_steps_ executed in a specific order perform consistently, or remediating
changes to improve reliability of a software supply chain.

Thus, defenses can meet the following security objectives:

T1 - Topology changes detected: Provides a mechanism for detecting changes to
the expected structure of the software supply chain graph, i.e., additions,
removals or reordering of individual supply chain elements. This property
validates the integrity of parts or whole software supply chains, essentially
detecting modified or compromised edges between two elements in the graph.

T2 - No single point of failure: Reduces the risks of failure in a software
supply chain due to a missing step or resource. This is achieved through
_redundancy_ mechanisms [45, 28].

T3 - Attack propagation prevented: Limits the risks to a particular step,
resource or principal by blocking or avoiding an interaction or transitive
relationship between two vertices in a software supply chain graph.

T4 - Topology non-equivocation: All principals have the same view of the
topology at a given point in time, this includes the set and order of steps in
the topology.

T5 - Consistent results: Provides a process for ensuring or checking that a
set of the steps performed on given artifacts in a specific order always
produces consistent artifacts. This property reflects the correctness of an
entire supply chain graph topology. This property is stricter than T4, we
consider an exact match in final artifacts to be the strongest form of
consistency for the sake of this evaluation.

###  7.2 Defense Approach Evaluation

Reducing risk over an entire topology requires knowledge about parts or all of
the steps and resources in a software supply chain. Thus, to enable defenses
for validation and detection of tampering or other topology changes, we assume
mechanisms are in place to establish a good-known topology configurations a
priori. Similarly, for defenses that improve the reliability of a software
supply chain to prevent attacks made possible through topology changes, these
defenses typically rely on a mechanism for detecting problematic
configurations, and recovering from these dynamically.

_Supply chain layout integrity_ enables principals to detect whether all steps
in a software supply chain were performed in the expected order (T4), whether
they were carried out by the expected principals, and whether expected
artifacts were modified between steps. This approach first formally introduced
in Torres Arias  _et al._ [134] reduces the risks of added, removed, or
reordered steps (T1).

Using a primitive called layouts, in-toto [134] implements this approach by
requiring project owners or maintainers (a principal role) to pre-define the
set of steps to be performed, the principals authorized to perform each step,
and the expected consumed and produced materials for each step, a priori.
Given an in-toto layout document authenticated by the expected project owner,
and step metadata is available (see §6), interested principals are able to
validate that a given artifact was produced following the expected in-toto
layout.

_Resource replication_ addresses risks in a step caused by a single point of
failure such as a removed or problematic resource that the particular step in
the software supply chain graph depends on. For instance, in the Debian or
Ubuntu package ecosystem, principals may configure their dependency fetching
steps to use “mirrors” [2], which replicate and regularly synchronize with a
central package registry to provide a fallback mechanism in case that a chosen
package registry becomes unavailable or otherwise inaccessible (T2). In the
case of left-pad incident , this technique could have helped the impacted
builds to succeed.

_Dependency reduction_ is a defense technique that intentionally modifies a
supply chain DAG itself in order to block or avoid transitive relationships
between two vertices, such as principals, resources and steps. One solution
specifically developed to address compromises in artifacts that are built
using a compiler (i.e., a resource) such as GCC is Bootstrappable builds [41,
3]. The key idea behind Bootstrappable builds is that the smaller the so-
called “seed” compiler is for a project, the lower the risks of compromise are
for the project since a seed can be individually inspected, increasing the
transparency of the dependencies. Reducing a resource dependency to a seed
ultimately limits the transitive relationships between a step and a resource
(T3).

_Supply chain reproducibility_ is broadly a mechanism for detecting whether a
particular sequence of steps in a software supply chain always produces the
same results. In practice, reproducibility relies on the chaining of
techniques for individual steps like deterministic builds (discussed in §6),
which ensure that a particular step, such as build, always produces the same
result (T5). By enabling downstream principals to repeat a sequence of
upstream steps, upstream producers enable their consumers to validate the
integrity of a software supply chain for their product artifact. This
guarantees that all principals have the same view of the set and order of
steps and of the topology (T4).

###  7.3 Discussion

Drawing further from systems research on redundancy, we observe that while
some mechanisms for replication are applicable in the software supply chain,
the stronger property of _fault tolerance_ , in which a system may tolerate or
even recover from unexpected changes such as modifications to the supply chain
DAG topology [45, 28] remain unexplored. One possible means to achieving this
property may be by substituting an individual compromised or faulty software
supply chain element with an equivalent element before re-attempting to
execute a given step, though further research and engineering are necessary to
better understand the impact of such fault recovery mechanisms to the
security, usability, and performance of a software supply chain.

Research gaps. while data-based approaches have been used to model risks in
the software supply chain, there has been no studies on best software supply
chain practices using topological data. Using topology information from
different data sources, it is possible to shed light on the correlation
between different supply chain practices and their security outcomes to
provide empirical models to harden the software ecosystem. Similarly,
interventions and human-aspects research to understand the way that software
supply chains are topologically configured (beyond package dependency
networks) will aid in understanding how individual structural risks surface.
This will allow to introduce stronger, data informed levels of replication and
reduction (T2-3), as well as define ideal topologies that are based on
empirical data (T1). Further, mechanisms to provide a transparent, tight
binding between policies and their evaluation will allow for stronger insights
on the security posture of an artifact in context (T4). Lastly, the use and
exploration of software reproducibility is widely explored in practice but
overlooked in academia. This includes work developing _tools and systems_ that
increase, leverage, or generate insights reproducibility, as well as human-
centered studies on the day-to-day challenges in achieving and maintaining
step reproducibility to pave the way to a more stable software supply chain
topology (T5).

##  8 Model Evaluation

Figure 2: The supply chain DAG of left-pad, the commit step can occur multiple
times before tagging the repo, and all the steps in figure occur for each
release. Figure 3: The supply chain DAG of SolarWinds build system.

To explore the utility of the AStRA model for software supply chain security
assessment, we need to ensure two properties: generality and completeness. We
define generality as the ability of the model to represent any software supply
chain. This property is important because missing or misrepresenting a
particular supply chain topology may lead to security gaps. Completeness
extends the concept of generality and is defined as the ability to capture
every _threat_ for every supply chain modeled. Without this property,
assessing supply chain risks, and thereby their mitigation, becomes difficult.

While the case studies enable us to examine specific characteristics of our
model, we also seek to validate whether our security objectives
comprehensively cover a larger dataset of attacks and attack classes (§8.3).

###  8.1 Generality

We evaluate the generality of our model by via two case studies of software
supply chain architectures that have been widely studied in both scientific
and grey literature: SolarWinds [55] and npm usage [9].

Left-pad we determined the supply chain for left-pad by analyzing its source
code repository [10]. Succinctly put, left-pad is a linear source code
repository that, when the main developer deems appropriate, uses git tags to
mark the release of a version. No automated pipeline is used to release, which
suggests that the developer uses a script (i.e., [14] to upload the
corresponding version to NPM. This same principal is in charge of pushing the
resulting binary to a registry for consumers to download. Figure 2 depicts
this process as an AStRA graph.

SolarWinds supply chain uses a combination of hosted services (e.g., GitHub)
as well as self-hosted tools and infrastructure (e.g., Tekton) to provide a
container build pipeline. Of particular interest is the use of different
principals to report dependencies as a separate step. This is done this way
because the automated pipeline pre-fetches the sources and installs it on the
build infrastructure at the time of build. One possible reason for this is
that developers need clearance and oversight when selecting third-party
components. Separately, developers build their own source code and host it in
a social coding platform, which is then tagged and released for a build by the
Tekton pipeline manager. This same principal is in charge of pushing the
resulting binary to a registry for consumers to download. Figure 3 depicts
this process as an AStRA graph.

###  8.2 Completeness

To evaluate this property, and given that we have proved the generality of our
model, we will use it to analyze widely-known supply chain attacks on both
SolarWinds and left-pad supply chains. We show how each compromise
materializes within an AStRA model.

Left-Pad was un-published by its author, as part of a dispute over a package
name with the administrators of the npm package manager [118]. Since this was
done without warning the developers of projects that depended on it, this
impacted many thousands of projects and npm observed hundreds of build
failures per minute for dependent projects and their dependents, and so on
[118]. Based on our conceptual model, the artifact removal imposes a
topological risk on all the software supply chain topologies that used left-
pad as direct or transitive dependency. This topology risk can be reduced
using resource replication techniques to prevent a dependency from being
single point of failure in build steps (T2).

SolarWinds In 2019, a sophisticated adversary used the SolarWinds Orion
platform to plant stealthy backdoors in the networks of thousands of US
government agencies and companies around the world [18, 112]. While
“SolarWinds” is used to refer to a single compromise, it was a campaign with
multiple stages. The attackers injected malicious code known as Sunburst (aka
Solorigate) into Orion during the build process. The report describes
credential reuse on principals carrying out the build process. In this case,
the nodes affected in Figure 3 were the CI/CD controller principals.

Further, network structure properties may improve the analysis of assets and
elements involved in a supply chain. For example, identifying principals with
high out-degree would suggest an excess of privilege (and thus a higher
compromise surface). Similar analysis on out-degree can be used to indicate
artifact, resource or even step criticality.

###  8.3 Large-Scale Analysis

We perform a comparative analysis of the AStRA model objectives and 72 attacks
listed in the IQT Labs dataset [121] used in the Ladisa  _et al._ SoK [79]. To
explicitly map each desired security objective to mitigated attack classes, we
include the attack vectors from the Ladisa taxonomy. We only included attacks
with valid references, that has enough published details to understand the
compromised supply chains.Due to space reasons, we have made the full table
with our analysis available
online.444https://docs.google.com/spreadsheets/d/e/2PACX-1vSWUhYy-
lpEsFFg8ZK3Gb5buHIhcjx1fEamJ2B6Jf6cAJJmdOOl9HYy-c60nSt7TdZgWmxjRnm7DwrN/pubhtml

##  9 Future Research Opportunities

The AStRA model allows us to evaluate different security mechanisms in the
context of software supply chain defenses to reveal future research
opportunities (towards RQ4).

Reducing Barriers to Adoption. Originally, we intended to evaluate the
tradeoffs and costs to adopt mechanisms for software supply chain security.
Unfortunately, we found there are very little literature and formal studies on
how to deploy a particular approach. These studies should cover human factors
(e.g., training), usability, and system requirements (e.g., extra servers).
Thus, we envision that a green field for research is that of Usable software
supply chain security.

Moving Beyond Modeling Threats. Our objective-driven model is a first step
towards systematically mapping threats to defenses. We see an opportunity to
expand upon our work to design novel adoption-ready software supply chain
defenses. Beyond our preliminary work, we envision future research that
incorporates holistic cost-benefit analysis frameworks for supply chain risk
mitigation with the goal of increasing adoption of supply chain defenses.

Understanding the Impact & Security of AI-Generated Software. Generative AI is
playing an increasingly central role in software development. According to a
recent survey [122], about 92% of developers in the U.S. rely on AI-based
tools. This rapid shift presents ample future research opportunities to study
the security implications of AI-generated code and address software and supply
chain security in this emerging space.

## References

  * [1] AppArmor.  https://wiki.ubuntu.com/AppArmor, retrieved Nov. 2023.
  * [2] apt-mirror.  URL: https://apt-mirror.github.io/.
  * [3] Bootstrappable builds.  URL: https://bootstrappable.org/.
  * [4] Certificate Transparency Version.  https://certificate.transparency.dev/, retrieved Apr. 2023.
  * [5] cgroups - Linux control groups.  https://man7.org/linux/man-pages/man7/cgroups.7.html, retrieved Oct. 2023.
  * [6] CHAINIAC: Proactive software-update transparency via collectively signed skipchains and verified builds.
  * [7] in-toto attestation framework.  original-date: 2021-04-01T14:58:27Z.  URL: https://github.com/in-toto/attestation.
  * [8] in-toto/attestation-verifier.  original-date: 2023-05-16T15:46:04Z.  URL: https://github.com/in-toto/attestation-verifier.
  * [9] left-pad.  URL: https://www.npmjs.com/package/left-pad.
  * [10] left-pad/left-pad.  original-date: 2014-03-14T09:09:34Z.  URL: https://github.com/left-pad/left-pad.
  * [11] [meta] Binary Transparency on Firefox.  https://bugzilla.mozilla.org/show_bug.cgi?id=1341395.
  * [12] Mitigating log4shell and other log4j-related vulnerabilities | CISA.  URL: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a.
  * [13] namespaces - overview of Linux namespaces.  https://man7.org/linux/man-pages/man7/namespaces.7.html, retrieved Oct. 2023.
  * [14] Npm docs: npm publish.  URL: https://docs.npmjs.com/cli/v6/commands/npm-publish.
  * [15] OpenID connect | OpenID.  URL: https://openid.net/connect/.
  * [16] PGP signatures on PyPI: worse than useless.  URL: https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI-worse-than-useless.
  * [17] SELinux Project Wiki.  https://selinuxproject.org/page/Main_Page, retrieved Nov. 2023.
  * [18] SolarWinds hack was ’largest and most sophisticated attack’ ever: Microsoft president.  URL: https://www.reuters.com/article/us-cyber-solarwinds-microsoft-idUSKBN2AF03R.
  * [19] Attribute-Based Access Control.  Artech House, 2017.
  * [20] Advanced Micro Devices Inc.  AMD64 Architecture Programmer’s Manual Volume 2: System Programming.  https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf, retrieved Dec. 2023, Jun 2023.
  * [21] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato.  Internet x.509 public key infrastructure time-stamp protocol (tsp).  URL: https://www.ietf.org/rfc/rfc3161.txt.
  * [22] Advanced Micro Devices, Inc.  AMD Secure Encrypted Virtualization (SEV).  https://developer.amd.com/sev/.
  * [23] Hammad Afzali, Santiago Torres-Arias, Reza Curtmola, and Justin Cappos.  Le-git-imate: Towards verifiable web-based git repositories.  In Proceedings of the 2018 on Asia Conference on Computer and Communications Security, ASIACCS ’18, page 469–482, New York, NY, USA, 2018. Association for Computing Machinery.  doi:10.1145/3196494.3196523.
  * [24] Mustafa Al-Bassam and Sarah Meiklejohn.  Contour: A practical system for binary transparency.  URL: http://arxiv.org/abs/1712.08427, arXiv:1712.08427[cs].
  * [25] Tiago Alves.  Trustzone: Integrated hardware and software security.  Information Quarterly, 3:18–24, 2004.
  * [26] Anchore.  Anchore 2022 Software Supply Chain Security Report, 2022.  URL: https://anchore.com/software-supply-chain-security-report-2022/.
  * [27] Apache Software Foundation.  Cve-2021-44832.  https://nvd.nist.gov/vuln/detail/CVE-2021-44832, retrieved Jul. 2022.
  * [28] A. Aviziens.  Fault-tolerant systems.  IEEE Transactions on Computers, 25(12), dec 1976.  doi:10.1109/TC.1976.1674598.
  * [29] Hayden B, John Speed Meyers, and Nathan Smith.  Security Model.  https://github.com/sigstore/fulcio/blob/main/docs/security-model.md, retrieved Apr. 2023.
  * [30] Eranga Bandara, Sachin Shetty, Abdul Rahman, and Ravi Mukkamala.  Let’sTrace — blockchain, federated learning and TUF/in-ToTo enabled cyber supply chain provenance platform.  In MILCOM 2021 - 2021 IEEE Military Communications Conference (MILCOM), pages 470–476.  ISSN: 2155-7586.  URL: https://ieeexplore.ieee.org/document/9653024, doi:10.1109/MILCOM52596.2021.9653024.
  * [31] Bandit Developers.  Bandit.  https://bandit.readthedocs.io/en/latest/, retrieved Dec. 2023.
  * [32] H. Birkholz, A. Delignat-Lavaud, C. Fournet, and Y. Deshpande.  An Architecture for Trustworthy and Transparent Digital Supply Chains.  IETF Data Tracker, Oct 2022.  URL: https://datatracker.ietf.org/doc/draft-birkholz-scitt-architecture/.
  * [33] Justin Cappos, Justin Samuel, Scott Baker, and John H. Hartman.  A look in the mirror: attacks on package managers.  In Proceedings of the 15th ACM conference on Computer and communications security - CCS ’08, page 565. ACM Press.  URL: http://portal.acm.org/citation.cfm?doid=1455770.1455841, doi:10.1145/1455770.1455841.
  * [34] Melissa Chase, Apoorvaa Deshpande, Esha Ghosh, and Harjasleen Malvai.  SEEMless: Secure End-to-End Encrypted Messaging with Less Trust.  In Proc. of ACM CCS ’19, 2019.  doi:10.1145/3319535.3363202.
  * [35] Mauro Cherubini, Alexandre Meylan, Bertil Chapuis, Mathias Humbert, Igor Bilogrevic, and Kévin Huguenin.  Towards usable checksums: Automating the integrity verification of web downloads for the masses.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1256–1271, 2018.
  * [36] Mauro Cherubini, Alexandre Meylan, Bertil Chapuis, Mathias Humbert, Igor Bilogrevic, and Kévin Huguenin.  Towards usable checksums: Automating the integrity verification of web downloads for the masses.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1256–1271. ACM.  URL: https://dl.acm.org/doi/10.1145/3243734.3243746, doi:10.1145/3243734.3243746.
  * [37] Jim Chow, Tal Garfinkel, and Peter M Chen.  Decoupling dynamic program analysis from execution in virtual environments.  In 2008 USENIX Annual Technical Conference (USENIX ATC 08), 2008.
  * [38] Cloudflare, Inc.  What is a session key?  https://www.cloudflare.com/learning/ssl/what-is-a-session-key, retrieved Apr. 2023.
  * [39] CNCF Security TAG.  Software Supply Chain Best Practices.  https://project.linuxfoundation.org/hubfs/CNCF_SSCP_v1.pdf, retrieved Apr. 2023.
  * [40] Ludovic Courtès.  Functional package management with guix.  arXiv preprint arXiv:1305.4584, 2013.
  * [41] Ludovic Courtès.  Building a secure software supply chain with gnu guix.  arXiv preprint arXiv:2206.14606, 2022.
  * [42] V. Craciun, P. A. Felber, A. Mogage, E. Onica, and R. Pires.  Malware in the SGX supply chain: Be careful when signing enclaves!  IEEE Transactions on Dependable and Secure Computing, pages 1–1, 2020.  doi:10.1109/TDSC.2020.3024562.
  * [43] Debian.  SecureApt.  https://wiki.debian.org/SecureApt, retrieved Dec. 2023.
  * [44] Hayley Denbraver.  Malicious packages found to be typo-squatting in Python Package Index.  SynkBlog, Dec 2019.  URL: https://snyk.io/blog/malicious-packages-found-to-be-typo-squatting-in-pypi/.
  * [45] Peter J. Denning.  Fault tolerant operating systems.  ACM Comput. Surv., 8(4):359–389, dec 1976.  doi:10.1145/356678.356680.
  * [46] Alexandra Dmitrienko, Christopher Liebchen, Christian Rossow, and Ahmad-Reza Sadeghi.  On the (in)security of mobile two-factor authentication.  volume 8437, pages 365–383, 03 2014.  doi:10.1007/978-3-662-45472-5_24.
  * [47] Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, and Wenke Lee.  Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages, 2020.  arXiv:2002.01139.
  * [48] Duo.  Duo mobile application: Secure access from your smartphone.  https://duo.com/product/multi-factor-authentication-mfa/duo-mobile-app, retrieved Apr. 2023.
  * [49] eBPF.io Authors.  What is eBPF?  https://ebpf.io/what-is-ebpf/, retrieved Dec. 2023, 2023.
  * [50] CSRC Content Editor.  Isolation - glossary | CSRC.  URL: https://csrc.nist.gov/glossary/term/isolation.
  * [51] Guy Edjlali, Anurag Acharya, and Vipin Chaudhary.  History-based access control for mobile code.  In Jan Vitek and Christian D. Jensen, editors, Secure Internet Programming: Security Issues for Mobile and Distributed Objects, Lecture Notes in Computer Science, pages 413–431. Springer.  doi:10.1007/3-540-48749-2_19.
  * [52] Mohamed Hamdy Eldefrawy, Muhammad Khurram Khan, Khaled Alghathbar, Tai-Hoon Kim, and Hassan Elkamchouchi.  Mobile one-time passwords: two-factor authentication using mobile phones.  Security and Communication Networks, 5(5):508–516, 2012.  URL: https://onlinelibrary.wiley.com/doi/abs/10.1002/sec.340, arXiv:https://onlinelibrary.wiley.com/doi/pdf/10.1002/sec.340, doi:10.1002/sec.340.
  * [53] D. Ferraiolo and R. Kuhn.  Role-based access controls.  In Proc. 15th National Computer Security Conference, Oct. 1992.
  * [54] Andrew Ferraiuolo, Razieh Behjati, Tiziano Santoro, and Ben Laurie.  Policy transparency: Authorization logic meets general transparency to prove software supply chain integrity.  In Proceedings of the 2022 ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, pages 3–13. ACM.  URL: https://dl.acm.org/doi/10.1145/3560835.3564549, doi:10.1145/3560835.3564549.
  * [55] FireEye.  Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor.  FireEye Blogs - Threat Research, Dec 2020.  URL: https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html.
  * [56] Apache Foundation.  Working with gpg.  https://central.sonatype.org/publish/requirements/gpg/.
  * [57] Git.  Git Basics - Viewing the Commit History.  https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History, retrieved Dec. 2023.
  * [58] Git SCM.  Signing your work.  https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work.
  * [59] GitHub, Inc.  Automate your workflow from idea to production.  URL: https://github.com/features/actions.
  * [60] GitHub, Inc.  Supported runners and hardware resources.  https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources, retrieved Nov. 2023.
  * [61] GitHub, Inc.  Repository roles for an organization, Oct 2022.  URL: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization.
  * [62] GitLab B.V.  Saas runners on linux.  https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html, retrieved Nov. 2023.
  * [63] Dan Goodin.  Hackers backdoor PHP source code after breaching internal git server.  Ars Technica, Mar 2021.  URL: https://arstechnica.com/gadgets/2021/03/hackers-backdoor-php-source-code-after-breaching-internal-git-server/.
  * [64] Google.  Delivering software securely - Industry-wide standards and frameworks.  https://cloud.google.com/resources/delivering-software-securely#section-3, retrieved Apr. 2023.
  * [65] Volker Gruhn, Christoph Hannebauer, and Christian John.  Security of public continuous integration services.  In Proceedings of the 9th International Symposium on Open Collaboration, WikiSym ’13, New York, NY, USA, 2013. Association for Computing Machinery.  doi:10.1145/2491055.2491070.
  * [66] Benjamin Hof and Georg Carle.  Software distribution transparency and auditability.  arXiv preprint arXiv:1711.07278, 2017.
  * [67] Yuncong Hu, Kian Hooshmand, Harika Kalidhindi, Seung Yang, and Raluca Popa.  Merkle2 : A low-latency transparency log system.  In Proc. IEEE Security & Privacy Symposium, pages 285–303, May 2021.  doi:10.1109/SP40001.2021.00088.
  * [68] Alex Ilgayev.  How We Discovered Vulnerabilities in CI/CD Pipelines of Popular Open-Source Projects.  Cycode Blog, Mar 2022.  URL: https://cycode.com/blog/github-actions-vulnerabilities/.
  * [69] in-toto Authors.  in-toto - A framework to secure the integrity of software supply chains.  https://in-toto.io/.
  * [70] Docker inc.  Docker Content Trust .  https://docs.docker.com/engine/security/trust/.
  * [71] GitHub Inc.  About commit signature verificaton.  https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification.
  * [72] Intel Corporation.  Intel® Trust Domain Extensions (Intel® TDX).  https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html.
  * [73] ISO/IEC 27034-1:2011 Information technology — Security techniques — Application security — Part 1: Overview and concepts.  Standard, International Organization for Standardization, International Electrotechnical Commission, Nov 2011.
  * [74] Cole Kennedy.  Verifiable eBPF Traces for Supply Chain Artifacts with Witness and Tetragon.  https://cloudnativesecurityconna22.sched.com/event/1AOie, retrieved Dec. 2023, Oct 2022.
  * [75] Igibek Koishybayev, Aleksandr Nahapetyan, Raima Zachariah, Siddharth Muralee, Bradley Reaves, Alexandros Kapravelos, and Aravind Machiry.  Characterizing the Security of Github CI Workflows.  In Proc. USENIX Security ’22, Aug 2022.
  * [76] Igibek Koishybayev, Aleksandr Nahapetyan, Raima Zachariah, Siddharth Muralee, Bradley Reaves, Alexandros Kapravelos, and Aravind Machiry.  Characterizing the security of github $\\{$CI$\\}$ workflows.  In 31st USENIX Security Symposium (USENIX Security 22), pages 2747–2763, 2022.
  * [77] Daniel Krohmer, Kunal Sharma, and Shi Chen.  Adapting Static Taint Analyzers to Software Marketplaces: A Leverage Point for Mass Vulnerability Detection?  In Proc. ACM SCORED ’22, Nov 2022.
  * [78] Trishank Karthik Kuppusamy, Santiago Torres-Arias, Vladimir Diaz, and Justin Cappos.  Diplomat: Using delegations to protect community repositories.  In 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), pages 567–581, 2016.
  * [79] Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais.  Sok: Taxonomy of attacks on open-source software supply chains.  In 2023 IEEE Symposium on Security and Privacy (SP), pages 1509–1526, 2023.  doi:10.1109/SP46215.2023.10179304.
  * [80] Piergiorgio Ladisa, Henrik Plate, Matias Martinez, Olivier Barais, and Serena Elisa Ponta.  Towards the Detection of Malicious Java Packages.  In Proc. ACM SCORED ’22, Nov 2022.
  * [81] Chris Lamb and Stefano Zacchiroli.  Reproducible builds: Increasing the integrity of software supply chains.  39(2):62–70.  doi:10.1109/MS.2021.3073045.
  * [82] Leslie Lamport.  Password authentication with insecure communication.  Commun. ACM, 24(11):770–772, nov 1981.  doi:10.1145/358790.358797.
  * [83] Ben Laurie and Emilia Kasper.  Revocation Transparency.  http://www.links.org/files/RevocationTransparency.pdf, retrieved Nov. 2023, Sep. 2012.
  * [84] Ben Laurie, E. Messeri, and R. Stradling.  RFC 9162 - Certificate Transparency Version 2.0.  https://datatracker.ietf.org/doc/rfc9162/, retrieved Apr. 2023.
  * [85] K Rustan M Leino.  Dafny: An automatic program verifier for functional correctness.  In International conference on logic for programming artificial intelligence and reasoning, pages 348–370. Springer, 2010.
  * [86] Xavier Leroy.  Formal verification of a realistic compiler.  Communications of the ACM, 2009.
  * [87] Morten Linderud.  Reproducible builds: Break a log, good things come in trees.  Master’s thesis, The University of Bergen, 2019.
  * [88] Linux Foundation.  Fulcio.  https://docs.sigstore.dev/fulcio/overview/, retrieved Apr. 2023.
  * [89] Alexander Floyd Marshall.  Announcing the Secure Software Factory Reference Architecture Paper.  Cloud Native Compute Foundation Blog, May 2022.  URL: https://www.cncf.io/blog/2022/05/20/announcing-the-secure-software-factory-reference-architecture-paper/.
  * [90] Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V. Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R. Savagaonkar.  Innovative Instructions and Software Model for Isolated Execution.  In Proc. Hardware and Architectural Support for Security and Privacy, 2013.
  * [91] Marcela S. Melara, Aaron Blankstein, Joseph Bonneau, Edward W. Felten, and Michael J. Freedman.  CONIKS: Bringing key transparency to end users.  In 24th USENIX Security Symposium (USENIX Security 15), pages 383–398, Washington, D.C., August 2015. USENIX Association.  URL: https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/melara.
  * [92] Marcela S. Melara and Santiago Torres-Arias.  A viewpoint on software supply chain security: Are we getting lost in translation?  IEEE Security & Privacy, 21(6):55–58, 2023.  doi:10.1109/MSEC.2023.3316568.
  * [93] Ralph C. Merkle.  A digital signature based on a conventional encryption function.  In Carl Pomerance, editor, Advances in Cryptology — CRYPTO ’87, pages 369–378, Berlin, Heidelberg, 1988. Springer Berlin Heidelberg.
  * [94] M. Narasimha, G. Tsudik, and Jeong Hyun Yi.  On the utility of distributed cryptography in p2p and manets: the case of membership control.  In 11th IEEE International Conference on Network Protocols, 2003. Proceedings., pages 336–345, 2003.  doi:10.1109/ICNP.2003.1249783.
  * [95] National Institute of Standards and Technology.  Ephemeral key.  https://csrc.nist.gov/glossary/term/ephemeral_key, retrieved Apr. 2023.
  * [96] National Institute of Standards and Technology.  Hash functions.  https://csrc.nist.gov/projects/hash-functions, retrieved Dec. 2023.
  * [97] Omar S. Navarro Leija, Kelly Shiptoski, Ryan G. Scott, Baojun Wang, Nicholas Renner, Ryan R. Newton, and Joseph Devietti.  Reproducible containers.  In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, pages 167–182. ACM.  URL: https://dl.acm.org/doi/10.1145/3373376.3378519, doi:10.1145/3373376.3378519.
  * [98] Zachary Newman, John Speed Meyers, and Santiago Torres-Arias.  Sigstore: Software signing for everybody.  In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 2353–2367. ACM.  URL: https://dl.acm.org/doi/10.1145/3548606.3560596, doi:10.1145/3548606.3560596.
  * [99] James Newsome and Dawn Xiaodong Song.  Dynamic taint analysis for automatic detection, analysis, and signaturegeneration of exploits on commodity software.  In NDSS, volume 5, pages 3–4. Citeseer, 2005.
  * [100] npm, Inc.  Organization roles and permissions.  https://docs.npmjs.com/organization-roles-and-permissions, retrieved Apr. 2023.
  * [101] npm, Inc.  Organization roles and permissions.  https://docs.npmjs.com/organization-roles-and-permissions, retrieved Apr. 2023.
  * [102] Michael Ogata, Josh Franklin, Jeffrey Voas, Vincent Sritapan, and Stephen Quirolgico.  Vetting the Security of Mobile Applications.  (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-164, Rev 1, April 2019.
  * [103] Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier.  Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks.  In Detection of Intrusions and Malware, and Vulnerability Assessment, 2020.
  * [104] Marc Ohm and Charlene Stuke.  Sok: Practical detection of software supply chain attacks.  In Proceedings of the 18th International Conference on Availability, Reliability and Security, ARES ’23, New York, NY, USA, 2023. Association for Computing Machinery.  doi:10.1145/3600160.3600162.
  * [105] Chinenye Okafor, Taylor R. Schorlemmer, Santiago Torres-Arias, and James C. Davis.  Sok: Analysis of software supply chain security by establishing secure design properties.  In Proc. ACM SCORED ’22, Nov 2022.
  * [106] OpenSSF Best Practices Working Group.  OpenSSF Scorecard.  https://securityscorecards.dev/.
  * [107] OSCAL NIST team.  Open Security Controls Assessment Language (OSCAL).  URL: https://pages.nist.gov/OSCAL/.
  * [108] Laura Paine and Hirsch Singhal.  Raising the bar for software security: Github 2fa begins march 13.  https://github.blog/2023-03-09-raising-the-bar-for-software-security-github-2fa-begins-march-13/, retrieved Apr. 2023, 2023.
  * [109] Claire Peters and Derek DeBellis.  Google-DORA 2022 Accelerate State of DevOps Report, Sep 2022.  URL: https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out.
  * [110] Gerald J. Popek.  Security kernels - a principle of kernel design.  In Proceedings of the May 6-10, 1974, National Computer Conference and Exposition, AFIPS ’74, page 973–980, New York, NY, USA, 1974. Association for Computing Machinery.  doi:10.1145/1500175.1500361.
  * [111] Python Software Foundation.  PyPI 2FA Security Key Giveaway.  https://pypi.org/security-key-giveaway/, retrieved Jul 2022, 2022.
  * [112] Sudhakar Ramakrishna.  An investigative update of the cyberattack.  URL: https://orangematter.solarwinds.com/2021/05/07/an-investigative-update-of-the-cyberattack/.
  * [113] Ronald L. Rivest.  Can we eliminate certificate revocation lists?  In Proc. Financial Crypto 1998, 1998.
  * [114] Aviel D Rubin.  Independent one-time passwords.  computing Systems, 9(1):15–27, 1996.
  * [115] Mark Ryan.  Enhanced certificate transparency and end-to-end encrypted mail.  In Proc. Network and Distributed System Security Symposium (NDSS), 01 2014.
  * [116] Jerome H Saltzer and Michael D Schroeder.  The protection of information in computer systems.  Proceedings of the IEEE, 63(9):1278–1308, 1975.
  * [117] Justin Samuel, Nick Mathewson, Justin Cappos, and Roger Dingledine.  Survivable key compromise in software update systems.  In Proceedings of the 17th ACM conference on Computer and communications security, pages 61–72. ACM.  URL: https://dl.acm.org/doi/10.1145/1866307.1866315, doi:10.1145/1866307.1866315.
  * [118] Isaac Z. Schlueter.  kik, left-pad, and npm.  The npm Blog, Mar 2016.  URL: https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm.
  * [119] Johannes Schlumberger, Christopher Kruegel, and Giovanni Vigna.  Jarhead analysis and detection of malicious java applets.  In Proceedings of the 28th Annual Computer Security Applications Conference, ACSAC ’12, page 249–257, New York, NY, USA, 2012. Association for Computing Machinery.  doi:10.1145/2420950.2420988.
  * [120] Adi Shamir.  How to share a secret.  Commun. ACM, 22(11):612–613, nov 1979.  doi:10.1145/359168.359176.
  * [121] Inbal Shani.  Software Supply Chain Compromises - A Living Dataset, Jun 2023.  URL: https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience/.
  * [122] Inbal Shani.  Survey reveals AI’s impact on the developer experience, Jun 2023.  URL: https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience/.
  * [123] Sigstore contributors.  Sigstore.  https://docs.sigstore.dev/.
  * [124] SLSA contributors.  SLSA Provenance.  https://slsa.dev/provenance/v0.2.
  * [125] Murugiah Souppaya, Karen Scarfone, and Donna Dodson.  NIST Special Publication 800-218 - Secure Software Development Framework (SSDF) Version 1.1.  NIST Computer Security Research Center Publications, Feb. 2022.
  * [126] SPDX contributors.  SPDX Overview.  https://spdx.dev/about/.
  * [127] tedhudek.  Authenticode digital signatures - windows drivers.  URL: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/authenticode.
  * [128] National Telecommunications and Information Administration.  Software Bill of Materials.  https://www.ntia.gov/SBOM, 2021.
  * [129] the Git community.  git source control management.  URL: https://git-scm.com/.
  * [130] The sigstore Developers.  Pluggable Types.  https://docs.sigstore.dev/logging/pluggable-types/.
  * [131] The SPIFFE authors.  The x.509 spiffe verifiable identity document - key usage.  https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#43-key-usage, retrieved Apr. 2023.
  * [132] The White House.  Executive Order on Improving the Nation’s Cybersecurity.  The White House Briefing Room - Presidential Actions, May 2021.  URL: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/.
  * [133] Emin Topalovic, Brennan Saeta, Lin-Shung Huang, Collin Jackson, and Dan Boneh.  Towards short-lived certificates.  In Proc. of Web 2.0 Security & Privacy (W2SP) ’12, 2012.
  * [134] Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos.  in-toto: Providing farm-to-table guarantees for bits and bytes.  In 28th USENIX Security Symposium (USENIX Security 19), pages 1393–1410, Santa Clara, CA, August 2019. USENIX Association.  URL: https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias.
  * [135] Santiago Torres-Arias, Anil Kumar Ammula, Reza Curtmola, and Justin Cappos.  On omitting commits and committing omissions: Preventing git metadata tampering that (re) introduces software vulnerabilities.  In 25th USENIX Security Symposium (USENIX Security 16), pages 379–395, 2016.
  * [136] David Uberti, James Rundle, and Catherine Stupp.  The log4j vulnerability: Millions of attempts made per hour to exploit software flaw.  URL: https://www.wsj.com/articles/what-is-the-log4j-vulnerability-11639446180.
  * [137] R. Uhlig, G. Neiger, D. Rodgers, A.L. Santoni, F.C.M. Martins, A.V. Anderson, S.M. Bennett, A. Kagi, F.H. Leung, and L. Smith.  Intel virtualization technology.  Computer, 38(5):48–56, 2005.  doi:10.1109/MC.2005.163.
  * [138] Nikos Vasilakis, Achilles Benetopoulos, Shivam Handa, Alizee Schoen, Jiasi Shen, and Martin C. Rinard.  Supply-chain vulnerability elimination via active learning and regeneration.  In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, pages 1755–1770. ACM.  URL: https://dl.acm.org/doi/10.1145/3460120.3484736, doi:10.1145/3460120.3484736.
  * [139] Robert Wahbe, Steven Lucco, Thomas E Anderson, and Susan L Graham.  Efficient software-based fault isolation.  In Proceedings of the fourteenth ACM symposium on Operating systems principles, pages 203–216, 1993.
  * [140] Jack Wallen.  Classic SysAdmin: Understanding Linux File Permissions.  https://www.linuxfoundation.org/blog/blog/classic-sysadmin-understanding-linux-file-permissions, retrieved Nov. 2023, Jul. 2022.
  * [141] Frank Wang, Catherine Yun, Shafi Goldwasser, Vinod Vaikuntanathan, and Matei Zaharia.  Splinter: Practical private queries on public data.  In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17), pages 299–313, Boston, MA, March 2017. USENIX Association.  URL: https://www.usenix.org/conference/nsdi17/technical-sessions/presentation/wang-frank.
  * [142] The Netfilter’s webmasters.  netfilter.  https://www.netfilter.org/, retrieved Dec. 2023.
  * [143] David A. Wheeler, John Speed Meyers, Mikaël Barbero, and Rebecca Rumbul.  SLSA++: A Survey of Software Supply Chain Security Practices and Beliefs, Mar 2023.  URL: https://openssf.org/blog/2023/03/15/new-slsa-survey-reveals-real-world-developer-approaches-to-software-supply-chain-security/.
  * [144] Boming Xia, Tingting Bi, Zhenchang Xing, Qinghua Lu, and Liming Zhu.  An empirical study on software bill of materials: Where we stand and the road ahead.  URL: http://arxiv.org/abs/2301.05362, arXiv:2301.05362[cs], doi:10.48550/arXiv.2301.05362.
  * [145] T. Ylonen and Ed. C. Lonvick.  Ssh protocol architecture sepcification.  IETF Data Tracker, Jan 2006.  URL: {https://datatracker.ietf.org/doc/html/rfc4251}.
  * [146] S. D. Young.  Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, Sep 2022.  URL: https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf.
  * [147] Yubico.  Otps explained.  https://developers.yubico.com/OTP/OTPs_Explained.html, retrieved Apr. 2023.
  * [148] Nusrat Zahan, Thomas Zimmermann, Patrice Godefroid, Brendan Murphy, Chandra Maddila, and Laurie Williams.  What Are Weak Links in the Npm Supply Chain?  In Proc. ACM ICSE-SEIP ’22, May 2022.