DISI Security Research Group Wiki

User Tools

Site Tools

Trace:
vulnerability_discovery_models

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
vulnerability_discovery_models [2018/08/31 10:58] – ivan.pashchenko@unitn.itvulnerability_discovery_models [2025/01/28 00:47] (current) – fabio.massacci@unitn.it
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 {{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.+You may want to read first a thematic analysis study ({{:research_activities:vulnerability-analysis:ccs-2020-aam.pdf|Accepted in CCS}}) in which we interviewed 25 developers all over the world provide some important insight in the choice of company to update or not update the software. 
 + 
 +In {{:research_activities:vulnerability-analysis:pashchenko-vuln4real.pdf |TSE 2020 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.
Line 29: Line 31:
  
 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 47:
  
 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.1535705936.txt.gz · Last modified: (external edit)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki