Osmy: A Tool for Periodic Software Vulnerability
Assessment and File Integrity Verification using
SPDX Documents
Rio Kishimoto∗ , Tetsuya Kanda∗ , Yuki Manabe† , Katsuro Inoue‡ , Yoshiki Higo∗∗ Osaka University, Japan, {r-kisimt, t-kanda, higo}@ist.osaka-u.ac.jp† The University of Fukuchiyama, Japan, manabe-yuki@fukuchiyama.ac.jp‡ Nanzan University, Japan, inoue599@nanzan-u.ac.jp

Abstract—Libraries have become integral to modern softwaredevelopment, yet their management often falls short, resulting
in issues such as delayed responses to vulnerabilities. To addressthese issues, the use of a Software Bill of Materials (SBOM)
is recommended. Despite the recommendation, there is a lackof tools supporting software management using SBOM. In thispaper, we present “Osmy”, a tool designed to facilitate effective
software management using SBOM in the SPDX format—oneof the major SBOM formats. Osmy is designed to simplify andstreamline SBOM-based software management for end users. It
automates vulnerability assessment and file integrity verification,
operating periodically to ensure continuous protection. Users
receive timely notification of any identified issues, ensuring aproactive approach to software security. Osmy is available athttps://github.com/higolab/Osmy.
Index Terms—SBOM, SPDX, vulnerability

I. I NTRODUCTION
In modern software development, developers use third-party
libraries to efficiently reuse common functionalities between
software projects. While the use of a library has the advantageof shortening development time and reducing development
costs, it also has the disadvantage of incorporating defects contained in the library [10], [18]. Defects affecting the securityof software are called vulnerabilities. When a vulnerability
is discovered, it is necessary to quickly update software toa non-vulnerable version. However, delays and omissions in
responding to vulnerabilities have become a problem because
the management of third-party libraries used in the project
is not enough [1], [7]. Taking the popular Java-based logging
library Log4j as an example, a serious vulnerability was foundin 2021 [4]. As of the November 2023 statistics, approximately
20% of Log4j downloads in the past month across multiple
countries still comprised outdated versions, persisting with thisidentified vulnerability [11].
To address these problems, the use of a Software Bill ofMaterials (SBOM) is recommended [17]. An SBOM is adocument that describes the elements such as packages anddocumentation that make up a particular piece of software,
their licenses, and the relationships among the elements.
SPDX [12] is one of the open standards for SBOM, andan SBOM described according to SPDX is called an SPDX
document. Utilizing the information described in an SPDX
document, we can scan vulnerabilities in a piece of softwareand the libraries where it depends. Additionally, we can verify
the integrity of its files to ensure the validity of the vulnerability assessment based on the SPDX document. Thus, SPDX
documents are valuable for effective software management.
However, despite the benefits of utilizing SPDX documents
for software management, there is currently a lack of tools
to support this process [20]. In particular, tools for software
end users are lacking. In this paper, we present a tool
called “Osmy”, which makes vulnerability assessment andfile integrity verification based on the information on SPDX
documents easier and more labor-saving for software end
users.
II. O SMY: OVERVIEWOsmy is a tool that performs periodic vulnerability assessment and file integrity verification of software based on
SPDX documents as shown in Fig. 1. Osmy consists of aserver program and CLI/GUI clients. The server program has
a list of software that is managed by Osmy using SPDX
documents. It performs a vulnerability assessment and a file
integrity verification periodically based on the information
in SPDX documents. It also notifies users of those resultsby e-mail. The CLI/GUI clients provide a user interface toregister/update SPDX documents that are used to perform
vulnerability assessments and file integrity verifications. They
also provide a user interface to check those results.
In the following, we explain the methods of vulnerability
assessment and file integrity verification on the server side, andhow to notify users of those results. Client-side functionality
is described in Section III along with a usage scenario.
A. Vulnerability Assessment
Osmy performs vulnerability assessment in two steps: 1)
identification of dependent packages, 2) retrieval of vulnerability information.

Osmy Client

SoftwareInformation

Osmy Server

SPDX

Add
Software
Software
List

User

Automatic Periodic
Execution
File Integrity
Verification

Package
Information

Vulnerability
Assessment

ResultCheck

Code. 1E XAMPLE OF RELATIONSHIPS INFORMATION BETWEEN SPDX ELEMENTS

Vulnerability
OSV
Information （Vuln DB）

Results
Notification

Results

Fig. 1. Overview of Osmy

1
2
3
4
5
6
7
8
9
10

{
"relationshipType": "DEPENDS_ON","spdxElementId": "SPDXRef-RootPackage","relatedSpdxElement": "SPDXRef-Package-log4net"},{"relationshipType": "DEPENDS_ON","spdxElementId": "SPDXRef-Package-log4net","relatedSpdxElement": "SPDXRef-Package-System.Xml.Xml
Document"}

Package A
eab

Package

Package B
ebe

Package F
ef g

ebc

SPDXRefRootPackage

Package

Depends on

SPDXRefPackage-log4net

Package

Depends on

SPDXRefPackage-System.
Xml.XmlDocument

edb
Package E

Package C

Package G
ecd

Fig. 3. Relationship described in Code. 1

egd

Package D

Fig. 2. Example of a dependency graph1) Identification of dependent packages: Software dependencies consist of runtime dependencies and developmenttime dependencies (e.g. packages that only a testing processdepends on). An SPDX document can include information
about packages that are development-time dependencies aswell as information about packages that are runtime dependencies. Vulnerabilities within runtime dependencies impact
software vulnerabilities during runtime, whereas those withindevelopment-time dependencies do not. Therefore, Osmy identifies runtime dependencies of a piece of software by utilizing
a dependency graph.
A dependency graph is a directed graph representing dependencies between packages. A vertex represents a package anda directed edge represents dependency between two packages.
An example of a dependency graph is shown in Fig. 2. Whenone package directly or indirectly depends on another package,there is a path between two packages in a dependency graph.
For example, in Fig. 2, there is a directed edge eab from
Package A to Package B, and it means Package A directly
depends on Package B. Also, since there is no path from
Package A to Package G, Package A does not depend directly
or indirectly on Package G.
Osmy creates a dependency graph from relationship information described in an SPDX document. Code. 1 shows anexample of a part of an SPDX document in JSON format
that describes relationships between elements. In this example, the relationships shown in Fig. 3 are described. In an
SPDX document, a relationship is described using the type of
relationship and the IDs of the two elements involved. The
relationship described in lines 1 through 5 of the Code. 1 saysa package (SPDXRef-RootPackage) depends (DEPENDS) on
another package (SPDXRef-Package-log4net). Lines 6 through10 indicate that the package (SPDXRef-Package-log4net) depends (DEPENDS) on another package (SPDXRef-Package-

System.Xml.XmlDocument). Using this information, Osmycreates a dependency graph in two steps. First, it adds all
packages whose information is described in an SPDX document as vertices of a graph. Next, it adds edges to thegraph based on relationship information in the document.
In this step, only relationships whose types indicate runtime
dependencies are processed, and relationships whose types
indicate development-time dependencies are ignored. The
types of relationships that indicate runtime dependencies areshown in Table I, Table II, and Table III. Dependent packages
are identified in the graph by a depth-first search from thesoftware’s own package (hereafter simply referred to as a root
package). Packages visited during a search are identified assoftware’s runtime dependencies because they have paths froma root package.
2) Retrieval of vulnerability information: For each identified package that is a runtime dependency, Osmy checks
whether the package contains a vulnerability or not by querying the OSV database [5], which is a database that stores
OSS vulnerabilities. The OSV database is queried via HTTP
communication with the officially provided OSV API. Osmy
fetches vulnerability information of packages by sending arequest to the OSV batch execution API, which performs up to
1000 vulnerability information queries at once, with the name

TABLE IR ELATIONSHIPS THAT A MAY INHERIT A VULNERABILITY THAT B
CONTAINS

Relationship

Description

CONTAINSDYNAMIC LINKEXPANDED FROM ARCHIVE
FILE ADDED
GENERATED FROMPATCH FORSTATIC LINK
HAS PREREQUISITE
DEPENDS ON

A contains B
A dynamically links to B
A is expanded from the archive B
A is a file that was added to B
A was generated from B
A is a patch file for B
A statically links to B
A has as a prerequisite B
A depends on B

TABLE IIR ELATIONSHIPS THAT B MAY INHERIT A VULNERABILITY THAT A CONTAINS
Relationship

