Supply Chain Insecurity: The Lack of Integrity Protection in SBOM Solutions

Can Özkan Xinhai Zhou Dave Singelée

KU Leuven - COSIC KU Leuven - COSIC KU Leuven - COSIC
Kasteelpark Arenberg 10 Kasteelpark Arenberg 10 Kasteelpark Arenberg 10
3001 Heverlee, Belgium 3001 Heverlee, Belgium 3001 Heverlee, Belgium
can.ozkan@kuleuven.be xinhai.zou@kuleuven.be dave.singelee@kuleuven.be

Abstract—The SolarWinds attack that exploited weaknesses have emerged as a crucial instrument for improving soft-
in the software update mechanism highlights the critical ware transparency and visibility. An SBOM is a formal,
need for organizations to have better visibility into their machine-readable inventory of software components and
arXiv:2412.05138v1 [cs.CR] 6 Dec 2024

software dependencies and potential vulnerabilities associ- dependencies, information about those components, and
ated with them, and the Software Bill of Materials (SBOM) their relationships [3]. It provides an inventory of the
is paramount in ensuring software supply chain security. various software components used in an application, such
Under the Executive Order issued by President Biden, the as libraries, frameworks, and dependencies. This nested
adoption of the SBOM has become obligatory within the inventory identifies the root and nested components within
United States. The executive order mandates that an SBOM the software, allowing for better management and mitiga-
should be provided for all software purchased by federal tion of potential security risks. [4]. By providing a com-
agencies. The main applications of SBOMs are vulnerability prehensive inventory of all open-source and proprietary
management and license management. This work presents components, along with their respective licenses and vul-
an in-depth and systematic investigation into the integrity nerability information, SBOMs empower organizations to
of SBOMs. We explore different attack vectors that can manage security, license, and compliance risks effectively
be exploited to manipulate SBOM data, including flaws in the ever-evolving software development ecosystem [5].
in the SBOM generation and consumption phases in the The adoption of SBOMs becomes vital after the Biden
SBOM life cycle. We thoroughly investigated four SBOM
administration signed the Executive Order on Improving
the Nation’s Cybersecurity in May 2021 [6], [7]. This or-
consumption tools and the generation process of SBOMs for
der emphasizes the need for secure software development
seven prominent programming languages. Our systematic
practices and forms the basis for standardizing and pro-
investigation reveals that the tools used for consumption lack
moting the use of SBOMs across government agencies and
integrity control mechanisms for dependencies. Similarly,
critical infrastructure sectors. The executive order men-
the generation process is susceptible to integrity attacks
tions that commercial software development often lacks
as well, by manipulating dependency version numbers in
transparency, sufficient focus on the software’s ability to
package managers and additional files, resulting in incorrect resist attacks, and adequate controls to prevent tampering
SBOM data. This could lead to incorrect views on software by malicious actors. Implementing more rigorous mech-
dependencies and vulnerabilities being overlooked during anisms is urgently needed to ensure products function
SBOM consumption. To mitigate these issues, we propose securely and as intended. For this reason, any company
a solution incorporating the decentralized storage of hash that sells software to the federal government must provide
values of software libraries. the application and a corresponding SBOM [8]. Since
Index Terms—software bill of materials, supply chain secu- SBOM is mentioned in the Cyber Resilience Act [9]
rity, dependency version manipulation, decentralized storage published by the European Parliament in July 2023, it is
solutions, integrity control mechanisms expected to become mandatory in the EU in the upcoming
years as well.
There is a relationship between entities producing
1. Introduction and acquiring software. We denote the entity that pro-
duces software as supplier in the rest of this work. On
Modern software systems involve increasingly com- the other hand, we denote the entity that acquires and
plex and dynamic supply chains. Lack of visibility into purchases the software from the supplier as consumer.
the composition and functionality of these systems con- The responsibility for generating an SBOM typically lies
tributes to cyber security risks [1]. The heavy reliance with the supplier [1]. This includes, but is not limited
on third-party software components and dependencies to, compiling an inventory of all components, libraries,
within the modern software ecosystem necessitates robust and dependencies used in the software, along with their
strategies to ensure software supply chain security. One corresponding versions and license information.
notable example is the SolarWinds attack, which exploited An SBOM encompasses various formats for docu-
weaknesses in the software update mechanism and high- menting and sharing information about software compo-
lights the critical need for organizations to have better nents within the supply chain. Two prominent SBOM
visibility into their software dependencies [2]. SBOMs types, CycloneDX and SPDX (Software Package Data
Exchange), have emerged as leading standards in this data.
domain. SPDX, created by the Linux Foundation, is an The rest of this chapter is organized as follows: In
open standard for communicating SBOM information, Section 2, we describe the life cycle of an SBOM, explain
including provenance, license, security, and other related the software development lifecycle (SDLC), and define
information [10]. Its main use case is license compliance. possible attack points. In Section 3 and 4, we investigate
CycloneDX, on the other hand, was primarily designed SBOM consumption and generation tools, respectively.
by OWASP to solve vulnerability identification, license Section 5 presents a solution to mitigate the identified
compliance, and outdated component analysis [11]. integrity problems and discuss the details in Section 6.
Let us now zoom in on vulnerability management. An We discuss related work in Section 7 and conclude our
SBOM facilitates a systematic approach for identifying work in Section 8.
security weaknesses by providing a detailed inventory of
software components and their versions. This process can 2. Lifecycle of an SBOM
be implemented proactively at regular intervals, with a
frequency depending on the organization’s policy, or re- Due to the strong relationship between SBOM and the
actively in response to specific vulnerabilities. Vulnerabil- accompanying software, we opt to first briefly discuss the
ity management can be performed regularly by checking Software Development Life Cycle (SDLC) before moving
the SBOM against a vulnerability database such as the to the SBOM lifecycle.
National Vulnerability Database (NVD) to identify any
known vulnerabilities in the software components. There- 2.1. Software Development Life Cycle (SDLC)
fore, potential security risks can be proactively identified
and addressed. This process can be automated to ensure The Software Development Life Cycle (SDLC) is a
timely and efficient vulnerability management. In addition, fundamental component of the software engineering pro-
vulnerability management utilizing SBOM can be trig- cess, detailing the transformation of code into the final
gered at specific times, such as when a new vulnerability product. For a typical SDLC, it consists of six primary
with a sufficiently high level of CVSS (Common Vul- phases: requirement, design, implementation, testing, de-
nerability Scoring System) is discovered. In such cases, ployment, and maintenance [13]:
the SBOM can be quickly referenced to determine if the
1) Requirement: This phase involves gathering re-
affected software component is used in the organization’s
quirements from stakeholders to assess the prod-
software system, allowing for swift vulnerability identi-
uct’s feasibility, revenue potential, and cost.
fication, remediation, and risk mitigation. For instance,
2) Design: This phase includes system architecture,
when Log4j, also known as Log4Shell with CVE-2021-
selection of programming languages, and security
44228, was first discovered, it created widespread concern
measures to mitigate potential issues.
due to its potential to be exploited by adversaries who
3) Implementation: This phase translates the soft-
request arbitrary LDAP and JNDI servers, resulting in the
ware requirements into code.
execution of arbitrary code remotely or sensitive informa-
4) Testing: This phase validates the software’s func-
tion leakage [12]. The vulnerable Java components can be
tionalities, user experience, and security.
quickly searched in an SBOM, and the organization can
5) Deployment: This phase releases the final prod-
quickly determine if they are affected. This incident em-
uct and delivers it to end-users.
phasized the urgent need for organizations to assess their
6) Maintenance: This phase monitors the entire
exposure to a critical vulnerability and take appropriate
software life cycle to ensure any issues are iden-
remediation actions immediately.
tified and corrected in subsequent updates.
Both in vulnerability and license management, the
integrity of SBOMs is of critical importance. In this work, Due to the extensive benefits of using the SDLC,
we exhaustively investigated the consumption tools and such as structured approach, risk management, and cost-
generation processes of SBOMs for prominent software effectiveness, many organizations are adopting SDLC in
languages. This involves examining how adversaries could order to improve their software development process [14].
potentially manipulate SBOMs to hide security vulnerabil-
ities. We explored how tampered SBOMs might deceive 2.2. SBOM-integrated SDLC
consumption tools into producing inaccurate vulnerability
data, resulting in organizations overlooking vulnerabili- To enhance the security and visibility of the supply
ties. We also explored how generation tools could be chain, the National Telecommunications and Information
attacked to provide incorrect and misleading dependency Administration (NTIA) introduced the concept of the
information leading to the concealment of vulnerabilities Software Bill of Materials (SBOM) in 2018 [15]. Due
when consumed. In summary, such manipulations can to the strong connection between SBOM and the SDLC,
lead to the generation of misleading vulnerability reports discussing the SBOM lifecycle in conjunction with the
by SBOM consumption tools, resulting in organizations SDLC is essential. Fig. 1 illustrates an SDLC integrated
to inadvertently believe that their software assets are with SBOM, featuring a typical SDLC on the supplier’s
free from vulnerabilities. Therefore, organizations may side, the distribution stage, and a maintenance phase
overlook critical security risks, exposing themselves to on the consumer’s side. This section will focus on the
potential exploitation and compromise. Our investigation SBOM lifecycle, excluding the typical SDLC components
underscores the crucial importance of robust integrity detailed in Section 2.1.
controls and verification mechanisms within the SBOM Throughout the development life cycle, the SBOM
life cycle to ensure the accuracy and reliability of SBOM helps track and manage dependencies and ensures that all
components meet security and licensing requirements on • The attacker can modify any file (e.g., SBOM)
the supplier’s end. Suppliers can use the SBOM to track between supplier and consumer.
and manage software dependencies in the implementation • The attacker can alter the codebase at the sup-
phase. This ensures that all components are up-to-date, plier’s side.
secure from known vulnerabilities, and compliant with • The attacker cannot alter the codebase at the con-
licensing terms. The supplier can continuously update the sumer’s side1
SBOM to reflect changes in dependencies or libraries, • The attacker has no access to any cryptographic
which ensures that the final delivered SBOM accurately keys either stored by consumer or supplier.
reflects the software’s composition. The software under-
goes various tests in the testing phase, such as penetration 2.4. Attack points in SBOM lifecycle
testing, code review, source composition analysis, and dy-
namic security testing. The SBOM facilitates identifying
potential vulnerabilities in dependencies on the supplier’s
end. Once the testing phase is fulfilled, it is deployed
to the production environment. When deploying the final
product, the supplier can include the final SBOM as
part of the deliverables. This provides the consumer with
detailed information about the software’s composition and
dependencies. After deployment, the software enters the
maintenance phase. The consumer can then use the de-
livered SBOM to perform periodic vulnerability checks.
By comparing the components listed in the SBOM against
vulnerability databases like the NVD, the consumer can
identify known vulnerabilities in either a proactive or a
reactive way.

