User Tools
vulnerability_discovery_models
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
vulnerability_discovery_models [2018/08/30 17:57] ivan.pashchenko@unitn.it Added description of the dependency paper |
vulnerability_discovery_models [2018/08/31 11:29] ivan.pashchenko@unitn.it Added paper from WEIS |
||
|---|---|---|---|
| Line 18: | Line 18: | ||
| Vulnerable dependencies are a known problem in today’s open-source software ecosystems because FOSS libraries are highly interconnected and developers do not always update their dependencies. | Vulnerable dependencies are a known problem in today’s open-source software ecosystems because FOSS libraries are highly interconnected and developers do not always update their dependencies. | ||
| - | In our recent paper we show how to avoid the over-inflation problem of academic and industrial approaches for reporting vulnerable dependencies in FOSS software, and therefore, satisfy the needs of industrial practice for correct allocation of development and audit resources. | + | In {{https://drive.google.com/file/d/1IewO3T_cZuz2GkRctDJYvyMJAqXxTamc/view?usp=sharing|our recent paper}} we show how to avoid the over-inflation problem of academic and industrial approaches for reporting vulnerable dependencies in FOSS software, and therefore, satisfy the needs of industrial practice for correct allocation of development and audit resources. |
| To achieve this, we carefully analysed the deployed dependencies, aggregated dependencies by their projects, and distinguished halted dependencies. All this allowed us to obtain a counting method that avoids over-inflation. | To achieve this, we carefully analysed the deployed dependencies, aggregated dependencies by their projects, and distinguished halted dependencies. All this allowed us to obtain a counting method that avoids over-inflation. | ||
| - | To understand the industrial impact, we considered the 200 most popular OSS Java libraries used by SAP in its own software. Our analysis included 10905 distinct GAVs (group, artifact, version) in Maven when considering all the library versions. | + | To understand the industrial impact, we considered the 200 most popular FOSS Java libraries used by SAP in its own software. Our analysis included 10905 distinct GAVs (group, artifact, version) in Maven when considering all the library versions. |
| We found that about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice. Developers of the analyzed libraries are able to fix (and actually responsible for) 82% of the deployed vulnerable dependencies. The vast majority (81%) of vulnerable dependencies may be fixed by simply updating to a new version, while 1% of the vulnerable dependencies in our sample are halted, and therefore, potentially require a costly mitigation strategy. | We found that about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice. Developers of the analyzed libraries are able to fix (and actually responsible for) 82% of the deployed vulnerable dependencies. The vast majority (81%) of vulnerable dependencies may be fixed by simply updating to a new version, while 1% of the vulnerable dependencies in our sample are halted, and therefore, potentially require a costly mitigation strategy. | ||
| Line 29: | Line 29: | ||
| Do you want to check if your project actually uses some vulnerable dependencies? Let us know. | Do you want to check if your project actually uses some vulnerable dependencies? Let us know. | ||
| + | |||
| ===== A Screening Test for Disclosed Vulnerabilities in FOSS Components ===== | ===== A Screening Test for Disclosed Vulnerabilities in FOSS Components ===== | ||
| Line 44: | Line 45: | ||
| If you are interested in getting the code for the analysis please let us know. | If you are interested in getting the code for the analysis please let us know. | ||
| + | |||
| + | |||
| + | ===== Effort of security maintenance of FOSS components ===== | ||
| + | |||
| + | In our paper we investigated publicly available factors (from number of active users to commits, from code size to usage of popular programming languages, etc.) to identify which ones impact three potential effort models: Centralized (the company checks each component and propagates changes to the product groups), Distributed (each product group is in charge of evaluating and fixing its consumed FOSS components), and Hybrid (seldom used components are checked individually by each development team, the rest is centralized). | ||
| + | |||
| + | We use Grounded Theory to extract the factors from a six months study at the vendor and report the results on a sample of 152 FOSS components used by the vendor. | ||
| ===== Which static analyzer performs best on a particular FOSS project? ===== | ===== Which static analyzer performs best on a particular FOSS project? ===== | ||
vulnerability_discovery_models.txt · Last modified: 2021/01/29 10:58 (external edit)
Page Tools
