No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Abstract
Software reuse is finally here but comes with risks.
... Cyberattacks targeting open source packages in the software supply chain have seen a rapid surge in recent times [1]. While modern software increasingly depends on open source packages [2], vulnerabilities in dependency packages can pose a security risk [3], [4]. Consequently, scrutiny from security researchers and bug bounty hunters has resulted in a continuous discovery of new vulnerabilities in the open source ecosystem [5]. ...
... Prior work has investigated the dependency network of package ecosystems and the phenomenon of outdated dependencies [7], [23], [24], [25], [26], [27], [28], [29], [30]. While open source dependencies in software projects bring about the benefit of code reuse [3], they also come with security risks in the form of known and unknown vulnerabilities [4], [9], [31], [32], [33]. Therefore, managing the security risk of open source packages in the software supply chain is an area of active research [3], [34]. ...
... While open source dependencies in software projects bring about the benefit of code reuse [3], they also come with security risks in the form of known and unknown vulnerabilities [4], [9], [31], [32], [33]. Therefore, managing the security risk of open source packages in the software supply chain is an area of active research [3], [34]. ...
Vulnerabilities in open source packages can be a security risk for the client projects that use these packages as dependencies. When a new vulnerability is discovered in a package, the package should quickly release a fix in a new version, referred to as security release in this study. The security release should be well-documented and require minimal migration effort to facilitate fast adoption by the client projects. However, to what extent the open source packages follow these recommendations is not known. The goal of this study is to aid software practitioners and researchers in understanding the current practice of releasing security fixes by open source packages and identifying areas for improvement through an empirical study of security releases. Specifically, in this paper, we study (1) the time lag between fix and release; (2) how security fixes are documented in the release notes; (3) code change characteristics (size and semantic versioning) of the release; and (4) the time lag between the release and an advisory publication on Snyk or NVD (two popular vulnerability databases) for security releases over a dataset of 4,377 security advisories across seven package ecosystems. We find that the median security release is available in under 4 days of the corresponding fix and contains 134 lines of code (LOC) change. Further, we find that 61.5% of the security releases come with a release note that documents the corresponding security fix. However, Snyk and NVD may take a median of 25 days (from the release) to publish an advisory for these security releases, possibly resulting in delayed notification to the client projects. Based on our findings, we make four recommendations for the package maintainers and the ecosystem administrators, such as using private fork for security fixes and standardizing the practice for announcing security releases.
... The past decades have seen the emergence of online software repositories hosting thousands, sometimes millions, of software artifacts ready for reuse [1]. Package managers that automate library resolution from these repositories have greatly facilitated the practice [2]. Increasingly, modern software consists, in a majority of external libraries glued together by a minority of business specific code directly written by the developer [3]. ...
... Bugs [4], breakages [5], and supply chain attacks [6], [7] can now occur in all the dependencies of an application and not solely in the code controlled by the application developer. For example, in March 2016, the removal of the left-pad package from the NPM registry broke the build of thousands of JavaScript projects [5], [2]. More recently, thousands of SolarWinds customers have been compromised through a malicious update. ...
... Package managers automatically fetch third-party libraries from a repository and integrate them into applications [1], [2]. There exist package managers and an associated repository for most programming languages. ...
Despite its obvious benefits, the increased adoption of package managers to automate the reuse of libraries has opened the door to a new class of hazards: supply chain attacks. By injecting malicious code in one library, an attacker may compromise all instances of all applications that depend on the library. To mitigate the impact of supply chain attacks, we propose the concept of Library Substitution Framework. This novel concept leverages one key observation: when an application depends on a library, it is very likely that there exists other libraries that provide similar features. The key objective of Library Substitution Framework is to enable the developers of an application to harness this diversity of libraries in their supply chain. The framework lets them generate a population of application variants, each depending on a different alternative library that provides similar functionalities. To investigate the relevance of this concept, we develop ARGO, a proof-of-concept implementation of this framework that harnesses the diversity of JSON suppliers. We study the feasibility of library substitution and its impact on a set of 368 clients. Our empirical results show that for 195 of the 368 java applications tested, we can substitute the original JSON library used by the client by at least 15 other JSON libraries without modifying the client's code. These results show the capacity of a Library Substitution Framework to diversify the supply chain of the client applications of the libraries it targets.
... This work proposes the first longitudinal analysis of software bloat. We focus on bloat among software dependencies [4,6,10,27] in the Java/Maven ecosystem. Bloated dependencies are software libraries that are unnecessarily part of software projects, i.e., when the dependency is removed from the project, it still builds successfully. ...
... Figure 3 shows an hypothetical example of the dependency usage tree of project . Suppose that directly calls two sets of instructions in the direct dependency 1 and the transitive dependency 6 . Then, the subset of instructions called in 1 also calls instructions in 4 . ...
... The dataset and the scripts are available in our experiment repository. 6 Table 1 shows descriptive statistics of our dataset. The 435 projects have been active for periods ranging from five months to 235 months (12 years and 7 months), with most of them in the range 48.5 months (1st Qu.) to 109.5 months (3rd Qu.). ...
We study the evolution and impact of bloated dependencies in a single software ecosystem: Java/Maven. Bloated dependencies are third-party libraries that are packaged in the application binary but are not needed to run the application. We analyze the history of 435 Java projects. This historical data includes 48,469 distinct dependencies, which we study across a total of 31,515 versions of Maven dependency trees. Bloated dependencies steadily increase over time, and 89.02% of the direct dependencies that are bloated remain bloated in all subsequent versions of the studied projects. This empirical evidence suggests that developers can safely remove a bloated dependency. We further report novel insights regarding the unnecessary maintenance efforts induced by bloat. We find that 22% of dependency updates performed by developers are made on bloated dependencies and that Dependabot suggests a similar ratio of updates on bloated dependencies.
... This work proposes the first longitudinal analysis of software bloat. We focus on bloat among software dependencies [4,6,10,27] in the Java/Maven ecosystem. Bloated dependencies are software libraries that are unnecessarily part of software projects, i.e., when the dependency is removed from the project, it still builds successfully. ...
... Figure 3 shows an hypothetical example of the dependency usage tree of project . Suppose that directly calls two sets of instructions in the direct dependency 1 and the transitive dependency 6 . Then, the subset of instructions called in 1 also calls instructions in 4 . ...
... The dataset and the scripts are available in our experiment repository. 6 Table 1 shows descriptive statistics of our dataset. The 435 projects have been active for periods ranging from five months to 235 months (12 years and 7 months), with most of them in the range 48.5 months (1st Qu.) to 109.5 months (3rd Qu.). ...
We study the evolution and impact of bloated dependencies in a single software ecosystem: Java/Maven. Bloated dependencies are third-party libraries that are packaged in the application binary but are not needed to run the application. We analyze the history of 435 Java projects. This historical data includes 48,469 distinct dependencies, which we study across a total of 31,515 versions of Maven dependency trees. Bloated dependencies steadily increase over time, and 89.2% of the direct dependencies that are bloated remain bloated in all subsequent versions of the studied projects. This empirical evidence suggests that developers can safely remove a bloated dependency. We further report novel insights regarding the unnecessary maintenance efforts induced by bloat. We find that 22% of dependency updates performed by developers are made on bloated dependencies and that Dependabot suggests a similar ratio of updates on bloated dependencies.
... Allerdings baut es kurioser Weise auf einer, dem OSI-Modell entgegenstehenden An-Abb. 6 Eine geschichtete Applikationsarchitektur. Die Vertikale repräsentiert die Ordnung durch die "Ist-Teil-von"-Relation, wie sie durch die funktionale Komposition entsteht. Die miteinander über Protokolle interagierenden Komponenten finden sich horizontal in derselben Schicht nahme auf. ...
... Der Erfolg des Interfacekonzepts der Operation zeigt sich nicht zuletzt in den inzwischen allgegenwärtigen Paketmanagern, von denen in vielen Programmiersprachen jeder mehr als 100.000 hierarchisch komponierende Pakete ver-waltet [6]. Problematisch wird es hingegen, wenn die Auffassung vertreten wird, dass alleine den Operationen ein Interfacecharakter zukommt (z. ...
Zusammenfassung
Dieser Artikel ist der zweite einer Viererreihe, die eine Diskussion über die Grundlagen der Informatik anregen soll. In ihm wird die Interaktion zwischen Systemen und die Koordination innerhalb von Systemen mithilfe des Kompositionskonzepts thematisiert.
Dabei wird, basierend auf zwei unterschiedlichen Kompositionen, eine strukturelle von einer interaktionsorientierten Perspektive unterschieden. Einerseits die hierarchische, homogene Komposition, die Systeme als Ganzes erfasst und zur Bildung von Supersystemen und damit zu einer strukturellen Teil-Ganzes-Relation führt. Sie basiert auf den Kompositionsregeln berechenbarer Funktionen. Andererseits eine inhomogene Komposition, die Systeme nur partiell im Sinne einer Projektion erfasst, die „Rolle“ genannt wird und zu vergleichsweise loser Kopplung in Form von Protokollen führt.
Diese beiden Kompositionsklassen sind die Basis für ein zweidimensionales Strukturmodell einer IT-Applikation entlang der grundsätzlichen Idee des OSI-Modells, in dem die Vertikale die Teil-Ganzes-Relation und die Horizontale die Interaktionsrelation repräsentiert.
Die Nichtdeterminiertheit der Rollen ist eine notwendige Voraussetzung zum einen für eine weitere Komposition, nämlich mehrerer Rollen eines Systems zu koordinieren – das konstruktive Gegenstück zur Projektion eines Systems auf seine Interaktion. Und zum anderen lässt die Nichtdeterminiertheit den Beteiligten einer protokollbasierten Interaktion Entscheidungsspielraum. Mithilfe von Entscheidungen lassen sich Rollen determinieren. Dies zeigt die enge Verwandtschaft des Protokollkonzepts mit dem Konzept des Spiels.
... Software reuse, a long time advocated software engineering practice [33,23], has boomed in the last years thanks to the widespread adoption of build automation and package managers [11,47]. Package managers provide both a large pool of reusable packages, a.k.a. ...
... Package managers boost software reuse by creating a clear separation between the application and its third-party dependencies. Meanwhile, they introduce new challenges for the developers of software applications, who now need to manage those third-party dependencies [11] to avoid entering into the so-called "dependency hell". These challenges relate to ensuring high quality dependencies [42], keeping the dependencies up-to-date [3], or making sure that heterogeneous licenses are compatible [51]. ...
Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application's code and its external dependencies, and automate several software development tasks. However, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies.
Bloated dependencies are libraries that the build tool packages with the application's compiled code but that are actually not necessary to build and run the application. This phenomenon artificially grows the size of the built binary and increases maintenance effort. We propose a tool, called DepClean, to analyze the presence of bloated dependencies in Maven artifacts. We analyze 9,639 Java artifacts hosted on Maven Central, which include a total of 723,444 dependency relationships. Our key result is that 75.1% of the analyzed dependency relationships are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts up to 1/4 of its current count. We also perform a qualitative study with 30 notable open-source projects. Our results indicate that developers pay attention to their dependencies and are willing to remove bloated dependencies: 18/21 answered pull requests were accepted and merged by developers, removing 131 dependencies in total.
... Software reuse at large is a known best practice in software engineering [1]. Its adoption has rocketed in the last decade, thanks to the rapid growth of repositories of reusable packages, along with the development of mature package managers [2]. These package managers let developers declare a list of third-party libraries that they want to reuse in their projects. ...
Modern software systems rely on a multitude of third-party dependencies. This large-scale code reuse reduces development costs and time, and it poses new challenges with respect to maintenance and security. Techniques such as tree shaking or shading can remove dependencies that are completely unused by a project, which partly address these challenges. Yet, the remaining dependencies are likely to be used only partially, leaving room for further reduction of third-party code. In this paper, we propose a novel technique to specialize dependencies of Java projects, based on their actual usage. For each dependency, we systematically identify the subset of its functionalities that is necessary to build the project, and remove the rest. Each specialized dependency is repackaged. Then, we generate specialized dependency trees where the original dependencies are replaced by the specialized versions and we rebuild the project. We implement our technique in a tool called DepTrim, which we evaluate with 30 notable open-source Java projects. DepTrim specializes a total of 343 (86.6%) dependencies across these projects, and successfully rebuilds each project with a specialized dependency tree. Moreover, through this specialization, DepTrim removes a total of 60,962 (47.0%) classes from the dependencies, reducing the ratio of dependency classes to project classes from 8.7x in the original projects to 4.4x after specialization. These results indicate the relevance of dependency specialization to significantly reduce the share of third-party code in Java projects.
... Dependencies are additional pieces of software that must be installed prior to the omics software being installed. The use of dependencies can ease software development and make software tools more effective, as dependencies are usually well tested, efficient, and optimized for performance 14 . ...
Omics software tools have reshaped the landscape of modern biology and become an essential component of biomedical research. The increasing dependence of biomedical scientists on these powerful tools creates a need for easier installation and greater usability. Packaging, virtualization, and containerization are different approaches to satisfy this need by wrapping omics tools in additional software that makes the omics tools easier to install and use. Here, we systematically review practices across prominent packaging, virtualization, and containerization platforms. We outline the challenges, advantages, and limitations of each approach and some of the most widely used platforms from the perspectives of users, software developers, and system administrators. We also propose principles to make packaging, virtualization, and containerization of omics software more sustainable and robust to increase the reproducibility of biomedical and life science research.
... In the first class, half of the projects have a median dependency coverage of 21% (mean: 26%), indicating that project test suites at large do not exercise dependencies in depth. This is not surprising: an ergonomic factor of third-party libraries is that they are welltested and should in principle not need extra tests [52]. In the second class, we can observe that projects have tests that exercise dependencies in-depth, suggesting the presence of projects with adequate test suites. ...
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 20% 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 five cases of unused dependencies. Our findings indicate that the combination of static and dynamic analysis should be a requirement for future dependency updating systems.
... Software dependencies are often treated as an afterthought [Cox, 2019]. They are expected to simply work. ...
Neuromorphic hardware enables novel modes of computation. We present two innovative learning strategies: First, we perform spike-based deep learning with LIF neurons in a Time-To-First-Spike coding scheme that focuses on achieving classification results with as few spikes as early as possible. This is critical for biological agents operating under environmental pressure, requiring quick reflexes while conserving energy. Deriving exact learning rules, we perform backpropagation on spike-times of LIF neurons in both software and on the BrainScaleS hardware platform. Second, we present fast energy-efficient analog inference on BrainScaleS-2. In this non-spiking mode, we use convolutional neural networks to check medical ECG traces for atrial fibrillation. The newly commissioned BrainScaleS-2 Mobile system has successfully participated and proven to operate reliably in the ``Energy-efficient AI system'' competition held by the German Federal Ministry of Education and Research. Developing these new computing paradigms from the ground up is a Herculean effort in terms of work required and people involved. Therefore, we introduce tooling methods to facilitate collaborative scientific software development and deployment. In particular, we focus on explicitly tracking disjoint sets of software dependencies via Spack, an existing package manager aimed at high performance computing. They are deployed as monolithic Singularity containers in a rolling-release schedule after thorough verification. These practices enable us to confidently advance our neuromorphic platform while fostering reproducibility of experiments, a still unsolved problem in software-aided sciences. By introducing quiggeldy, a micro-scheduling service operating on interleaved experiment-steps by different users, we achieve better hardware interactivity, stability and experiment throughput.
... Für viele Programmiersprachen gibt es mittlerweile Paketmanager, von denen jeder mehr als 100.000 Pakete verwaltet [12]. ...
Zusammenfassung
In diesem Artikel diskutiere ich Interoperabilität von berechenbaren Systemen mithilfe des mathematischen Konzepts der Komposition. Die zentrale Vorstellung ist, dass Systeme durch Interaktion komponieren und diese Komposition mathematisch als Operator, also als Funktion auf Systemen beschreibbar ist. Daraus ergibt sich der Begriff des Interface eines Systems, als Zusammenfassung aller seiner auf die Komposition bezogenen Angaben, auf natürliche Art und Weise ebenso wie der Begriff der Komponente als eines Systems, das für eine bestimmte Komposition konstruiert wurde.
Ich unterscheide zwei grundsätzlich verschiedene Kompositionen von Systemen. Zunächst die hierarchische Komposition, die Systeme als Ganzes erfasst und zur Bildung von Supersystemen führt. Sie basiert auf den Kompositionsregeln berechenbarer Funktionen und führt zu den Interfaces der Operationen (+Events) sowie zu Komponentenhierarchien. Demgegenüber steht eine zweite Form der Komposition, die Systeme nur partiell im Sinne einer Projektion erfasst und zu vergleichsweise loser Kopplung durch Protokolle führt, mit dem Interface der Protokoll-Rolle. Damit sind Interfaces, die Operationen repräsentieren, per Definitionem nur für hierarchische Kompositionen geeignet und keine wesentliche Hilfe in der Darstellung netzwerkartiger „horizontaler“ Interaktionen.
Um die Anwendbarkeit des Kompositionskonzepts zu demonstrieren, werden verschiedene System‑, Interface- und Komponentenmodelle aus der Literatur diskutiert, u. a. das Komponentenmodell verteilter Objekte, sowie die Interfacekonzepte von SOA und REST.
... Package managers boost software reuse by creating a clear separation between the application and its third-party dependencies. Meanwhile, they introduce new challenges for the developers of software applications, who now need to manage those third-party dependencies (Cox 2019) to avoid entering into the so-called "dependency hell". These challenges relate to ensuring high quality dependencies (Salza et al. 2019), keeping the dependencies up-to-date (Bavota et al. 2015), or making sure that heterogeneous licenses are compatible (Wu et al. 2017). ...
Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application’s code and its external dependencies, and automate several software development tasks. However, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies. Bloated dependencies are libraries that are packaged with the application’s compiled code but that are actually not necessary to build and run the application. They artificially grow the size of the built binary and increase maintenance effort. We propose DepClean, a tool to determine the presence of bloated dependencies in Maven artifacts. We analyze 9,639 Java artifacts hosted on Maven Central, which include a total of 723,444 dependency relationships. Our key result is as follows: 2.7% of the dependencies directly declared are bloated, 15.4% of the inherited dependencies are bloated, and 57% of the transitive dependencies of the studied artifacts are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts to 1/4 of its current count. Our qualitative assessment with 30 notable open-source projects indicates that developers pay attention to their dependencies when they are notified of the problem. They are willing to remove bloated dependencies: 21/26 answered pull requests were accepted and merged by developers, removing 140 dependencies in total: 75 direct and 65 transitive.
... Entire ecosystems have been created around these package managers, e.g., the Node.js ecosystem is largely supported by npm [4]. ...
Nowadays, developing software would be unthinkable without the use of third-party packages. Although such code reuse helps to achieve rapid continuous delivery of software to end-users, blindly reusing code has its pitfalls. For example, prior work has investigated the rationale for using packages that implement simple functionalities, known as trivial packages (i.e., in terms of the code size and complexity). This prior work showed that although these trivial packages were simple, they were popular and prevalent in the npm ecosystem. This popularity and prevalence of trivial packages peaked our interest in questioning the ‘triviality of trivial packages’.
To better understand and examine the triviality of trivial packages, we mine a large set of JavaScript projects that use trivial npm packages and evaluate their relative centrality. Specifically, we evaluate the triviality from two complementary points of view: based on project usage and ecosystem usage of these trivial packages. Our result shows that trivial packages are being used in central JavaScript files of a software project. Additionally, by analyzing all external package API calls in these JavaScript files, we found that a high percentage of these API calls are attributed to trivial packages. Therefore, these packages play a significant role in JavaScript files. Furthermore, in the package dependency network, we observed that 16.8% of packages are trivial and in some cases removing a trivial package can impact approximately 29% of the ecosystem. Overall, our finding indicates that although smaller in size and complexity, trivial packages are highly depended on packages by JavaScript projects. Additionally, our study shows that although they might be called trivial, nothing about trivial packages is trivial.
... Recently, Node.js/JavaScript has become one of the most commonly and widely used programming languages [32]. One of the main forces behind the popularity of JavaScript is the fact that code sharing is prominent and even encouraged by its developer community [10]. This code sharing is supported by the node package manager (npm). ...
Developers often share their code snippets by packaging them and making them available to others through software packages. How much a package does and how big it is can be seen as positive or negative. Recent studies showed that many packages that exist in the npm ecosystem are trivial and may introduce high dependency overhead.
Hence, one question that arises is why developers choose to publish these trivial packages. Therefore, in this paper, we perform a developer centered study to empirically examine why developers choose to publish such trivial packages. Specifically, we ask 1) why developers publish trivial packages, 2) what they believe to be the possible negative impacts of these packages, and 3) how such negative issues can be mitigated. The survey response of 59 JavaScript developers who publish trivial npm packages showed that the main advantages for publishing these trivial packages are to provide reusable components, testing & documentation, and separation of concerns. Even the developers who publish these trivial packages admitted to having issues when they publish such packages, which include the maintenance of multiple packages, dependency hell, finding the right package, and the increase of duplicated packages in the ecosystems.
Furthermore, we found that the majority of the developers suggested grouping these trivial packages to cope with the problems associated with publishing them. Then, to quantitatively investigate the impact of these trivial packages on the npm ecosystem and its users, we examine grouping these trivial packages. We found that if trivial packages that are always used together are grouped, the ecosystem can reduce the number of dependencies by approximately 13%. Our findings shed light on the impact of publishing trivial packages and show that ecosystems and developer communities need to rethink their publishing policies since it can negatively impact the developers and the entire ecosystem.
... Modern software is built to depend on countless subcomponents, each with their own lifecycles. Cox [2019] writes about surviving software dependencies from a practitioner's Onward! Essays 2020, October 2020, Chicago, IL, USA 2018. ...
The long-standing aspiration for software reuse has made astonishing strides in the past few years. Many modern software development ecosystems now come with rich sets of publicly-available components contributed by the community. Downstream developers can leverage these upstream components, boosting their productivity. However, components evolve at their own pace. This imposes obligations on and yields benefits for downstream developers, especially since changes can be breaking, requiring additional downstream work to adapt to. Upgrading too late leaves downstream vulnerable to security issues and missing out on useful improvements; upgrading too early results in excess work. Semantic versioning has been proposed as an elegant mechanism to communicate levels of compatibility, enabling downstream developers to automate dependency upgrades. While it is questionable whether a version number can adequately characterize version compatibility in general, we argue that developers would greatly benefit from tools such as semantic version calculators to help them upgrade safely. The time is now for the research community to develop such tools: large component ecosystems exist and are accessible, component interactions have become observable through automated builds, and recent advances in program analysis make the development of relevant tools feasible. In particular, contracts (both traditional and lightweight) are a promising input to semantic versioning calculators, which can suggest whether an upgrade is likely to be safe.
... Für viele Programmiersprachen gibt es mittlerweile entsprechende Paketmanager, die jeweils mehr als 100.000 Pakete in hierarchischen Abhängigkeiten verwalten, u. a. Maven Central (Java), NuGet (.NET), Packagist (PHP), PyPI (Python), Ruby-Gems (Ruby), etc. (Cox 2019). ...
Zusammenfassung
In diesem Artikel bewerten wir die bisherigen Ergebnisse der Standardisierungsanstrengungen der Plattform Industrie 4.0 im Hinblick auf das Verfolgen einheitlicher und in sich konsistenter Konzepte. Die von uns betrachteten Ergebnisse sind das Referenzarchitekturmodell Industrie 4.0 (RAMI4.0) sowie das Konzept der Verwaltungsschale (VWS).
Um seinen Zweck zu erfüllen, den Diskurs zur Standardisierung von Industrie 4.0 (I4.0)-relevanten Aspekten im Sinne einer Schichtung zu vereinfachen, müssten die vom RAMI4.0 eingeführten Begriffsachsen ein klares Ordnungskriterium aufweisen. Dies ist zumindest bei der Architekturachse (Business, Functional, Information, Communication, Integration, Asset) nicht der Fall, weswegen diese Begriffsachse nicht die gewünschte „Schichtung“ erreicht. Stattdessen repräsentieren die Werte der Architekturachse eher verschiedene, sich überlappende Aspekte.
Das Konzept der Verwaltungsschale analysieren wir mit Hilfe der drei grundsätzlich verschiedenartigen Konzepte der „administrativen Prozesse“, des „Komponentenmodells“ und des „Datenmodells“. Wir stellen fest, dass sich im Laufe der Zeit Elemente aller drei Konzepte in unterschiedlicher Zusammensetzung wiederfinden und insbesondere die ursprüngliche Idee der VWS als eine „schmale informatische Hülle“ in sich widersprüchlich ist. Diese konzeptuelle Unschärfe hat unseres Erachtens erheblich dazu beigetragen, dass die Ergebnisse der Standardisierung der VWS bis jetzt hinter den ursprünglichen Plänen zurückgeblieben sind.
... A dependency is third-party code that a developer includes in their software project [14]. Adding a dependency to a project avoids repeating work that is already done including development, testing, and maintenance. ...
Software developers often fail to run simple checks for known vulnerabilities in software dependencies, creating a common security risk. To remedy this, GitHub began sending security alerts to hosted projects that declare a vulnerable dependency in October 2017. This naturally raises an important question: how did vulnerable dependency fix rates change after notifications were deployed? To answer this question, we examine 261,998 GitHub projects with external dependencies from five language ecosystems over a period of two years, characterize and identify vulnerable dependencies with GitHub's security advisory database, and determine if and when developers fix these vulnerabilities. We find 58,855 repositories had vulnerable dependencies at some point, with a fix rate of 26.9%. Additionally, we find that 12.5% of projects were fixed after a GitHub security advisory, compared to 9.0% of fixes which occurred after a CVE was published but before a GitHub advisory. Moreover, we find that over 40% of vulnerable dependencies are corrected if the alert is sent at the time of the vulnerability-introducing commit. Our findings show that security alerts are correlated with modest fix rate improvements across all of GitHub.
... The latter is used for pre-tapeout veri cation during chip development. 5) Software Environment: Reuse of existing software packages reduces development costs but also introduces technical debt in the form of dependencies on external software packages [27]. BrainScaleS uses a containerized and explicit software dependency tracking system based on singularity [28] and spack [29]. ...
BrainScaleS-1 is a wafer-scale mixed-signal accelerated neuromorphic system targeted for research in the fields of computational neuroscience and beyond-von-Neumann computing. The BrainScaleS Operating System (BrainScaleS OS) is a software stack giving users the possibility to emulate networks described in the high-level network description language PyNN with minimal knowledge of the system. At the same time, expert usage is facilitated by allowing to hook into the system at any depth of the stack. We present operation and development methodologies implemented for the BrainScaleS-1 neuromorphic architecture and walk through the individual components of BrainScaleS OS constituting the software stack for BrainScaleS-1 platform operation.
Software bills of materials (SBOM) promise to become the backbone of software supply chain hardening. We deep-dive into 6 tools and the accuracy of the SBOMs they produce for complex open-source Java projects. Our novel insights reveal some hard challenges for the accurate production and usage of SBOMs.
Functional diversity is widely used and widespread. However, the main packages used to compute functional diversity indices are not flexible and not adapted to the volume of data used in modern ecological analyses. We here present fundiversity, an R package that eases the computation of classical functional diversity indices. It leverages parallelization and memoization (caching results in memory) to maximize efficiency with data with thousands of columns and rows. We also did a performance comparison with packages that provide analog functions. In addition to being more flexible, fundiversity was always an order of magnitude quicker than alternatives. fundiversity aims to be a lightweight, efficient tool to compute functional diversity indices, which can be used in a variety of contexts. Because it has been designed following clear principles, it is easy to extend. We hope the wider community will adopt it and we welcome all contributions.
This study demonstrates the role of blockchain adoption in facilitating supply chain operations, as well as contributing to providing security in commercial operations that take place through the supply chain and supporting it in obtaining the necessary information about the exchange and transportation of products in a timely manner, which generally facilitates social trade operations. Providing the best that customers desire in commercial operations, which is the ease of conducting transactions and the speed of their completion, as well as eliminating the most important thing that keeps consumers away from adopting social commerce due to their fear of account penetration, data manipulation, and fraud resulting from the loss of the safety factor in digital accounts.
Web applications are becoming more ubiquitous. All manner of physical devices are now connected and often have a variety of web applications and web-interfaces. This proliferation of web applications has been accompanied by an increase in reported software vulnerabilities. The objective of this analysis of vulnerability data is to understand the current landscape of reported web application flaws. Along those lines, this work reviews ten years (2011 - 2020) of vulnerability data in the National Vulnerability Database. Based on this data, most common web application weaknesses are identified and their profiles presented. A weakness ontology is developed to capture the attributes of these weaknesses. These include their attack method and attack vectors. Also described is the impact of the weaknesses to software quality attributes. Additionally, the technologies that are susceptible to each weakness are presented, they include programming languages, frameworks, communication protocols, and data formats.
BrainScaleS-1 is a wafer-scale mixed-signal accelerated neuromorphic system targeted for research in the fields of computational neuroscience and beyond-von-Neumann computing. Here we present the BrainScaleS Operating System (BrainScaleS OS): the software stack gives users the possibility to emulate networks described in the high-level network description language PyNN with minimal knowledge of the system, as well as expert usage facilitated by allowing access to the system at any depth of the stack. BrainScaleS OS has been used extensively in the commissioning and calibration of BrainScaleS-1 as well as in various neuromorphic experiments, e.g., rate-based deep learning, accelerated physical emulation of Bayesian inference, solving of SAT problems, and others. The tolerance to faults of individual components of the neuromorphic system is reflected in the mapping process based on information stored in an availability database. We evaluate the robustness and compensation mechanisms of the system and software stack. The software stack is designed with performance in mind, with its core implemented in C++ and most user-facing API wrapped automatically to Python. The implemented multi-FPGA orchestration allows for parallel configuration and synchronized experiments facilitating wafer-scale experiments. The initial configuration of a wafer-scale experiment with hundreds of neuromorphic ASICs is performed in a fraction of a minute. Subsequent experiments, that potentially change only a subset of parameters, can be executed with rates of typically 10Hz. The bandwidth from the host machine to the neuromorphic system is fully utilized starting from a quarter of the system’s FPGA count. Operation and development methodologies implemented for the BrainScaleS-1 neuromorphic architecture are presented and the individual components of BrainScaleS OS constituting the software stack for BrainScaleS-1 platform operation are detailed.
Released as open source in November 2009, Go has become the foundation for critical infrastructure at every major cloud provider. Its creators look back on how Go got here and why it has stuck around.
Dieser Artikel ist als Beitrag zu der Diskussion gedacht, das Begriffsnetzwerk, das den Kern der Informatik ausmacht, zu bestimmen. Dieses Begriffsnetzwerk steht in dem Spannungsfeld zum einen weitgehend in unserem alltagssprachlichen Verständnis verankert zu sein, aber zum anderen mittels des spezifischen informatischen Ansatz, sich auf das Unterscheidbare zu fokussieren, auch auf genuin informatischen Konzepten aufzubauen.
Diese wechselseitige Beziehung birgt einerseits die Chance, einen entscheidenden Beitrag zu einem differenzierteren Verständnis unserer Welt zu leisten aber andererseits das Risiko unsere Alltagswelt mit falsch verstandenen informatischen Konzepten unnötigerweise erheblich zu verwirren. Für beides gibt es mittlerweile gute Beispiele.
Die zentralen Begriffe sind meiner Meinung nach die der Zustandsfunktion, des Systems, der Unterscheidbarkeit und damit der Information, der Berechenbarkeit sowie eine ganze Reihe mathematischer Konzepte, allen voran das der Relation, der Funktion, der mathematischen Struktur und der Komposition. Der grundlegende Bezug zum Informationskonzept als Abstraktion vom Ununterscheidbaren macht die Informatik zu einer Strukturwissenschaft und bindet damit die Klarheit ihrer Begrifflichkeit letztlich an deren Bezug zur Mathematik.
Was scheint verwirrend in der Informatik und was klärt diese Arbeit auf? Einerseits basiert alles in der Informatik auf dem Austausch von Informationen -- andererseits scheint dieser aber bei der Beschreibung von Operationen, wie sie in imperativen Programmiersprachen verwendet werden, gar keine Rolle zu spielen. Einerseits ist Informatik geprägt durch das Konzept der Berechenbarkeit, in dem Determinismus herrscht und in dem Zustand nur passager notwendig ist -- andererseits sind die Interaktionen zwischen komplexen Systemen ''auf gleicher Augenhöhe'' in der Regel nichtdeterministisch und zustandsbehaftet. Einerseits komponieren Systeme durch Interaktion zu Supersystemen -- andererseits auch wieder nicht. Einerseits scheint in der Informatik ein Modell etwas zu beschreiben -- andererseits scheint in der Informatik ein Modell etwas Beschriebenes. Einerseits scheint das Konzept der Semantik im Bereich der Berechenbarkeit überflüssig -- andererseits scheint die Informatik zu der Aufklärung von Semantik einen wesentlichen Beitrag liefern zu können.
Neben der Aufklärung dieser und weiterer Verwirrungen ist es mir wichtig, das Bild zu vermitteln, dass eine wohlverstandene Informatik tatsächlich menschlicher wird. Mit ihr können wir aufzeigen, dass eben nicht die Berechenbarkeit die Welt mit ihrem Determinismus dominiert, sondern wir permanent große Vorteile aus ihrer Unberechenbarkeit, aus ihrer Nichtdeterminiertheit ziehen. Ganz konkret lässt die enge Verbindung des von ihr erarbeiteten Protokollkonzepts mit dem des Spiels den Entscheidungsbegriff näher bestimmen und darauf aufbauend ein Konzept der alltagssprachlichen Semantik im Sinne einer Interaktionssemantik entwickeln.
Damit leistet eine solche Informatik einen essentiell wichtigen Beitrag für unser Verständnis solch wichtiger alltagssprachlicher Begriffe wie der unserer persönlichen Freiheit -- was vor den aktuellen gesellschaftlichen, wesentlich durch die Informatik möglich gemachten Entwicklungen der Megainteraktionsnetzwerke, auch zu erwarten wäre und meiner Ansicht nach auch dringend erforderlich ist.
Hyrum’s law states a common observation in the software industry: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody”. Meanwhile, recent research results seem to contradict this observation when they state that “for most APIs, there is a small number of features that are actually used”. In this work, we perform a large scale empirical study of client API relationships in the Maven ecosystem, in order to investigate this seeming paradox between the observations in industry and the research literature.
We study the 94 most popular libraries in Maven Central, as well as the 829,410 client artifacts that declare a dependency to these libraries and that are available in Maven Central, summing up to 2.2M dependencies. Our analysis indicates the existence of a wide spectrum of API usages, with enough clients, most API types end up being used at least once. Our second key observation is that, for all libraries, there is a small set of API types that are used by the vast majority of its clients. The practical consequences of this study are two-fold: (i) it is possible for API maintainers to find an essential part of their API on which they can focus their efforts; (ii) API developers should limit the public API elements to the set of features for which they are ready to have users.
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 20% 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 five cases of unused dependencies. Our findings indicate that the combination of static and dynamic analysis should be a requirement for future dependency updating systems.
Reuse is the objective that must lead to a dependable target system composed of reused and new components. Systems nowadays consist of different types of E&E components that will be integrated by software. Therefore, the authors suggest to start with software aspects, without neglecting its interaction with hardware.
In diesem Artikel diskutiere ich Interoperabilität von berechenbaren Systemen mithilfe des mathematischen Konzepts der Komposition. Die zentrale Vorstellung ist, dass Systeme durch Interaktion komponieren und diese Komposition mathematisch als Operator, also als Funktion auf Systemen beschreibbar ist. Daraus ergibt sich der Begriff des Interface eines Systems, als Zusammenfassung aller seiner auf die Komposition bezogenen Angaben, auf natürliche Art und Weise ebenso wie der Begriff der Komponente als eines Systems, das für eine bestimmte Komposition konstruiert wurde.
Ich unterscheide zwei grundsätzlich verschiedene Kompositionen von Systemen. Zunächst die hierarchische Komposition, die Systeme als Ganzes erfasst und zur Bildung von Supersystemen führt. Sie basiert auf den Kompositionsregeln berechenbarer Funktionen und führt zu den Interfaces der Operationen (+Events) sowie zu Komponentenhierarchien. Demgegenüber steht eine zweite Form der Komposition, die Systeme nur partiell im Sinne einer Projektion erfasst und zu vergleichsweise loser Kopplung führt, mit dem Interface der Protokolle.
Damit sind Interfaces, die Operationen repräsentieren, per Definitionem nur für hierarchische Kompositionen geeignet und keine wesentliche Hilfe in der Darstellung netzwerkartiger ''horizontaler'' Interaktionen.
Um die Anwendbarkeit des Kompositionskonzepts zu demonstrieren, werden verschiedene System-, Interface- und Komponentenmodelle aus der Literatur diskutiert, u.a. das Komponentenmodell verteilter Objekte, sowie die Interfacekonzepte von SOA und REST.
Very large data sets often have a flat but regular structure and span multiple disks and machines. Examples include telephone call records, network logs, and web document reposi- tories. These large data sets are not amenable to study using traditional database techniques, if only because they can be too large tofit in a single relational database. On the other hand, many of the analyses done on them can be expressed using simple, easily distributed computations: filtering, aggregation, extraction of statistics, and so on. We present a system for automating such analyses. A filtering phase, in which a query is expressed using a new procedural programming language, emits data to an aggregation phase. Both phases are distributed over hundreds or even thousands of computers. The results are then collated and saved to a file. The design—including the separation into two phases, the form of the programming language, and the properties of the aggregators—exploits the parallelism inherent in having data and computation distributed across many machines.
Google's monolithic repository provides a common source of truth for tens of thousands of developers around the world.
To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.
RE2: A principled approach to regular expression matching
- R Cox
- Cox R.
Cox, R. RE2: A principled approach to regular
expression matching. Google Open Source Blog (Mar.
2010);
A single Node of failure
- N Willis
- Willis N.
Willis, N. A single Node of failure. LWN.net (Mar. 2016);
Details about the event-stream incident. The npm Blog
- A Baldwin
Baldwin, A. Details about the event-stream incident.
The npm Blog (Nov. 2018);
Infer: A tool to detect bugs in Java and C/ C++/Objective-C code before it ships
Facebook. Infer: A tool to detect bugs in Java and C/
C++/Objective-C code before it ships; https://fbinfer.
com/.
Testing Chromium: ThreadSanitizer v2 a next-gen data race detector. Chromium Blog
- A Potapenko
- Testing Chromium
Potapenko, A. Testing Chromium: ThreadSanitizer v2,
a next-gen data race detector. Chromium Blog (Apr.
2014);
Multi-process architecture
- C Reis
- Reis C.
Reis, C. Multi-process architecture. Chromium Blog
(Sept. 2008);
SD-8: Standard library compatibility
- T Winters
Winters, T. SD-8: Standard library compatibility, C++
standing document, 2018; http://bit.ly/2QNhT5k.
The principles of versioning in Go
- R Cox
Cox, R. The principles of versioning in Go. GopherCon
Singapore (May 2018);
Cox, R. Regular expression matching with a trigram index or how Google Code Search worked
- R Cox
- Cox R.
Cox, R. Regular expression matching with a trigram
index or how Google Code Search worked. Swtch.com
(Jan. 2012);
Open-sourcing gVisor a sandboxed container runtime
- N Lacasse
Lacasse, N., Open-sourcing gVisor, a sandboxed
container runtime. Google Cloud (May 2018);
Chromium's seccomp sandbox
- A Langley
- Langley A.
Langley, A. Chromium's seccomp sandbox.
ImperialViolet (Aug. 2009); https://www.
imperialviolet.org/2009/08/26/seccomp.html.
How SQLite is tested
- D R Hipp
Hipp, D. R. How SQLite is tested; https://www.sqlite.
org/testing.html.
Cox, R. The principles of versioning in Go
- R Cox
- Cox R.
Hipp D. R. How SQLite is tested
- D R Hipp
House of Representatives Committee on Oversight and Government Reform. The Equifax Data Breach
- U.S. House of Representatives Committee on Oversight and Government Reform
U.S. House of Representatives Committee on
Oversight and Government Reform. The Equifax Data
Breach, Majority Staff Report, 115th Congress (Dec.
2018);
Baldwin, A. Details about the event-stream incident. The npm Blog
- A Baldwin
- Baldwin A.
Testing Chromium: ThreadSanitizer v2, a next-gen data race detector. Chromium Blog
- A Potapenko
- Potapenko A.