Figure 2. Attack points in a typical SDLC integrated with SBOM

Based on the trust assumptions outlined for the SBOM

lifecycle, Fig. 2 depicts an SBOM-integrated SDLC, high-
lighting potential attacks at different phases. The figure
shows three essential scenarios where attacks might occur:
during SBOM generation before the deployment phase
(Attack scenario 1), throughout the SBOM distribution
process (Attack scenario 2), and during SBOM storage
in the maintenance phase (Attack scenario 3).

2.4.1. Attack scenario 1 during SBOM generation be-

fore the deployment phase. In this scenario, attackers
with access to the codebase aim to mislead the SBOM
generation process to produce an inaccurate SBOM, af-
Figure 1. Typical SDLC integrated with SBOM fecting the results of SBOM consumption on both the
supplier’s and consumer’s sides. To generate an incorrect
SBOM, attackers can modify either (1) the source code
2.3. Trust assumption in SBOM lifecycle itself or (2) the library information file, depending on their
level of access to the codebase.
Before we zoom in on the security of the SBOM
lifecycle, we first need to specify our trust assumptions 1) Source Code Access: If attackers have access to
for suppliers, consumers and the communications channels the source code, they can directly inject malicious
they rely on. We want to minimize these trust assumptions. code into the source code without altering the
Therefore, we do not make any assumptions regarding the library information file. In this case, a naive
security of the file systems, used to store SBOMS and/or SBOM generator that relies only on the library
software, used by suppliers and consumers. Moreover, information file will generate an SBOM reflecting
no trust assumptions are made on the security of the an incorrect product structure unrelated to the
communication channel between suppliers and consumers. source code.
The only trust assumption we make, is that any key man- 2) Library Information Access: If attackers only
agement system used by either consumer and/or supplier have access to the library information, they
is reliable and secure.
1. The main reason is that if an attacker is capable of altering the
We consider attackers with the goal to compromise codebase at the consumer’s side, it does not really make sense to
the integrity of an SBOM. Based on the trust assumptions manipulate the SBOM itself. Therefore, this attack is out of scope of
above, the attacker has the following capabilities: this work.
 can modify the library information file to hide version numbers are tampered with. As our objective is se-
