Modern programming languages such as Java, JavaScript, and Rust encourage software reuse by hosting diverse and fast-growing repositories of highly interdependent packages (i.e., reusable libraries) for their users. The standard way to study the interdependence between software packages is to infer a package dependency network by parsing manifest data. Such networks help answer questions such as “How many packages have dependencies to packages with known security issues?” or “What are the most used packages?”. However, an overlooked aspect in existing studies is that manifest-inferred relationships do not necessarily examine the actual usage of these dependencies in source code. To better model dependencies between packages, we developed Präzi, an approach combining manifests and call graphs of packages. Präzi constructs a dependency network at the more fine-grained function-level, instead of at the manifest level. This paper discusses a prototypical Präzi implementation for the popular system programming language Rust. We use Präzi to characterize Rust’s package repository, Crates.io, at the function level and perform a comparative study with metadata-based networks. Our results show that metadata-based networks generalize how packages use their dependencies. Using Präzi, we find packages call only 40% of their resolved dependencies, and that manual analysis of 34 cases reveals that not all packages use a dependency the same way. We argue that researchers and practitioners interested in understanding how developers or programs use dependencies should account for its context—not the sum of all resolved dependencies.@en

Developers are increasingly using services such as Dependabot to automate dependency updates. However, recent research has shown that developers perceive such services as unreliable, as they heavily rely on test coverage to detect conflicts in updates. To understand the prevalence of tests exercising dependencies, we calculate the test coverage of direct and indirect uses of dependencies in 521 well-tested Java projects. We find that tests only cover 58% of direct and 21% of transitive dependency calls. By creating 1,122,420 artificial updates with simple faults covering all dependency usages in 262 projects, we measure the effectiveness of test suites in detecting semantic faults in dependencies; we find that tests can only detect 47% of direct and 35% of indirect artificial faults on average. To increase reliability, we investigate the use of change impact analysis as a means of reducing false negatives; on average, our tool can uncover 74% of injected faults in direct dependencies and 64% for transitive dependencies, nearly two times more than test suites. We then apply our tool in 22 real-world dependency updates, where it identifies three semantically conflicting cases and three cases of unused dependencies that tests were unable to detect. Our findings indicate that the combination of static and dynamic analysis should be a requirement for future dependency updating systems.@en

Modern software projects consist of more than just code: teams follow development processes, the code runs on servers or mobile phones and produces run time logs and users talk about the software in forums like StackOverflow and Twitter and rate it on app stores. Insights stemming from the real-time analysis of combined software engineering data can help software practitioners to conduct faster decision-making. With the development of CodeFeedr, a Real-time Software Analytics Platform, we aim to make software analytics a core feedback loop for software engineering projects. CodeFeedr's vision entails: (1) The ability to unify archival and current software analytics data under a single query language, and (2) The feasibility to apply new techniques and methods for high-level aggregation and summarization of near real-time information on software development. In this paper, we outline three use cases where our platform is expected to have a significant impact on the quality and speed of decision making; dependency management, productivity analytics, and run-time error feedback.@en

A popular form of software reuse is the use of open source software libraries hosted on centralized code repositories, such as Maven or npm. Developers only need to declare dependencies to external libraries, and automated tools make them available to the workspace of the project. Recent incidents, such as the Equifax data breach and the leftpad package removal, demonstrate the difficulty in assessing the severity, impact and spread of bugs in dependency networks. While dependency checkers are being adapted as a counter measure, they only provide indicative information. To remedy this situation, we propose a fine-grained dependency network that goes beyond packages and into call graphs. The result is a versioned ecosystem-level call graph. In this paper, we outline the process to construct the proposed graph and present a preliminary evaluation of a security issue from a core package to an affected client application.@en

Blockchain technology has found a great number of applications, from banking to the Internet of Things (IoT). However, it has not yet been envisioned whether and which problems in Software Engineering (SE) Blockchain technology could solve. In this paper, we coin this field 'Blockchain-based Software Engineering' and exemplify how Blockchain technology could solve two core SE problems: Continuous Integration (CI) Services such as Travis CI and Package Managers such as apt-get. We believe that Blockchain technology could help (1) democratize and professionalize Software Engineering infrastructure that currently relies on free work done by few volunteers, (2) improve the quality of artifacts and services, and (3) increase trust in ubiquitously used systems like GitHub or Travis CI.@en

Developers strategically reuse code to expedite project development and lower maintenance costs. With the advent of software supply chains, integrating open-source libraries into projects has transitioned from a cumbersome, manual task to an automated, streamlined process. However, this ease of integration has downsides; adding just one library can typically bring in multiple others, each following different coding standards and maintenance protocols. This layer of complexity significantly impedes the effective monitoring and evaluation of security vulnerabilities and breaking changes stemming from these external libraries in software projects. To mitigate these challenges, developers use various tools to oversee and react to software supply chain activities. However, these tools frequently result in a high rate of false positives and are often not insightful, primarily because they rely on metadata from build manifests. This thesis proposes call-based reachability analysis to enhance comprehension and precision by treating source code as first-class citizens in software supply chain analysis. Initially, we generate function call graphs for package releases, forming a call-based dependency network. We then compare such networks with manifest inferred networks to understand better their similarities and differences in approximating package relationships. The next phase of the thesis explores third-party library updates. Here, we examine the extent to which project test suites cover third-party functionality, followed by applying code-based reachability analysis to augment code areas lacking test coverage. Finally, we investigate the reuse of imported third-party library code in software projects, providing insights for developers and organizations to benchmark and question their reliance on imported third-party code over first-party code. Our results demonstrate that reachability analysis based on build manifest inferred networks often tends to overestimate transitive package relationships compared to call-based networks, overlooking the specific usage patterns of third-party libraries in projects. Software projects typically utilize only a portion of the functionalities from a third-party library, a pattern that also extends to dependent third-party libraries. Tools relying on manifest-inferred data incorrectly infer that projects use all functionalities of imported third-party libraries. This results in false alarms when identifying software supply chain issues like security vulnerabilities. Similarly, tools that automate third-party library updates also assume that project test suites can detect regressions effectively. Project tests often fail to cover all functionalities from a third-party library, leading to approved updates where changes are unchecked. Finally, while most projects are aware of importing a large number of third-party libraries, we observe that the reuse of imported libraries remains relatively low, raising critical questions about how organizations should strategically balance third-party versus first-party code, especially in light of the risks inherent in software supply chains.@en