A Software Bill of Materials (SBOM) is becoming an essential tool for effective software dependency management. An SBOM is a list of components used in software, including details such as component names, versions, and licenses. Using SBOMs, developers can quickly identify software components and assess whether their software depends on vulnerable libraries. Numerous tools support software dependency management through SBOMs, which can be broadly categorized into two types: tools that generate SBOMs and tools that utilize SBOMs. A substantial collection of accurate SBOMs is required to evaluate tools that utilize SBOMs. However, there is no publicly available dataset specifically designed for this purpose, and research on SBOM consumption tools remains limited. In this paper, we present a dataset of SBOMs to address this gap. The dataset we constructed comprises 46 SBOMs generated from real-world Java projects, with plans to expand it to include a broader range of projects across various programming languages. Accurate and well-structured SBOMs enable researchers to evaluate the functionality of SBOM consumption tools and identify potential issues. We collected 3,271 Java projects from GitHub and generated SBOMs for 798 of them using Maven with an open-source SBOM generation tool. These SBOMs were refined through both automatic and manual corrections to ensure accuracy, currently resulting in 46 SBOMs that comply with the SPDX Lite profile, which defines minimal requirements tailored to practical workflows in industries. This process also revealed issues with the SBOM generation tools themselves. The dataset is publicly available on Zenodo (DOI: 10.5281/zenodo.14233414).

Current software development takes advantage of many external libraries, but it entails security and copyright risks. While the use of the Software Bill of Materials (SBOM) has been encouraged to cope with this problem, its adoption is still insufficient. In this research, we analyzed the challenges that developers faced in practicing SBOM use by examining questions about SBOM utilization on Stack Overflow, a Q&A site for developers. As a result, we found that (1) the proportion of resolved questions about SBOM use is 15.0% which is extremely low, (2) the number of new questions has increased steadily from 2020 to 2023, and (3) SBOM users have three major challenges on SBOM tools.

Libraries have become integral to modern software development, yet their management often falls short, resulting in issues such as delayed responses to vulnerabilities. To address these issues, the use of a Software Bill of Materials (SBOM) is recommended. Despite the recommendation, there is a lack of tools supporting software management using SBOM. In this paper, we present “Osmy”, a tool designed to facilitate effective software management using SBOM in the SPDX format-one of the major SBOM formats. Osmy is designed to simplify and streamline 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 a proactive approach to software security. Osmy is available at https://github.com/higolab/Osmy.

Over the years, Stack Overflow (SO) has accumulated numerous code snippets, with developers going to SO for problem solutions and code references. However, in the case of the Python programming language, Python 3 is not necessarily backward compatible with Python 2. The major implication of this versioning problem is that code written in Python 2 may not be interpreted by Python 3 without modifications. This issue may affect the usability of Python code snippets on SO. We investigate how many Python code snippets on SO suffer from version compatibility issues, and find that about 10% of the snippets exhibit this problem. Moreover, of the code snippets that are interpretable only by Python 2 or Python 3, less than 17% are tagged with the Python version.In this paper, we present a Chrome extension called PyVerDetector. This extension allows the user to select a given version of Python and verifies whether the code snippets on a given SO question are compatible with the user’s selected Python version, providing error messages if not. The tool parses snippets and can determine versioning errors due to differences in syntax and also provides the user with a list of Python versions capable of interpreting each code snippet.

In this paper, as an example of comparing developer’s work efficiency between different editors, we propose a method to collect and compare self-evaluations and quantitative evaluations of developer’s work efficiency for each editor. We also practiced the proposed method on Visual Studio Code and Eclipse, and confirmed the applicability of the method.

One of the important purposes of code review is to find potential defects caused by other developers' code changes. When reviewing bug fixes, it is important to check the program behavior is properly changed to remove the bug. On the other hand, it is also important to check the program behavior that is not related to the bug is not changed. To investigate the program behavior, omniscient debugging which records all the runtime events is proposed. With omniscient debugging techniques, existing tools visualize multiple execution paths and the states of local variables of a method, but they are not focusing on code changes. In this paper, we implemented a prototype tool that compares and visualizes the difference between two execution traces caused by code changes. Each variable has a maximum of two lists of values, before and after the code changes, so we proposed their categorization based on their difference of length and contents. We also developed a viewer to show both code changes and the difference of execution traces at a glance by extending our previous viewer for omniscient debugging.

Logging is an important feature of a software system to record run-time information. Detailed logging allows developers to collect run-time information in situations where they cannot use an interactive debugger, such as continuous integration and web application server cases. However, extensive logging leads to larger execution traces because few instructions can be repeated many times. This paper presents our tool NOD4J, which monitors a Java program's execution within limited storage space constraints and annotates the source code with observed values in an HTML format. Developers can easily investigate the execution and share the report on a web server. We show two examples that our tool can debug defects using incomplete execution traces.