vulnerable versions and make these appear as curity, we chose the tools recommended in the CycloneDx
vulnerability-free versions without changing the tool center. The tools we experimented with are OWASP
source code. Similarly, a naive SBOM generator Dependency Track [16], Bomber [17], cve-bin-tool [18],
that relies solely on the library information will and Grype [19]. The criteria governing tool selections
thus help attackers conceal vulnerabilities. stem from their adherence to fundamental principles such
as open-source availability, unrestricted free accessibil-
2.4.2. Attack scenario 2 throughout the SBOM distri- ity, and formal recognition by the CycloneDX standard.
bution process. In this scenario, attackers with access to Our analysis revealed a vulnerability that compromises
insecure channels between suppliers and consumers aim the integrity of dependency information within all four
to spoof consumers with incorrect information of the end applications. None of the applications employed any cryp-
product. By tampering with the library information in the tographic controls for integrity verification in the depen-
SBOM, attackers can create incorrect information during dencies listed in the SBOM file, underscoring a significant
the consumer’s SBOM consumption process for malicious gap in integrity control practices. While hash values were
purposes, such as hiding vulnerabilities. present within the SBOM file, they were not checked to
ensure the integrity of the libraries and dependencies or
2.4.3. Attack scenario 3 during SBOM storage in to detect potential manipulation. Therefore, our findings
the maintenance phase. In this scenario, attackers with show a limitation in existing SBOM consumption tools.
access to the file system aim to mislead the SBOM These tools rely solely on version number information to
consumption process to obtain wrong results. This can identify possible vulnerabilities concerning dependencies,
happen on both the supplier’s and consumer’s side. Based which is a critical shortcoming.
on the types of files and the entity being attacked, three For illustration purposes, we implemented our attack
different attack scenarios can be identified: for the OWASP Dependency Track. As discussed above,
1) Supplier’s Codebase Access: If attackers have our code review showed that the tool exclusively focuses
access to the codebase during maintenance, they on comparing the version numbers of each software com-
can tamper with the source code or alter the li- ponent against a vulnerability database. The lack of hash
brary information file based on their accessibility value comparison in this tool was surprising to us. We
to the code: Source Code Access or Library In- implemented our attack as follows: We first installed the
formation Access. However, these modifications tool. Then, we created an empty project and filled in the
will not affect the current product but compro- details, such as the project name and type. We used the
mise future iterations. Owasp-developed Juicy Shop application for demonstra-
2) Supplier’s SBOM File Access: If attacks can tion purposes. Upon completion, we imported a clean and
access the SBOM file on the supplier’s side, they non-tampered SBOM file in CycloneDx format. We ana-
can update the version information in the SBOM lyzed the results executed by the tool, which summarizes
file when new vulnerabilities are discovered be- the benign use case of SBOM consumption. As shown in
fore developers notice. This concealment prevents Fig. 3, the vulnerability results are 15 critical, 42 high, 17
developers from updating the software to address medium, and 0 low, with 75 exploit predictions and audit
the vulnerabilities. vulnerabilities. Additionally, the tool shows that there are
3) Consumer’s SBOM File Access: If attackers 840 components in the application.
obtain access to the SBOM file on the consumer’s The engine.io library used in the application was ma-
side, they can employ the same strategy as on the nipulated from version 3.4.2, which contains vulnerabili-
supplier’s side to hide new vulnerabilities. Con- ties, to version 6.5.3 without any vulnerability at the time
sequently, consumers will not take any actions to of writing, and we did not change any hash value, leaving
mitigate any hidden vulnerabilities. the tool a hint to catch the modification. In other words,
the SBOM file was tampered with in such a way that the
3. Consumption of an SBOM version number of the engine.io dependency was modified
from 3.4.2 to 6.5.3 while leaving the hash value intact, as
In this section we discuss our experiments to com- seen in Fig. 4. Subsequently, the newly modified SBOM
promise the integrity of SBOM consumption and, more file was imported into the OWASP Dependency Track.
specifically, tampering with version numbers of depen- After import, the tool successfully digested the file without
dencies listed in the SBOM. This can have significant checking the integrity of the component we manipulated.
security implications. For instance, tampering with values Then, it analyzed the file and produced results show-
in dependencies can misrepresent the actual dependencies ing fewer vulnerabilities than the benign use case. More
being used, which, in turn, affects the vulnerability man- specifically, the tool showed one less high and medium
agement process because it can result in false security vulnerability this time, as seen in Fig. 5, resulting in 41
assessment results. Therefore, organizations can overlook high and 16 medium, with 73 exploit predictions and audit
vulnerabilities and assume they are safe from particular vulnerabilities. Despite the availability of hash values, we
vulnerabilities while they may not be secure. In addition, can conclude that the SBOM consumption process lacks
tampering with license information in an SBOM file can integrity control for the dependencies listed in the SBOM
violate your license compliance process, leading to non- file.
compliance with licensing obligations. Additionally, an unexpected consequence emerged
We systematically reviewed four distinct consumption while analyzing tools for SBOM consumption. Each tool
applications and analyzed how these tools react when the relied on a distinct vulnerability database, leading to
 Figure 3. Benign SBOM Consumption: Non-tampered SBOM

reside. Available automated tools can scan the source code

and file system in order to reveal dependencies, libraries,
frameworks, and other components used in the application.
In addition, many modern programming languages and
frameworks utilize package and dependency management
tools such as Maven [23], npm [24], pip [25], and com-
poser [26] that maintain a list of external dependencies
Figure 4. Tampering SBOM File without Altering Hash Values imported and their versions so that those dependencies
can be easily installed at the beginning of the software
installation or when another developer forks the code base.
discrepancies in the number of vulnerabilities identified SBOM generation tools, programs that help organizations
following SBOM consumption. In particular, Dependency produce their SBOM, can deduce information to identify
Track can locate 75 vulnerabilities, with 15 critical, 42 and document dependencies through the aforementioned
high, 17 medium, and one unassigned. In contrast, Bomber methods.
can locate 97 vulnerabilities in total, with 16 critical, 39
This section discusses a comprehensive analysis and
high, 40 moderate, and two low, and cve-bin-tool can
experimental evaluation of SBOM generation processes
detect 85 CVEs in total, with 22 critical, 63 high, 41
across various prominent programming languages. We
medium, zero low, and six unknown. OWASP Depen-
seek to answer whether adversaries can manipulate the
dency Tracker utilizes the NVD and the GitHub Advisory
generation process, which could yield inaccurate SBOM
database as primary sources [20]. Conversely, Bomber
files. Manipulating the SBOM generation process to ex-
leverages the Open Source Vulnerabilities (OSV) database
clude specific dependencies or to mislead version numbers
[21] by default. The cve-bin tool, on the other hand,
compromises the integrity and accuracy of the resulting
prioritizes vulnerability information from NVD, OSV, Git-
SBOM artifact.
lab Advisory Database (GAT), RedHat Security Database
(REDHAT), and Curl Database (Curl) sources [22]. Therefore, we conducted experiments to compromise
Another shortcoming we identified, was that the tools the integrity of the SBOM generation process by manip-
in question do not require SBOMs to be digitally signed ulating dependency version information in package man-
before consumption, which presents a security risk. Con- agers. More specifically, we analyzed SBOM generation
sequently, even when suppliers digitally sign an SBOM for Python, C, C++, Java, C#, Javascript, and PHP—the
file to confirm its integrity and authenticity, adversaries first seven programming languages based on Tiobe’s
could effortlessly tamper with it and remove the signa- November 2023 ranking [27]. As the objective of our
ture before consumption. This manipulation could lead study is geared toward security, we chose the tools from
to excluding specific dependencies or misleading version the CycloneDx tool center. The tools we experimented
numbers, potentially obscuring existing vulnerabilities. To with for this section are CycloneDx for Python [28],
address this risk, future iterations of SBOM consumption CycloneDx for Conan [29], CycloneDx for Maven [30],
tools should introduce the enforcement of mandatory dig- CycloneDx for .NET [31], CycloneDx for npm [32], Cy-
ital signatures before consumption. cloneDx for PHP Composer [33], and Syft [34].
We performed a source code review to reveal the
4. Generation of an SBOM SBOM generation process and how the tools identify
dependency information. We carefully reviewed the source
The SBOM generation process entails creating a com- code of the SBOM generation tools mentioned previously.
prehensive list of all software components, such as li- This in-depth analysis aims to elucidate the mechanisms
braries, frameworks, and dependencies, and their corre- through which these tools extract and process depen-
sponding versions used in an application. This typically dency information. Our analysis revealed a flaw that
involves scanning the software’s source code and file sys- compromises the integrity of the generated SBOM data
tem, where these components and other relevant artifacts by manipulating the package managers and other files in
 Figure 5. Malicious SBOM Consumption: Tampered SBOM

all tools except CycloneDx for Maven. The generation