Description

CONTAINED BY
DISTRIBUTION ARTIFACT
GENERATESOPTIONAL COMPONENT OF
PATCH APPLIED
PREREQUISITE FOR
DEPENDENCY OF
OPTIONAL DEPENDENCY OF
RUNTIME DEPENDENCY OF

A is contained by B
distributing A requires that B also be distributed
A generates B
A is an optional component of B
A is a patch file that has been applied to B
A is a prerequisite for B
A is a dependency of B
A is an optional dependency of B
A is a dependency required for the execution of B

TABLE IIIR ELATIONSHIPS THAT IF ONE IS VULNERABLE , THEN THE OTHER MAY

Code. 2
E XAMPLE OF FILE INFORMATIONALSO BE VULNERABLE

Relationship

Description

COPY OFPACKAGE OFVARIANT OF

A is an exact copy of B
A is used as a package as part of B
A is a variant of B

and version of the packages. In addition, since popular libraries
appear in multiple SPDX documents, queries for packages
with the same name and version are combined into a single
query to reduce the number of queries.
B. File Integrity Verification
Osmy checks for tampering and corruption in software files
by verifying the checksum of each file. This ensures thecontent of an SPDX document matches the information of
the corresponding installed software.
Osmy verifies the checksum of each file using the information described in a file information section of an SPDX
document. This section lists the files composing a pieceof software, along with the name and checksum for eachfile. Code. 2 shows an example of the section in an SPDX
document in JSON format. This example shows the information of a file whose name is log4net.dll, and the checksum
calculated with SHA-1 is written. The SPDX format permits
the inclusion of multiple hash values, computed using different
algorithms, as the checksum of a file. Specifically, the SHA-1
hash value must be specified. Osmy verifies the integrity of afile by comparing the SHA-1 hash value recorded in the fileinformation of an SPDX document with the one calculated
from the actual file on the system. A mismatch indicatespotential tampering or corruption.
C. Notification to Users
Osmy conducts periodic vulnerability assessments and file
integrity verifications, saving the results in a database. Users
can customize the execution intervals for these processes
in Osmy’s configuration file. If the user configures e-mailnotification settings, Osmy sends results to the user by e-mailwhen a vulnerability or file integrity error is detected. The
e-mail message provides a summary of the vulnerability assessment or the file integrity verification. When Osmy detects

1
2
3
4
5
6
7
8
9
10
11
12
13

