Lags in the release, adoption, and propagation of npm vulnerability fixes

Chinthanet, Bodin; Kula, Raula Gaikovina; McIntosh, Shane; Ishio, Takashi; Ihara, Akinori; Matsumoto, Kenichi

doi:10.1007/s10664-021-09951-x

Cited by 43 publications

(42 citation statements)

References 36 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Prior research finds that developers are more likely to upgrade a package when security fixes are isolated in a separate release [8], [10]. However, security releases of open source packages often come bundled with unrelated functional changes [7]. Therefore, we quantitatively analyze the code changes in the security releases.…”

Section: Rq2: How Is the Security Fix Documented In The Release Notes?mentioning

confidence: 99%

“…To the best of our knowledge, ours is the first study investigating RQ1, RQ2, and RQ4 for open source packages. Regarding RQ3, Chinthanet et al [7] studied SemVer versioning and lines of code (LOC) change in security releases for the npm ecosystem, and we extend such analysis over seven ecosystems. Further, to the best of our knowledge, ours is the first study with a comparison of security release practices across packages in different languages.…”

Section: Rq4: What Is the Time Lag Between A Security Release And The...mentioning

confidence: 99%

“…Figure 1 shows a timeline on how security fixes in the open source packages become available to the client projects and the possible windows of delays. Note that, a client project may not upgrade to the security release even after getting notified [7], [17]. However, such delays are out of scope for this study, as we only investigate the security release practices from the root (of the security fix propagation) packages.…”

Section: Vulnerability Discoveredmentioning

confidence: 99%

“…security release, so the client projects are able to adopt the fix. Delay in the propagation of security fixes downstream creates a window of opportunity for an attacker to exploit the unpatched vulnerability within the client projects [6], [7]. Therefore, packages should follow good developmental practices to ensure client projects are promptly informed about a vulnerability (e.g.…”

Section: Introductionmentioning

confidence: 99%

“…Therefore, packages should follow good developmental practices to ensure client projects are promptly informed about a vulnerability (e.g. through release notes or publication of a security advisory on popular vulnerability databases) and can upgrade to the security release with minimal migration effort [7], [8], [9], [10].…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Open or Sneaky? Fast or Slow? Light or Heavy?: Investigating Security Releases of Open Source Packages

Imtiaz¹,

Aniqa²,

Williams³

2021

Preprint

View full text Add to dashboard Cite

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 (Composer, Go, Maven, npm, NuGet, pip, and RubyGems). 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. Further, security releases may also contain breaking change(s) as 13.4% of the releases indicated backward incompatibility through semantic versioning, while 6.4% of the releases mentioned breaking change(s) in the release notes. 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.

show abstract

Section: Rq2: How Is the Security Fix Documented In The Release Notes?mentioning

confidence: 99%

Section: Rq4: What Is the Time Lag Between A Security Release And The...mentioning

confidence: 99%

Section: Vulnerability Discoveredmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Open or Sneaky? Fast or Slow? Light or Heavy?: Investigating Security Releases of Open Source Packages

Imtiaz¹,

Aniqa²,

Williams³

2021

Preprint

View full text Add to dashboard Cite

show abstract

Vulnerability diffusions in software product networks

Kang

Templeton

2023

J of Ops Management

View full text Add to dashboard Cite

During software product development, the combination of digital resources (such as application programming interfaces and software development kits) establishes loose and tight edges between nodes, which form a software product network (SPN). These edges serve as observable conduits that may help practitioners and researchers better understand how vulnerabilities diffuse through SPNs. We apply network theory to analyze data from over 12 years of records extracted from the National Vulnerability Database. We contribute novel measures established using machine learning to gauge the properties influencing vulnerability diffusion within an SPN. We observed an SPN having a discernable shape that changed over time via network updates. We propose hypotheses and find empirical evidence that vulnerability diffusion is influenced by edge dynamics, developer responses, and their interaction. Implications for practice are that increased developer responses reduce software vulnerability diffusion attributed to edge dynamics.

show abstract