process is susceptible to manipulation through tampering
with package management systems and their associated
dependency files. Dependency files such as package.json
and requirements.txt specify the software project’s ex-
ternal dependencies and versions. An adversary could
introduce misleading information by tampering with these
dependency files as well as additional files, which will
be discussed in detail in the following paragraphs. This
underscores the importance of implementing robust mech-
anisms within SBOM generation tools beyond solely trust-
ing on dependency and some file information.
The next paragraphs dissect the SBOM generation Figure 6. Manipulating Generation for C/C++
tools specific to each programming language and system-
atically elaborate on the experimental results. The results
are summarized in Table 1. to achieve it.
PHP: It is possible to manipulate the SBOM
generation process for PHP projects. Manipulating C/C++: The tool used to generate SBOM for
the contents of the ./composer.json, ./composer.lock, C/C++ projects is read-only at the time of writing
and /vendor/composer/installed.json files in the code [29]. The owner archived this repository on Oct 2,
base influence the SBOM generation process, thereby 2023. Although there is a newer version of the tool
potentially compromising the reliability and accuracy [35], it is not yet a mature project to generate SBOM
of the resulting SBOM artifact. Another interesting for C/C++ projects. Hence, we could not analyze the
outcome is that CycloneDx for PHP does not produce CycloneDX Conan SBOM generation tool. Instead, we
a hash value for components. Since a hash value is not used another tool. Syft, supporting C/C++, Debian, Go,
utilized in the consumption phase, as discussed in the and JavaScript ecosystems, among others, was used to
Consumption of an SBOM section, it does not break the generate SBOM for C/C++ projects. It supports the
consumption operation; however, dependency integrity Conan package manager for C/C++ projects, and it is
validation cannot be achieved for organizations seeking possible to manipulate the SBOM generation process for
to achieve it. C/C++ projects utilizing the Conan package manager
if an adversary manipulates either conanfile.txt or
Python: It is possible to manipulate the SBOM conanfile.py as can be seen in Fig. 6.
generation process for projects written in Python.
The requirements.txt file is a package management Java: It is not possible to tamper with Java projects
file and dictates the dependencies required for the that utilize Maven for their build process. There are two
project’s execution. The SBOM generation process tools to generate an SBOM for Java projects: CycloneDX
can be manipulated by changing the contents of the Maven Plugin [30] and CycloneDX Core (Java) [36].
requirements.txt file in the code base. This could make Both are used as Maven plugins. Hence, we focused on
the final SBOM less reliable and accurate. Another the CycloneDX Maven Plugin. The plugin configuration
interesting result is that CycloneDx for Python produces for usage is available in [37]. Maven, a widely used build
no component hash values. Since a hash value is not and package management tool in the Java development
utilized in the consumption phase, as discussed in the ecosystem, has a technique for efficiently managing
Consumption of an SBOM section, it does not break the dependencies. Maven prominently includes a centralized
consumption operation; however, dependency integrity repository that is a reliable and authoritative source for
validation cannot be achieved for organizations seeking pre-compiled software libraries and dependencies. When
 Figure 7. Different Hash Values in C#
Figure 8. No Hash Values for Tampered Dependency in JS

a Java project uses Maven, all changes made to the We validated the identified flaw for Javascript as fol-
project object model (pom.xml) file swiftly initiate an lows. We installed the tool. For demonstration purposes,
immediate and efficient updating process. This automated we once again used the Owasp-developed Juicy Shop
process guarantees that the project includes the designated application. We generate an SBOM for the Juicy Shop
versions of the dependencies listed in the pom.xml file application, summarizing the benign use case of SBOM
by retrieving them from the central repository. If an generation. We then tampered with version values on
adversary tampers with the version numbers in pom.xml, package.json, package-lock.json, and package.json files
Maven will download and install the versions the attacker under the node modules folder. Thus, incorrect, tampered
indicated. For this reason, an adversary trying to sabotage SBOM data was generated in the following SBOM gen-
the SBOM generation process might actually patch a eration, posing a security risk for organizations when
vulnerability in a dependency on behalf of the company consumed.
while trying to manipulate the process. Thus, the SBOM Besides the manipulation of the SBOM generation
generation process for Java projects incorporating Maven process, there is another potential security concern regard-
for build and dependency management does not allow ing the SBOM generation tools. While digital signatures
tampering with the version numbers. can guarantee the authenticity and integrity of SBOM data,
their use remains optional and is not activated by default
C#: It is possible to manipulate the SBOM generation [1]. This flaw exposes the SBOM generation process to
process for dotnet projects written in C#. The tool used to manipulation by adversaries.
generate SBOM focuses on dotnet projects written in C#.
Changes made to the packages.config file in the code 5. Conceptual solution
base affect the SBOM generation process, which could
make the final SBOM artifact less reliable and accurate. To solve the identified problems in both the SBOM
Another significant observation is that the generation tool consumption and generations tools, we propose the com-
produces different hash values once you alter version bination of 3 solutions: (1) secure distribution of SBOMs,
numbers, as Figure Fig. 7 shows. ensuring that the SBOMs are transmitted securely from
supplier to consumer; (2) secure storage of SBOMs, which
JavaScript: It is possible to manipulate the SBOM protects SBOMs from unauthorized access and tampering;
generation process for Node.js projects, an open-source, and (3) secure decentralized storage of hash values, facili-
cross-platform JavaScript runtime environment written tating the verification and validation of SBOM authenticity
in JavaScript if adversaries manipulate package.json, by comparing recorded hashes.
package-lock.json, and package.json files under the
node modules folder. Furthermore, we observed that 5.1. Secure distribution of SBOMs
the generation tool generates a hash value for the non-
The distribution of SBOM over insecure channels
tampered SBOM generation process. In contrast, it does
clearly poses significant security risks. For instance, an
not generate a hash value for any component in a software
SBOM with a library with known vulnerabilities in SBOM
project, even if only one version number is tampered
could be altered to a version without vulnerabilities. How-
with. In other words, only one alteration in version
ever, this change only happens in the SBOM itself; the
numbers is enough to not generate any hash value for
actual software remains vulnerable. The SBOM might
all the components in a software project, as seen in Fig. 8.
still seem valid but fail to reflect the software’s accurate
information. Consequently, attackers could exploit these
undisclosed vulnerabilities.
TABLE 1. SBOM G ENERATION TAMPERING R ESULTS To ensure the secure SBOM distribution between sup-
Programming Language Tampering Possible pliers and consumers, we recommend using secure com-
Python ✓ munication techniques such as Transport Layer Security
C ✓ (TLS) or end-to-end encryption. These mechanisms are
C++ ✓ crucial for maintaining the authenticity, confidentiality,
Java ✕ and integrity of SBOM during distribution. With these
C# ✓
JavaScript ✓
safeguards in place, attackers cannot compromise the
PHP ✓ SBOM during transmission because any tampered files
will fail to decrypt correctly.
5.2. Secure storage of SBOMs with certificate transparency [38], [39]. The importance
of certificate transparency became evident after the Dig-
Secure storage plays an important role in a secure iNotar hack, which resulted in the issuance of numerous
SBOM lifecycle, as its security impacts the entire SBOM fraudulent certificates [40]. This incident highlighted the
lifecycle. To ensure secure SBOM storage at suppliers need for public records so everyone on a global level can
and consumers, we recommend using digital signatures on verify certificates, enhancing trust beyond relying solely
SBOM files and associated software. Upon development on Certificate Authorities (CAs). Certificate transparency
or receipt, both parties should sign the SBOM using their introduced a system where CAs no longer directly sign
private keys with an appropriate validity period for these certificates for web servers, but instead CAs first send the
signatures. If attackers attempt to compromise the SBOM certificates to log servers. Once logged, the certificates
or software to spoof future SBOM consumption, they can be signed and issued to the web servers, allowing
cannot produce a valid signature without access to the monitors to review the certificates in the logs and notify
private keys. For enhanced security, a shorter validity pe- web servers if any discrepancies or issues are found.
riod for signatures is required to prevent hackers replacing Monitors can be deployed by anyone interested in web
an SBOM by an outdated version. security, ensuring the accuracy and integrity of issued
certificates. Such a public log system is very suitable in
5.3. Linking SBOMs to the actual software our setting for establishing hash tables for every software
being issued, enhancing transparency and allowing for
Secure communication and storage are common se- public verification for each software hash.
curity practices, and therefore the two security solutions
described above can be relatively easy realized. However, 5.4.2. Blockchain. Blockchain was first described in 1991
a significant challenge remains: how to link an SBOM by Stuart Haber and W. Scott Stornetta to prevent tam-
to the actual software? This disconnection can occur pering with document timestamps [41]. It functions as
during SBOM generation, consumption, distribution, and a distributed public ledger, consisting of interconnected
storage. The latter two stages are covered by the solutions blocks with a previous hash and proof of work. One of
above, but security issues persist in SBOM generation and the critical properties of blockchain is its immutability,
consumption. Currently, SBOM tools use version names achieved through the combination of previous hashes and
instead of hash values to represent software, and therefore proof of work. The blockchain structure connects all
there is not a strong connection between the version name blocks in a sequential chain, where each block includes the
and the actual software component (i.e., the code itself). previous block’s hash. To modify any block, one would
The way forward is to compute the hash of the software need to change all preceding blocks to maintain the in-
and to tie this to the SBOM. However, an important tegrity of the chain. Proof of work secures the blockchain
limitation is that there is no practical method for providing by requiring significant computational effort to generate a
a reference repository for hash values of software libraries. valid hash for each block, meaning that an attacker would
Such a reference is vital, because nothing stops an attacker need immense computational power to modify a block’s
manipulating a software library to adapt the corresponding hash. The first practical implementation of blockchain was
hash value as well. It is not straightforward to establish introduced by Satoshi Nakamoto in 2008 with the creation
such a reference repository for hash values of software of Bitcoin [42]. Due to its immutability and transparency,
libraries. The challenges arise from the complexity of the blockchain technology has become increasingly popular in
current software environment. Firstly, the huge amount various fields, including certificate transparency [43], [44].
of software makes it difficult to record hash values for Its security properties make blockchain suitable for build-
all of them, necessitating an efficient storage mechanism. ing a decentralized repository of software hash values.
Secondly, the system is dynamic: software is frequently Blockchain’s properties eliminate the introduction of third
updated, sometimes even with different authors/owners. parties and add a layer of security through computational
Thirdly, the system must handle high throughput and fast power.
response times, as it will receive numerous read and write
requests in parallel. Fourthly, some companies may need
a private system for software used exclusively within 5.5. Secure decentralized repository for software
their internal networks. Finally, the solution should be hashes: main concept
decentralized, as there is no single party which can be
trusted on a global scale to manage a reference repository. Inspired by the two decentralized solutions discussed
The combination of these challenges make the creation above, we aim to create a public software hash comparison
of a reference hash table for software a difficult task. For- table that serves as a reference for everyone to check and
tunately, there exist at least two large-scale decentralized verify software integrity. As described before, certificate
systems, closely related to our setting, which could be transparency also opens possibilities for various fields,
used as a basis to realize our concept. We will briefly including binary transparency for malware fingerprints and
discuss these first in the next subsection before zooming ID-to-key mappings [38], which can be used in our design.
in on our proposed solution. We propose an SBOM framework with integrity guar-
antees, as illustrated in Fig. 9. This framework involves
5.4. Large-scale decentralized storage solutions two groups of entities (software developers and software
users) and two decentralized repositories (one for storing
5.4.1. Certificate Transparency. The transparency issues the identity information of the software developer/owner
associated with software hashes closely resemble those and another one for the information on the software –
including the hash value). The figure shows the main steps Once ownership is confirmed, the developer uploads the
in the process. We will discuss these further in this section. software’s details, such as its hash value, to the soft-
ware repository. (3) The software repository then checks
with the identities repository to confirm the developer’s
ownership. If confirmed, the information is successfully
uploaded; if not, the upload fails. Additionally, it is im-
portant to increment the software version for each new
version that gets registered. (4) If users want to verify
the validity of the software, for example during SBOM
generation or consumption, users will request reference
information from the software repository. Upon receiving
the reference information, users check the transaction’s
signature using the owner’s public key. (5) If the signature
is verified, the identities repository is then consulted to
confirm the owner’s ownership of the software when the
information was recorded in the software repository based
on the owner’s public key and the timestamp. (6) Once
the identities repository confirms ownership, users can
trust the reference information provided by the software
repository to validate the software they intend to use.