{
"fileName": "./log4net.dll","SPDXID": "SPDXRef-File--log4net.dll","checksums": [{"algorithm": "SHA1","checksumValue": "40fdba136f864c8a2f3e3f9c9e3949
f7582a6077"}],"licenseConcluded": "NOASSERTION","licenseInfoInFiles": [ "NOASSERTION" ],"copyrightText": "NOASSERTION"}

a vulnerability, the message includes the number and names ofvulnerable software, and when it detects a file integrity error,
the message includes the number and names of software withfile integrity errors. By notifying users when a problem isfound, Osmy helps the user to respond to the problem as soon
as possible.
III. I LLUSTRATIVE U SAGE S CENARIO
In this section, we present a usage instance of Osmy todetect vulnerabilities and file integrity errors in software.
Additionally, we describe the functionality of Osmy’s client
programs along with a usage scenario. As detailed in Section II, Osmy has two client programs: a GUI client and a
CLI client. Users have the flexibility to utilize either or bothto add software for management within Osmy. In this scenario,
the user uses the GUI client.
A. Usage ScenarioFirst, the user configures Osmy. The user sets automatic execution intervals of vulnerability assessment and file integrity
verification and e-mail notification settings in the configuration
file of Osmy. After configuration, the user starts the server
program of Osmy.
Next, the user adds software to the list of managed software.
The user uses a client program of Osmy to add software to
the list. The GUI client is shown in Fig. 4. The user can add
software to the list by clicking the “Add” button in the lowerleft corner of the window. When the user clicks the “Add”
button, a dialog to enter software information is displayed(Fig. 5). The user enters a display name of the software, atains a vulnerability whose IDs are GHSA-8g2p-5pqh-5jmc
and CVE-2022-41064.
2) File Integrity Errors: Fig. 7 shows the client after selecting the software with file integrity errors. In the “Files” tab,the status of a file is indicated by an icon next to the file name.
The green file icon means that the file checksum matches
the legitimate checksum written in the SPDX document. The
yellow file icon means that the file checksum does not match
it, and the dotted file icon means that the file does not exist
nevertheless the SPDX document contains its information. In
this example, ILSpy.dll is corrupted and AvalonDock.dll is
missing.
IV. R ELATED W ORK

Fig. 4. GUI clientFig. 5. Dialog to add software

path to an SPDX document of the software, and a path to thedirectory where the software is located in the dialog. After
filling in the dialog, the user clicks the “OK” button to add
the software to the list. In this use case, the user adds fivesoftware (ILSpy1 , jellyfin2 , ScreenToGif3 , ShareX4 , v2rayN5 ).
Added software is displayed in the software list on the left
side of the window, and Osmy executes initial vulnerability
assessment and file integrity verification for them.
B. Detected Vulnerabilities and File Integrity Errors
In this section, we illustrate some instances of detectedvulnerabilities and file integrity errors. Fig. 4 shows the client
when Osmy manages the five software. On the left side of thewindow, the list of software displays a red bug icon next to thename of vulnerable software. Similarly, if a piece of software
has file integrity errors, a yellow file icon is shown next to its
name. In this case, the user can see that three software containvulnerabilities and one software has file integrity errors. By
selecting a piece of software in the list, the user can checkdetailed information about it.
1) Vulnerabilities: Fig. 6 shows the client after selecting thesoftware with vulnerabilities. In the “Packages” tab, packages
containing vulnerabilities are highlighted in red in the list of
packages. In this example, one of the dependent packages of
ScreenToGif: System.Data.SqlClient with version 4.8.3 con1 https://github.com/icsharpcode/ILSpy/tree/2ef324515
2 https://github.com/jellyfin/jellyfin/tree/cc3d087
3 https://github.com/NickeManarin/ScreenToGif/tree/867c5f6
4 https://github.com/ShareX/ShareX/tree/d491b1f
5 https://github.com/2dust/v2rayN/tree/5ceb638

OSV-Scanner [6] and spdx-to-osv [13] are command line
tools to perform vulnerability assessment based on information in SPDX documents, which can be easily incorporated
into CI/CD pipelines. Dependency-Track [14] is a software
composition analysis tool, which leverages SBOMs written in
CycloneDX [9] format. These tools are designed for softwaredevelopers to manage dependent packages of their software
projects in their development process. In this paper, we described Osmy, which is designed for software end users andprovides features for them such as GUI, periodic execution,and notifications. SBOM’s states of practice and challenges
have been investigated in [3], [8], [15], [16], [20], and Balliu etal. have investigated the maturity of SBOM producers for Javaprojects in [2]. Wermke et al. have discussed security challenges introduced by adopting open-source components [19].
V. S UMMARY
In this paper, we presented “Osmy”, which automatically
performs software vulnerability assessment and file integrity
verification using SPDX documents periodically. We demonstrated the use of Osmy to detect vulnerabilities and file
integrity errors in software. We have future work to assess
the effectiveness of Osmy by evaluating its performance andusability when managing a larger number of SPDX documents
and to improve the user interface to help users prioritize
vulnerabilities.
Acknowledgements
This work was supported by JSPS KAKENHI Grant
Numbers
JP23H03375,
JP21K02862,
JP19K20239,
JP20H04166, JP21K18302, JP21K11829, JP21H04877,
JP22H03567, JP22K11985, and Nanzan University Pache
Research Subsidy I-A-2 for the 2023 academic year.
R EFERENCES[1] M. Alfadel, D. E. Costa, and E. Shihab, “Empirical Analysis of Security
Vulnerabilities in Python Packages,” in Proceedings of the 2021 IEEE
International Conference on Software Analysis, Evolution and Reengineering (SANER), 2021, pp. 446–457.
[2] M. Balliu, B. Baudry, S. Bobadilla, M. Ekstedt, M. Monperrus, J. Ron,
A. Sharma, G. Skoglund, C. Soto-Valero, and M. Wittlinger, “Challengesof Producing Software Bill of Materials for Java,” IEEE Security &Privacy, pp. 2–13, 2023.

Fig. 6. Packages Tab

Fig. 7. Files Tab[3] T. Bi, B. Xia, Z. Xing, Q. Lu, and L. Zhu, “On the Way to
SBOMs: Investigating Design Issues and Solutions in Practice,” 2023,
arXiv:2304.13261.
[4] CISA, “Mitigating Log4Shell and Other Log4j-Related Vulnerabilities,”
2021, accesed on 4 November 2023. [Online]. Available: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a[5] Google, “OSV: Open source vulnerability DB and triage service,” https://osv.dev/.
[6] ——, “OSV-Scanner,” https://github.com/google/osv-scanner, accesed
on 4 November 2023.
[7] R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Dodevelopers update their library dependencies?” Empirical Software
Engineering, vol. 23, no. 1, pp. 384–417, Feb. 2018. [Online].
Available: https://doi.org/10.1007/s10664-017-9521-5[8] S. Nocera, S. Romano, M. D. Penta, R. Francese, and G. Scanniello,“Software Bill of Materials Adoption: A Mining Study from GitHub,”in Proceedings of the 2023 IEEE International Conference on Software
Maintenance and Evolution (ICSME), 2023, pp. 39–49.
[9] OWASP Foundation, “OWASP CycloneDX Software Bill of Materials(SBOM) Standard,” https://cyclonedx.org/.
[10] O. P. N. Slyngstad, A. Gupta, R. Conradi, P. Mohagheghi, H. Rønneberg,
and E. Landre, “An Empirical Study of Developers Views on Software

Reuse in Statoil ASA,” in Proceedings of the 2006 ACM/IEEE International Symposium on Empirical Software Engineering (ISESE), 2006,
pp. 242–251.
[11] Sonatype, “Log4j Updates and Vulnerability Resources,” accesed on
4 November 2023. [Online]. Available: https://www.sonatype.com/
resources/log4j-vulnerability-resource-center[12] SPDX Workgroup, “About - Software Package Data Exchange (SPDX),”
https://spdx.dev/about.
[13] ——, “spdx-to-osv: Produce an Open Source Vulnerability JSON file
based on information in an SPDX document,” https://github.com/spdx/
spdx-to-osv, accesed on 4 November 2023.
[14] S. Springett, “Dependency-Track: an intelligent Component Analysis platform that allows organizations to identify and reduce riskin the software supply chain,” https://github.com/DependencyTrack/
dependency-track.
[15] T. Stalnaker, N. Wintersgill, O. Chaparro, M. D. Penta, D. M. German,
and D. Poshyvanyk, “BOMs Away! Inside the Minds of Stakeholders:
A Comprehensive Study of Bills of Materials for Software Systems,”
2023, accepted to ICSE2024.
[16] The Linux Foundation, “The State of Software Bill of Materials(SBOM) and Cybersecurity Readiness,” 2022, accesed on 4 November
2023. [Online]. Available: https://www.linuxfoundation.org/research/
the-state-of-software-bill-of-materials-sbom-and-cybersecurity-readiness[17] The White House, “Executive Order on Improving the Nation’s
Cybersecurity,” 2021, accesed on 4 November 2023. [Online]. Available: https://www.whitehouse.gov/briefing-room/presidential-actions/
2021/05/12/executive-order-on-improving-the-nations-cybersecurity/[18] Y. Wang, B. Chen, K. Huang, B. Shi, C. Xu, X. Peng, Y. Wu,
and Y. Liu, “An Empirical Study of Usages, Updates and Risks ofThird-Party Libraries in Java Projects,” in Proceedings of the 2020
IEEE International Conference on Software Maintenance and Evolution(ICSME), 2020, pp. 35–45.
[19] D. Wermke, J. H. Klemmer, N. Wöhler, J. Schmüser, H. S. Ramulu,
Y. Acar, and S. Fahl, ““Always Contribute Back”: A Qualitative Studyon Security Challenges of the Open Source Supply Chain,” in 2023
IEEE Symposium on Security and Privacy (SP), 2023, pp. 1545–1560.
[20] B. Xia, T. Bi, Z. Xing, Q. Lu, and L. Zhu, “An Empirical Study on
Software Bill of Materials: Where We Stand and the Road Ahead,” inProceedings of the 2023 IEEE/ACM 45th International Conference on
Software Engineering (ICSE), 2023, pp. 2634–2646.