Fix that Fix Commit: A real-world remediation analysis of JavaScript projects

While there is a large body of work on understanding vulnerabilities in the wild, little has been done to understand the dynamics of the remediation phase of the development cycle. To this end, we have done a timeline analysis on 118K commits from 53 of the most used JavaScript projects from GitHub to understand the provenance and prevalence of vulnerabilities in those projects. We used a vulnerability detector (CodeQL) to filter commits that introduced vulnerabilities and the commits that fixed a prior vulnerability. We found that in 82% of the projects, a commit fixing a prior vulnerability, in turn, introduced one or more new vulnerabilities. Among those projects, on average, 18% of the commits intended to fix vulnerabilities, in turn, introduced one or more new vulnerabilities. We also found that 50% of the total vulnerabilities found in those projects originated from a commit meant to fix a prior vulnerability, and 78% of those vulnerabilities could have been avoided if they were to use proper internal testing. We provide critical insights into how proper internal testing can avoid a significant portion of vulnerabilities, increasing organizations’ security posture.

[1]  Nan Zhang,et al.  An Empirical Study of the Framework Impact on the Security of JavaScript Web Applications , 2018, WWW.

[2]  Vern Paxson,et al.  A Large-Scale Empirical Study of Security Patches , 2017, CCS.

[3]  Noura Alomar,et al.  "You've Got Your Nice List of Bugs, Now What?" Vulnerability Discovery and Management Processes in the Wild , 2020, SOUPS @ USENIX Security Symposium.

[4]  Rocco Oliveto,et al.  Fixing of Security Vulnerabilities in Open Source Projects: A Case Study of Apache HTTP Server and Apache Tomcat , 2019, 2019 12th IEEE Conference on Software Testing, Validation and Verification (ICST).

[5]  Kevin Hogan,et al.  The Challenges of Labeling Vulnerability-Contributing Commits , 2019, 2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW).

[6]  Thomas Zimmermann,et al.  Automatic Identification of Bug-Introducing Changes , 2006, 21st IEEE/ACM International Conference on Automated Software Engineering (ASE'06).

[7]  Michael Hicks,et al.  Understanding security mistakes developers make: Qualitative analysis from Build It, Break It, Fix It , 2020, USENIX Security Symposium.

[8]  Elissa M. Redmiles,et al.  How I Learned to be Secure: a Census-Representative Survey of Security Advice Sources and Behavior , 2016, CCS.

[9]  Daniel M. Germán,et al.  How bugs are born: a model to identify how bugs are introduced in software components , 2020, Empirical Software Engineering.

[10]  Ali Mesbah,et al.  Discovering bug patterns in JavaScript , 2016, SIGSOFT FSE.

[11]  Ding Yuan,et al.  How do fixes become bugs? , 2011, ESEC/FSE '11.

[12]  Воробьев Антон Александрович Анализ уязвимостей вычислительных систем на основе алгебраических структур и потоков данных National Vulnerability Database , 2013 .

[13]  Matthew Smith,et al.  VCCFinder: Finding Potential Vulnerabilities in Open-Source Projects to Assist Code Audits , 2015, CCS.

[14]  Manar Alohaly,et al.  When Do Changes Induce Software Vulnerabilities? , 2017, 2017 IEEE 3rd International Conference on Collaboration and Internet Computing (CIC).

[15]  Mark C. Paulk,et al.  Capability Maturity Model , 1991 .

[16]  Brendan Murphy,et al.  How Do Developers Act on Static Analysis Alerts? An Empirical Study of Coverity Usage , 2019, 2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE).

[17]  Lutz Prechelt,et al.  Why software repositories are not used for defect-insertion circumstance analysis more often: A case study , 2014, Inf. Softw. Technol..

[18]  Bernhard Plattner,et al.  Large-scale vulnerability analysis , 2006, LSAD '06.

[19]  Andrew Meneely,et al.  When a Patch Goes Bad: Exploring the Properties of Vulnerability-Contributing Commits , 2013, 2013 ACM / IEEE International Symposium on Empirical Software Engineering and Measurement.