5.5.4. Ownership transfer in identities repository.

Ownership transfer occurs when a software owner de-
cides to pass software ownership to another party, which
happens in the identities repository. In our design, we
consider a software name as a property, and transferring
ownership means starting a transaction where the current
Figure 9. Proposed framework for enhanced SBOM integrity owner assigns the software name to the new owner. Once
recorded, the software repository can verify the new own-
5.5.1. Stakeholders. In our framework, there are two ership details from the identities repository. However, the
primary stakeholders: software developers and software new owner must verify their software ownership from the
users. Software developers are responsible for developing identities repository before adding any data to the software
and uploading the information of their software to the repository to prevent security issues.
software repository. On the other hand, software users
focus on verifying the libraries in software they use. 6. Discussion
For each library they want to verify, they compute the
hash value and compare it against reference data from In the previous section, we outlined our main concept
the software repository. Moreover, both groups can serve for the decentralized storage and verification of refer-
as decentralized contributors to the identity and software ence information (including the hash value) of software
repository. libraries. This section will zoom in more on some practical
considering regarding the realization of such a system,
5.5.2. Repositories. In our proposal, there are two repos- including extensions for private systems. Moreover, we
itories: the identities repository and the software reposi- will also discuss the feasibility of different implementation
tory. The identities repository serves as access control for approaches.
the software repository. Developers can modify software
information in the software repository only if they can 6.1. Implementation Approaches
prove ownership by relying on the identities repository. On
the other hand, the software repository records software 6.1.1. Blockchain-based solution. Due to the decentral-
details, such as the software name and its hash value. This ized nature of the system, a blockchain-based solution is
setup allows software users to verify the integrity of any an obvious choice. There are two main repositories in
software by comparing their software hash with the hash our design: an identities repository and a software repos-
stored in the software repository. itory. The use of blockchain gives us integrity guaranties
and supports transaction-based ownership control. The
5.5.3. Enhanced SBOM integrity by decentralized identities repository guarantees a developer’s identity and
public repositories. As illustrated in Fig. 9, our frame- their ownership of specific software. Unlike a traditional
work is divided into two main parts: a registration phase blockchain that records cryptocurrency transactions, this
and a verification phase. Lets now zoom in on the dif- identity blockchain will record the software transactions,
ferent steps: (1) To register software, a developer must tracking software creation, transfer, and ownership. For
generate their public/ private key pairs and register their instance, if developer A is the first to declare he created
ownership of this software in the identities repository. software S, the identities blockchain will log this, prevent-
This is only possible if the software name does not exist; ing other developers from claiming ownership of software
otherwise, software ownership can only be transferred S. Ownership can only change if developer A creates a
from the current owner (see further in this section). (2) transaction to transfer it to another developer, such as
developer B. The software repository stores key details private repositories, we proposed traditional table struc-
about the software, such as hash values, creation time, tures and Merkle trees, which are more efficient and com-
and other identity information. Developers who own their putationally friendly. In addition, they avoid the need for
software can upload this information to the blockchain proof of work, reducing vulnerability to attacks from en-
as a reference for software users. The blockchain will tities with substantial computational power. As illustrated
deny the upload if a developer does not own the software. in Fig. 10, the framework includes two groups (software
Additionally, software users can verify a software library developers and software users) and two repositories (one
by comparing it with the reference information stored on for access control and another for software information),
the blockchain. Each transaction in both the identities and which are similar to the public system. As outlined in the
software repositories is designed to include at least the figure, our framework involves two main parts: registering
following elements: and verifying software information via logs. (1) To upload
For transfer of ownership: the software information, software developers are first
verified by the access control system. Developers may
1) Unique transaction id: A distinct identifier of the apply for permissions in advance or receive them automat-
transaction. ically based on company policies. The access control then
2) Timestamp: The time when the transaction was checks if the developers have the appropriate permissions
initiated. for the specified software. (2) Once verified, developers
3) Input public key: The public key of the current are allowed to upload the software information to the
software owner. logging server. (3) Software users who wish to verify
4) Output public key: The public key of the future software must communicate with the access control entity
software owner. to confirm their permissions. (4) After confirming their
5) Transactions: The specific software ownership. permissions, they can access software information from
6) Signature: A signature created with the input’s the logs.
private key.
For registering software in the repository:
1) Unique transaction id: A distinct identifier of the
transaction.
2) Timestamp: The time when the transaction was
initiated.
3) Owner public key: The public key of the software
owner.
4) Software name: Unique name of the software.
5) Version: The version of the software.
6) Hash value: Hash of this version of the software.
7) Optional: Some optional information.
8) Signature: A signature created with the owner’s
private key.