Logging is an important feature for a software system to record its run-time information. Detailed logging allows developers to collect information in situations where they cannot use an interactive debugger, such as continuous integration and web application server cases. However, extensive logging leads to larger execution traces because few instructions could be repeated many times. To record detailed program behavior within limited storage space constraints, we propose Near-Omniscient Debugging, a methodology that records an execution trace using fixed size buffers for each observed instruction. Our tool monitors a Java program's execution and annotates source code with observed values in an HTML format. Developers can easily investigate the execution and share the report on a web server. In case of DaCapo benchmark applications, our tool requires fewer than 1% of the complete execution traces to visualize all runtime values used by 66% of instructions that are executed less than 64 times. Developers also can obtain data dependencies with precision 91.8% and recall 79.0% using this tool.

When developing and maintaining a software project, many issues about bug fixing or feature addition are reported on the Bug Tracking System (BTS) and the Issue Tracking System (ITS). Bountysource is a web founding platform that awards developers who have solved issues on the BTS/ITS. Users can post a bounty for the issues, and a developer who solves the issue can get that bounty. This research analyzes Bountysource to clarify how bounties act in open source software projects and discusses further research topics in open-source bounties.

A software product is often dependent on a large number of third-party components. To assess potential risks, such as security vulnerabilities and license violations, a list of components and their versions in a product is important for release engineers and security analysts. Since such a list is not always available, a code comparison technique named Software Bertillonage has been proposed to test whether a product likely includes a copy of a particular component or not. Although the technique can extract candidates of reused components, a user still has to manually identify the original components among the candidates. In this paper, we propose a method to automatically select the most likely origin of components reused in a product, based on an assumption that a product tends to include an entire copy of a component rather than a partial copy. More concretely, given a Java product and a repository of jar files of existing components, our method selects jar files that can provide Java classes to the product in a greedy manner. To compare the method with the existing technique, we have conducted an evaluation using randomly created jar files including up to 1,000 components. The Software Bertillonage technique reports many candidates; the precision and recall are 0.357 and 0.993, respectively. Our method reports a list of original components whose precision and recall are 0.998 and 0.997.

The reuse of free and open source software (FOSS) components is becoming more and more popular. They usually contain one or more software licenses describing the requirements and conditions which should be followed when been reused. Licenses are usually written in the header of source code files as program comments. Removing or modifying the license header by re-distributors will result in the inconsistency of license with its ancestor, and may potentially cause license infringement. But to the best of our knowledge, no research has been devoted to investigate such kind of license infringements nor license inconsistencies. In this paper, we describe and categorize different types of license inconsistencies and propose a feasible method to detect them. Then we apply this method to Debian 7.5 and present the license inconsistencies found in it. With a manual analysis, we summarized various reasons behind these license inconsistencies, some of which imply license infringement and require the attention from the developers. This analysis also exposes the difficulty to discover license infringements, highlighting the usefulness of finding and maintaining source code provenance.

Source code is often reused in software development. Although developers can avoid re-implementing features in existing products, doing so may result in a large number of similar software products. To understand the commonalities and variabilities of similar products, comparing their source code is critical. However, a product may change its own directory structure, even if the products share the same source code with other products. Hence, comparing source code among products in a systematic manner is difficult. In this paper, we propose a technique to extract and visualize a unified directory tree to compare the source code of similar products. This tree includes all directories of given products and merges corresponding directories into a single node. Since a node in a tree corresponds to multiple directories in products, developers can easily compare the contents of products. In our study, we implemented the visualization as a GUI tool. In addition, we conducted a case study using four Android products to demonstrate the tool's ability to assist developers in accessing the source code of multiple products.

Developers often reuse source files developed for another project. In order to update a reused file to a newer version released by the original project, developers have to track which revision of a file was reused and how its content was modified. However, such tracking is tedious for developers. Many projects keep older versions of files whose bugs are already fixed in the original project. In this paper, we propose a technique to automatically identify source code reuse relationships between two repositories. Using a similarity metric based on longest common subsequence, we identify pairs of similar revisions of files across the repositories. To evaluate our approach, we have analyzed eight project pairs of open source software projects and compared the result with the recorded information in the repositories. As a result, we have identified 1394 file revisions as instances of source code reuse. While 75.3% of the instances are recorded in the repositories, 20.1% of the instances are unrecorded but recovered by our approach.

A large number of software products may be derived from an original single product. Although software product line engineering is advocated as an effective approach to maintaining such a family of products, re-engineering existing products requires developers to understand the evolution history of the products. This can be challenging because developers typically only have access to product source code. In this research, we propose to extract a Product Evolution Tree that approximates the evolution history from source code of products. Our key idea is that two successive products are the most similar to one another in the evolution history. We construct a Product Evolution Tree as a minimum spanning tree whose cost function is defined by the number of similar files between products. As an experiment, we extracted Product Evolution Trees from 6 datasets of open-source projects. The result showed that 53% to 92% of edges in the extracted trees were consistent with the actual evolution history of the projects.