6.1.2. Certificate transparency-based solution. An al-

ternative strategy could be to reuse the concepts from
certificate transparency, including the use of monitors to
ensure the security of log servers. In our design, all stake-
holders can act as monitors. Software developers should Figure 10. Proposed framework for enhanced SBOM integrity with
Access Control
monitor the identities repository to verify the correctness
of their identities, such as public keys. Additionally, they To log software information, we use Merkle tree-
should monitor the software repository to detect any in- based repositories. A Merkle tree is a binary tree structure
correct or unauthorized software information. On the other consisting of numerous nodes, with the top-most node
hand, software users should monitor for any changes in known as the root and the bottom-most as leaf nodes.
the previously immutable software information, as the Software information is stored in the leaf nodes, and all
repository should be append-only and previous software other nodes, except for the leaves, contain hash values
information should remain unchanged. derived from the nodes below them. For instance, each
parent node has two child nodes and stores a hash value
6.2. Private repositories for reference hash values generated from these children. This setup ensures that
every node, except the leaves, represents a summary of all
Some companies require private repositories for their nodes beneath it. In this case, the root node summarizes all
software information due to privacy concerns. Motivated leaf nodes. Any modification to the software information
by certificate transparency, we proposed a solution tailored will alter the root hash, enabling users to efficiently verify
for private repositories, shown in Fig. 10. For private the software’s integrity by comparing multiple root hashes.
repositories, the number of participants is small and access The repository record includes:
control is managed internally. Therefore, using blockchain 1) Unique record ID: Unique identifier for this
to eliminate third-party access control is unnecessary. For record.
 2) User ID: Unique identifier for each user. million public repositories. According to the npm official
3) Software name: Unique name of the software. website in 2019, the average modern web application
4) Version: The version of software. has over 1000 dependencies. Thus, the estimated total
5) Hash value: Hash of software at this version. verification time for a user is (0.5 + 1.5) × 1000 ms = 2
6) Optional: Some optional information. seconds, which includes software hash verification in soft-
7) Timestamp: The time when this record was initi- ware blockchain and ownership verification in the iden-
ated. tities blockchain [47]. An SBOM verification process of
2 seconds is feasible, and further improvements could be
6.3. Feasibility achieved by caching frequently verified software hashes.
Similarly as for storage, there are no speed concerns for
We argue that it is feasible to deploy a decentralized the private repository, as it does not rely on blockchain
solution for storing and verifying reference information techniques and has significantly fewer participants and
of software libraries, including their hash values. As a software.
reference, we will refer to Bitcoin and Certificate Trans-
parency; both have been deployed on a global scale. 6.3.3. Registration Speed. Registration speed refers to
how quickly blocks are created in the identities and soft-
TABLE 2. T HE S IZE OF DATA E LEMENTS IN I DENTITY AND ware blockchain. To evaluate the registration speed, we
S OFTWARE R EPOSITORY collected the average confirmation time of Bitcoin over
three years, from June 2021 to June 2024 [48]. The maxi-
Item Size (byte)
Identity Repository mum, minimum, median, and average time were 25809, 5,
ID (SHA-256) 32 40, and 262 minutes, respectively. To avoid the influence
Timestamp 8 of the outliers, such as 25809 minutes, we used the median
Input Public Key (ECDSA-256) 32 value of 40 minutes as the expected confirmation time
Output Public Key (ECDSA-256) 32
Transactions Content 128 for our decentralized public repository system, which is
Signature (ECDSA) 64 an acceptable speed for a global reference system for
Total 296 software libraries.
Software Repository
ID (SHA-256) 32
Timestamp 8 7. Related Work
Owner Public Key (ECDSA-256) 32
Software Name 32
Version Number 8 This study is the first to comprehensively explore both
Hash Value 32 the theoretical and practical aspects of generating and
Signature (ECDSA) 64 consuming SBOMs to increase the supply-chain security.
Total 208
A notable study has introduced a blockchain frame-
work designed to improve SBOM sharing, featuring an
authoritative structure and a tree-based certificate sys-
6.3.1. Storage. For our decentralized public repository, tem. This framework capitalizes on the inherent integrity
the size of each transaction are shown in Table 2, where properties of blockchain technology, offering a potential
the total size of identities and software repositories are solution for SBOM sharing challenges [49]. However,
296 and 208 bytes, respectively. In 2023, Github reached issues remain with linking SBOMs to actual code, gen-
100 million developers and 284 million public repositories erating SBOMs with correct software hashes, and cor-
[45]. We assume that the average number of versions of rectly consuming SBOMs. MITRE ATT&CK proposed
each software is 10. Thus, using these numbers one gets an end-to-end framework for software supply chain in-
a total size for a full node of the identities blockchain of tegrity, inspired by the SolarWinds incident. It emphasizes
27.57 GB, and 550.15 GB for the software blockchain. standardizing SBOMs, improving signature infrastructure,
It should be mentioned that some public repositories on and enhancing automation, integration, and cryptographic
Github are documentation or resources instead of soft- traceability. Specifically, it advocates for strengthening
ware, meaning that the actual total size will be smaller. the generation and distribution process of SBOMs, high-
In comparison, the total size for a full node in Bitcoin lighting their critical importance [50]. L.J. Camp et al.
was 562.61 GB on 21st May 2024 [46]. Therefore, we assess the risks associated with SBOMs and the immediate
can conclude that the storage requirements for our frame- need for SBOM standardization. The authors argue that
work (27.57 GB and 550.15 GB) are manageable. For a without widespread adoption of robust protocol security,
decentralized private repository, storage requirements are SBOMs risk failing to meet their security promise [51].
expected to be significantly lower. Although both works emphasize the importance of SBOM
standardization and distribution, significant improvements
6.3.2. Verification Speed. Verification speed refers to in actual implementation are still required. In conclusion,
how quickly a software user can verify all the hashes current studies mainly focus on SBOM standardization
of the software entries in an SBOM using blockchain. and distribution, neglecting the generation and consump-
This process is similar to the ”check a transaction and the tion parts, e.g., a global software comparison table for
certificate” speed described in [43], which is 0.25 ms per SBOM.
verification. Based on this, we estimate a verification time In addition to SBOMs, various traditional methods,
of 0.5 ms and 1.5 ms for identity and software blocks, e.g., distribution of hash, threat modelling, software
respectively, considering the 100 million users and 300 composition analysis, are used in supply-chain security.
MITRE ATT&CK advises verifying complied code bi- detection of issues like outdated or malicious packages.
naries against known good hashes and using other in- Elena N. Akimova et al. review deep learning-based tech-
tegrity mechanisms to protect against software supply niques for software defect prediction, discussing current
chain injections. They suggest distributing the software’s challenges and future directions in this field [60]. Szymon
cryptographic hash through independent, trusted mecha- Stradowski et al. focused on predicting software defects
nisms accompanied by code signing [52]. The idea of in industrial applications through machine learning. They
comparing software hashes is similar to SBOM; however, review studies from 2015 to 2022, discussing the AI
it lacks a method for storing these known-good hashes. models, datasets, and costs associated with software defect
Our proposal also offers a secure framework for storing prediction in industry [61]. Most AI studies focus on
these known-good hashes. Jeong Yang et al. highlighted directly predicting defects from code, which can be too
four key mechanisms to detect or prevent software supply time-consuming and complex for consumers to verify
chain attacks: (1) Github’s Software Composition Anal- vulnerabilities in large applications. In contrast, SBOM
ysis (SCA) tools that identify and patch vulnerabilities consumption is more straightforward.
in open-source dependencies; (2) CISA’s CHIRP (CISA Instead of using AI in defect detection, people have
Hunt and Incident Response Program), which utilizes started to apply AI in SBOM. B. Xia et al. propose ”AI-
Indicators of Compromise (IoCs) to detect threats after BOMs,” an adaptation where traditional SBOMs, which
a compromise; (3) SootDiff, a tool that identifies code list software components, are extended to suit AI sys-
clones produced by different compliers using bytecode tems’ dynamic and evolving nature. AIBOMs specifi-
clone detection techniques; (4) The in-toto framework, cally address the challenges posed by AI systems like
which cryptographically secures the software supply chain reinforcement learning, which continuously evolves with
and enables end-users to verify all steps within the chain new data, by creating a tailored BOM for these dynamic
[53]. These mechanisms are similar to SBOM and will be environments [49]. Petar Radanliev et al. highlighted that
integrated with or replaced by SBOM with SBOM devel- technologies such as machine learning, including genera-
opment. Guanyi Lu et al. divided supply chain security tive pre-trained transformers and natural language process-
into four categories: detection, prevention, response, and ing, can automate processes in the SBOM consumption
mitigation. They operationalized these categories using with Vulnerability-Exploitability eXchange (VEX) [62].
various indicators to assess and explain the performance Heeyeon Kim et al. developed a binary classifier to iden-
of supply chain security across 462 firms in the United tify defective software before SBOM generation. By re-
States and Italy [54]. Naeem Firdous Syed et al. per- moving these defective software, the authors can produce
formed a STRIDE threat modeling analysis on SBOM an SBOM consisting solely of defect-free software [63].
traceability data, organizing it into four layers: applica- These mechanisms add a security layer before SBOM
tion, data sharing, data capture, and data carrier. The generation, while they do not address the issue of linking
authors describe common threats within these layers and SBOMs to the actual code.
offer countermeasures, helping stakeholders understand
and mitigate potential cybersecurity risks and vulnerabil- 8. Conclusion
ities [55]. Although threat modeling provides a general
security strategy, our proposal offers a detailed implemen-
Our work revealed several significant security weak-
tation for SBOM integrity in supply chain security. S.E.
nesses in the processes and tools for SBOM consumption
Chang et al. [56] and Pankaj Dutta et al. [57] reviewed
and generation currently widely used in practice. For
106 and 178 research articles, respectively, on blockchain
SBOM consumption, all the investigated tools, including
implementation in supply chains. Both studies enhance
the OWSAP dependency tracker, only rely on basic checks
understanding of blockchain applications in supply chain
of library names and versions and omit the verification of
management and offer a blueprint based on literature
hash values. For SBOM generation, we investigated the
analysis. Besides exploring blockchain applications, Sana
SBOM generation process for the seven most common
Al-Farsi et al. identified several challenges that impede the
programming languages and have shown that for all lan-
reliability and security of blockchain-based supply chain
guages except one, the SBOM file is generated merely
management (BC-SCM) systems, helping to establish the
based on library configuration files, hence disregarding
desired security of the BC-SCM [58]. Nevertheless, these
the actual code. Moreover, we discovered that none of the
works do not address blockchain applications for SBOM
tools enabled the signing of an SBOM by default dur-
integrity, and our study extends blockchain applications to
ing generation nor required SBOMs to be signed during
SBOM integrity.
consumption. To mitigate these issues, we propose a a
With the excellent performance of artificial intelli-
mitigation strategy that includes the decentralized storage
gence (AI), it is increasingly being used to enhance supply
of hash tables, either public or private, that explicitly links
chain security. Malka N. Halgamuge et al. explore state-
each entry in an SBOM to its corresponding software
of-the-art deep learning techniques to secure supply chains
library.
in the renewable energy industry. The authors highlight
key model design factors for combating adversarial threats
and detail various deep learning architectures, assessing Acknowledgements
their strengths and limitations in security applications
[59]. People also use various AI models to predict de- This work has been supported in part by CyberSecurity
fects in software, enhancing supply chain security. These Research Flanders with reference number VR20192203,
models are trained on large datasets of defective and by the Energy Transition Fund of the FPS Economy
defect-free code to predict software defects, enabling the of Belgium through the CYPRESS project, and by
the VLAIO COOCK program through the IIoT-SBOM [21] “Bomber Vulnerability Data Source,” https://github.com/
project. devops-kung-fu/bomber?tab=readme-ov-file#providers, last
Accessed: 15-10-2024.
[22] “CveBinTool Vulnerability Data Source,” https://github.com/intel/
References cve-bin-tool/blob/main/doc/MANUAL.md#data-sources, last Ac-
cessed: 15-10-2024.
[1] É. Ó. Muirı́, “Framing software component transparency: Estab-
[23] “Maven,” https://maven.apache.org/, last Accessed: 15-10-2024.
lishing a common software bill of material (sbom),” NTIA, Nov,
vol. 12, 2019. [24] “Npm,” https://docs.npmjs.com/about-npm, last Accessed: 15-10-
2024.
[2] S. Peisert, B. Schneier, H. Okhravi, F. Massacci, T. Benzel,
C. Landwehr, M. Mannan, J. Mirkovic, A. Prakash, and J. B. [25] “The Python Package Index,” hhttps://pypi.org/project/pip/, last
Michael, “Perspectives on the solarwinds incident,” IEEE Security Accessed: 15-10-2024.
& Privacy, vol. 19, no. 2, pp. 7–13, 2021.
[26] “Composer,” https://getcomposer.org/, last Accessed: 15-10-2024.
[3] NTIA, “SBOM at a Glance,” https://tinyurl.com/txyvbhfu, last
Accessed: 15-10-2024. [27] “Tiobe Index,” https://www.tiobe.com/tiobe-index/, last Accessed:
15-10-2024.
[4] The United States Department of Commerce, “The Minimum
Elements For a Software Bill of Materials (SBOM),” [28] CycloneDx Python, “CycloneDx Python,” https://github.com/
https://www.ntia.doc.gov/files/ntia/publications/sbom minimum CycloneDX/cyclonedx-python.
elements report.pdf, last Accessed: 15-10-2024. [29] CycloneDx Conan, “CycloneDx Conan,” https://github.com/
[5] “Roles and Benefits for SBOM Across the Supply Chain,” CycloneDX/cyclonedx-conan.
https://www.ntia.gov/sites/default/files/publications/ntia sbom [30] CycloneDx Maven, “CycloneDx Maven,” https://github.com/
use cases roles benefits-nov2019 0.pdf, last Accessed: 15-10- CycloneDX/cyclonedx-maven-plugin, last Accessed: 15-10-2024.
2024.
[31] CycloneDx Dotnet, “CycloneDx Dotnet,” https://github.com/
[6] White House, “Executive Order on Improving the CycloneDX/cyclonedx-dotnet, last Accessed: 15-10-2024.
Nation’s Cybersecurity,” https://www.whitehouse.
gov/briefing-room/presidential-actions/2021/05/12/ [32] CycloneDx Node Npm, “CycloneDx Node Npm,” https://github.
executive-order-on-improving-the-nations-cybersecurity/, last com/CycloneDX/cyclonedx-node-npm, last Accessed: 15-10-2024.
Accessed: 05-03-2024. [33] CycloneDx PHP Composer, “CycloneDx PHP Composer,” https:
[7] P. Hernandez, “Executive order 14028, improving the nation’s //github.com/CycloneDX/cyclonedx-php-composer, last Accessed:
cybersecurity,” 2021. 15-10-2024.
[8] Sonatype, “Biden executive order on cybersecurity calls for [34] “Syft,” https://github.com/anchore/syft, last Accessed: 23-05-2024.
enhanced software supply chain security,” https://tinyurl.com/
[35] CycloneDx Cona2n, “CycloneDx Conan2,” https://github.com/
ywuyuzck, last Accessed: 15-10-2024.
conan-io/conan-extensions#readme.
[9] European Parliament, “COMPROMISE AMENDMENT 1 -
[36] CycloneDx Core (Java), “CycloneDx Core (Java),” https://github.
CYBER RESILIENCE ACT,” https://www.europarl.europa.eu/
com/CycloneDX/cyclonedx-core-java, last Accessed: 15-10-2024.
meetdocs/2014 2019/plmrep/COMMITTEES/ITRE/DV/2023/
07-19/11-CA CRA EN.pdf, last Accessed: 15-10-2024. [37] CycloneDx Maven Configuration, “CycloneDx Maven Config-
[10] “SPDX Overview,” https://spdx.dev/about/overview/, last Ac- uration,” https://github.com/CycloneDX/cyclonedx-maven-plugin?
cessed: 15-10-2024. tab=readme-ov-file#maven-usage, last Accessed: 15-10-2024.

[11] “CycloneDx History,” https://cyclonedx.org/about/history/, last Ac- [38] B. Laurie, “Certificate transparency,” Communications of the ACM,
cessed: 15-10-2024. vol. 57, no. 10, pp. 40–46, 2014.

[12] S. Feng and M. Lubis, “Defense-in-depth security strategy in [39] ——, “Certificate transparency: Public, verifiable, append-only
log4j vulnerability analysis,” in 2022 International Conference logs,” Queue, vol. 12, no. 8, pp. 10–19, 2014.
Advancement in Data Science, E-learning and Information Systems [40] N. Van der Meulen, “Diginotar: Dissecting the first dutch digital
(ICADEIS). IEEE, 2022, pp. 01–04. disaster,” Journal of strategic security, vol. 6, no. 2, pp. 46–58,
[13] J. E. Akinsola, A. S. Ogunbanwo, O. J. Okesola, I. J. Odun- 2013.
Ayo, F. D. Ayegbusi, and A. A. Adebiyi, “Comparative analysis [41] S. Haber and W. S. Stornetta, How to time-stamp a digital docu-
of software development life cycle models (sdlc),” in Intelligent ment. Springer, 1991.
Algorithms in Software Engineering: Proceedings of the 9th Com-
puter Science On-line Conference 2020, Volume 1 9. Springer, [42] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”
2020, pp. 310–322. Satoshi Nakamoto, 2008.
[14] A. Mishra and D. Dubey, “A comparative study of different [43] Z. Wang, J. Lin, Q. Cai, Q. Wang, D. Zha, and J. Jing, “Blockchain-
software development life cycle models in different scenarios,” based certificate transparency and revocation transparency,” IEEE
International Journal of Advance research in computer science and Transactions on Dependable and Secure Computing, vol. 19, no. 1,
management studies, vol. 1, no. 5, 2013. pp. 681–697, 2020.
[15] “SBOM’s History,” https://www.ntia.doc.gov/files/ntia/ [44] D. Madala, M. P. Jhanwar, and A. Chattopadhyay, “Certificate
publications/uscc - 2021.06.17.pdf, last Accessed: 15-10-2024. transparency using blockchain,” in 2018 IEEE International Con-
ference on Data Mining Workshops (ICDMW). IEEE, 2018, pp.
[16] OWASP, “Dependency Track,” https://dependencytrack.org/, last 71–80.
Accessed: 05-03-2024.
[45] G. Korkmaz, J. B. S. Calderón, B. L. Kramer, L. Guci, and C. A.
[17] DevOps Kung Fu, “Bomber,” https://github.com/devops-kung-fu/ Robbins, “From github to gdp: A framework for measuring open
bomber, last Accessed: 15-10-2024. source software innovation,” Research Policy, vol. 53, no. 3, p.
[18] Intel Corporation, “cve bin tool,” https://github.com/intel/ 104954, 2024.
cve-bin-tool, last Accessed: 15-10-2024.
[46] “Blockchain Size (MB),” https://www.blockchain.com/explorer/
[19] “Grype,” https://github.com/anchore/grype, last Accessed: 22-05- charts/blocks-size/, last Accessed: 21-06-2024.
2024.
[47] “This year in JavaScript: 2018 in review and npm’s pre-
[20] “OWASP Dependency Track Vulnerability Data Source,” https:// dictions for 2019,” https://blog.npmjs.org/post/180868064080/
owasp.org/www-project-dependency-track/, last Accessed: 15-10- this-year-in-javascript-2018-in-review-and-npms/, last Accessed:
2024. 24-06-2024.
[48] “Average Confirmation Time,” https://www.blockchain.com/ [56] S. E. Chang and Y. Chen, “When blockchain meets supply chain: A
explorer/charts/avg-confirmation-time/, last Accessed: 23-06- systematic literature review on current development and potential
2024. applications,” Ieee Access, vol. 8, pp. 62 478–62 494, 2020.
[49] B. Xia, D. Zhang, Y. Liu, Q. Lu, Z. Xing, and L. Zhu, “Trust in [57] P. Dutta, T.-M. Choi, S. Somani, and R. Butala, “Blockchain tech-
software supply chains: Blockchain-enabled sbom and the aibom nology in supply chain operations: Applications, challenges and
future,” in Proceedings of the 2024 ACM/IEEE 4th International research opportunities,” Transportation research part e: Logistics
Workshop on Engineering and Cybersecurity of Critical Systems and transportation review, vol. 142, p. 102067, 2020.
(EnCyCriS) and 2024 IEEE/ACM Second International Workshop
on Software Vulnerability, 2024, pp. 12–19. [58] S. Al-Farsi, M. M. Rathore, and S. Bakiras, “Security of
blockchain-based supply chain management systems: challenges
[50] “Deliver Uncompromised: Securing Critical Software Supply and opportunities,” Applied Sciences, vol. 11, no. 12, p. 5585, 2021.
Chains,” https://tinyurl.com/ydxzcw78, last Accessed: 15-10-2024.
[59] M. N. Halgamuge, “Leveraging deep learning to strengthen the
[51] L. J. Camp and V. Andalibi, “Sbom vulnerability assessment & cyber-resilience of renewable energy supply chains: A survey,”
corresponding requirements,” NTIA Response to Notice and Re- IEEE Communications Surveys & Tutorials, 2024.
quest for Comments on Software Bill of Materials Elements and
Considerations, 2021. [60] E. N. Akimova, A. Y. Bersenev, A. A. Deikov, K. S. Kobylkin,
A. V. Konygin, I. P. Mezentsev, and V. E. Misilov, “A survey
[52] “Supply Chain Compromise: Compromise Software Supply
on software defect prediction using deep learning,” Mathematics,
Chain,” https://attack.mitre.org/techniques/T1195/002/, last Ac-
vol. 9, no. 11, p. 1180, 2021.
cessed: 15-10-2024.
[53] J. Yang, Y. Lee, and A. P. McDonald, “Solarwinds software [61] S. Stradowski and L. Madeyski, “Industrial applications of software
supply chain security: Better protection with enforced policies defect prediction using machine learning: A business-driven sys-
and technologies,” Software Engineering, Artificial Intelligence, tematic literature review,” Information and Software Technology,
Networking and Parallel/Distributed Computing 22, pp. 43–58, vol. 159, p. 107192, 2023.
2022. [62] P. Radanliev, “in software vulnerability management: automations
[54] G. Lu, X. Koufteros, and L. Lucianetti, “Supply chain security: in the software bill of materials (sbom) and the vulnerability-
A classification of practices and an empirical study of differential exploitability exchange (vex),” Authorea Preprints, 2023.
effects and complementarity,” IEEE Transactions on Engineering [63] H. Kim and K.-H. Kim, “Deep learning-based sbom defect de-
Management, vol. 64, no. 2, pp. 234–248, 2017. tection for medical devices,” in 2024 International Conference on
[55] N. F. Syed, S. W. Shah, R. Trujillo-Rasua, and R. Doss, “Trace- Artificial Intelligence in Information and Communication (ICAIIC).
ability in supply chains: A cyber security analysis,” Computers & IEEE, 2024, pp. 047–051.
Security, vol. 112, p. 102536, 2022.