Pith. sign in

REVIEW 3 major objections 6 minor 54 references

Linux Kernel Recency Matters, CVE Severity Doesn't, and History Fades

T0 review · 3 major / 6 minor · reviewed 2026-08-03 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read For Linux kernel CVEs, how new your kernel is predicts how fast it gets fixed; CVSS severity has no measurable effect.

desk verdict CVSS null result is solid; the recency gradient in §5.5 needs a within-CVE control before you can trust it. read the letter →

arxiv 2601.22196 v1 pith:HFLFGAU4 submitted 2026-01-29 cs.SE cs.CR

Piotr Przymus (1) , Witold Weiner (1) , Krzysztof Rykaczewski (1) , Gunnar Kudrjavets (2) ((1) Nicolaus Copernicus University , Toruń , Poland , (2) Amazon Web Services , Seattle
show 2 more authors
WA USA)
This is my paper · ORCID
classification cs.SEcs.CR
keywords LinuxkernelCVECVSSsurvivalanalysispatchlatencyLTSkernelsvulnerability-introducingcommitsbackporting
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Since the Linux kernel became its own Common Vulnerabilities and Exposures (CVE) Numbering Authority in 2024, the project has issued an order of magnitude more CVEs, making systematic study possible. Using 32,857 (LTS-branch, CVE) observations across six long-term support kernels, the paper shows that CVSS v3.1 base metrics and severity levels have essentially zero association with how long a vulnerability takes to fix (Somers' D ≈ 0), while kernel branch version age is a consistent, modest predictor: median fix time rises from about 1,112 days on the newest branch (6.12) to 2,677 days on the oldest (5.4). The paper also finds that vulnerability-introducing commits are typically far larger and broader than their fixes, and that many are squashed or refactored histories whose true introduction points have faded. A sympathetic reader would take this as an empirical confirmation that triaging kernel CVEs by CVSS score is ineffective, and that remaining on old LTS branches carries a measurable security cost.

What carries the argument

The analysis is carried by survival analysis: Kaplan-Meier survival curves estimate the probability that a CVE remains unfixed at time t, and Somers' D (a rank correlation for censored data) quantifies the association between a predictor and fix time, with bootstrap confidence intervals. The time axis is measured from the inferred vulnerability-introducing commit to the earliest fixing commit in each LTS branch, where introducing commits are inferred by a dyad-based tool and fixing commits by pattern matching in the kernel's CVE repository. Commit anatomy is annotated line-by-line by PatchScope into code/documentation/configuration/test categories. These together turn a heterogeneous CVE dat

What would settle it

Manually audit a random sample of, say, 100 CVE-introducing commit mappings using mailing-list history or bisection, then re-estimate median fix times on the corrected subset. If the median ordering across LTS branches flips or the gap between 6.12 and 5.4 collapses below, say, 500 days, the recency claim is an artifact of the mapping. Separately, if a dataset with balanced CVSS scores (not the near-constant current vectors) still shows no association with fix latency, the severity claim is corroborated; if not, it is refuted.

Watch

Extended reading notes

Core claim

The central discovery is a dissociation between two factors commonly assumed to drive patching. Across all CVSS v3.1 vector components and severity levels, Somers' D with time-to-fix is effectively zero with very narrow bootstrap confidence intervals, so severity does not predict fix latency. In contrast, the LTS branch's position in the kernel's release sequence does predict fix latency, with Somers' D = 0.13: median fix time is 1,112 days in branch 6.12, 1,427 in 6.6, 1,844 in 6.1, 1,960 in 5.15, 2,189 in 5.10, and 2,677 in 5.4. The authors also show that introducing commits are structurally larger (median 2 files, 56 added lines) than fixing commits (median 1 file, 4 added lines), and tha

Load-bearing premise

The whole time-to-fix measurement rests on the dyad-inferred vulnerability-introducing commit being the true moment a vulnerability entered the code; squashed commits, refactorings, and the 2005 BitKeeper-to-Git import can shift these dates, and the paper does not quantify how much bias that introduces.

Editorial extensions

If this is right

  • Organizations running older LTS kernels (5.4, 5.10) should expect known CVEs to remain unfixed for roughly 2,000-2,700 days on median, versus about 1,100 days on 6.12, so kernel version choice is a security parameter.
  • CVSS base scores and severity levels are not informative for prioritizing Linux kernel patches; decisions based on them are unlikely to reduce exposure.
  • The backlog of ~14 new kernel CVEs per day, combined with slow backporting to old branches, makes automated backporting and upstream-first strategies increasingly necessary.
  • Because introducing commits are large and often squashed, forensic estimates of vulnerability age are inherently approximate; bug-introduction data should be treated as a reconstruction, not a ground truth.
  • When a root cause is known, fixes tend to be tiny (≤9 lines in 75% of cases), so the practical bottleneck is detection and coordination, not patch size.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the kernel CNA ever assigned CVSS scores itself rather than inheriting NVD templates, the near-zero association could change; the paper's own association-rule analysis shows the current vectors are almost constant, so the severity result may reflect template uniformity rather than a true indifference to severity.
  • The recency gradient could be partly explained by maintenance effort being concentrated on branches that serve more users; D = 0.13 leaves substantial room for other drivers such as subsystem maintainership and backport difficulty.
  • A practical test the paper implies but doesn't run: compare fix latency between CVEs of the same age but different architecture or subsystem; if subsystem explains more variance than branch age, the 'move to latest' recommendation could be refined into 'move to well-staffed subsystems.'
  • The 2005 import commit artifact affects all branches similarly, so the relative gradient likely survives its removal, but absolute lifetime numbers should be read as upper bounds for true vulnerability age.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper analyzes 6,464 Linux kernel CVEs issued since the kernel became its own CNA, combining NVD metadata, kernel commit data, dyad/strak/verhaal tooling, and survival analysis to answer three RQs. RQ1 finds that vulnerability-introducing commits are substantially larger and more heterogeneous than fixing commits. RQ2 reports that CVSS v3.1 metrics and severity levels have a negligible association with fix latency, with Somers' D approximately zero. RQ3 reports that newer LTS branches are associated with shorter fix times, with D_xy = 0.13 and median fix times rising from 1,112 days in 6.12 to 2,677 days in 5.4. The paper concludes with practical recommendations to move to newer kernels and not to rely on CVSS for triage.

Significance. If the results hold, this is one of the first large-scale quantitative studies of the Linux kernel CNA era, and the replication package and CVE-commit mappings are valuable community assets. The survival-analysis framing and the CVSS negative result are useful contributions. However, the most practically consequential claim — that kernel recency drives fix speed — is currently supported only by a marginal, cross-sectional comparison across LTS branches, and the CVSS null result is limited by severe vector imbalance and non-random missingness. The paper needs additional within-CVE and sensitivity analyses before the policy-level recommendations are warranted.

major comments (3)
  1. [§5.5, Table 6, Fig. 4] The RQ3 result is computed on the marginal distribution of time-to-fix across (LTS, CVE) observations. Because a CVE appears in a branch only when the vulnerable code is present and the fix is backported to that branch, the six branch populations are not exchangeable: 6.12 and 6.6 are enriched for recently introduced or recently fixed flaws, while 5.4 and 5.10 include long-lived flaws that were never carried forward. The reported gradient (median 1,112 vs 2,677 days; D_xy=0.13) therefore conflates branch age with CVE composition, and Section 7 does not mention this threat. I request a within-CVE analysis: for CVEs observed in multiple branches, compare fix times in the newer and older branches (paired differences or stratified survival), and report the gradient restricted to a common introduction-era cohort. Without this, the Section 8.1.1 recommendation to "move to the latest kernel ver
  2. [§3, §5.2, Table 6] The start time T_s comes from dyad-inferred introducing commits, and the paper itself states these are approximations affected by squashing and pre-Git history. The footnote in §5.2 says many CVEs are associated with the 2005 BitKeeper-to-Git import commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, which "distorts many CVE associations." This is not a minor caveat: every branch in Table 6 has max time-to-fix 7,396 days, equal to the interval from that commit to the study end, indicating that a substantial number of observations are anchored to this one commit. I ask the authors to (i) report how many LTS-CVE observations have T_s = 1da177e, (ii) re-run Table 6 and D_xy with those observations excluded, and (iii) include this as an explicit sensitivity analysis in Section 7.
  3. [§5.4, Tables 1 and 5] The severity-null conclusion is stated as "negligible association," but the test has limited sensitivity on this dataset. Only 43% of LTS-CVE pairs have CVSS metadata, and coverage varies strongly by branch (31% for 6.12 vs 62% for 5.4, Table 1), so missingness is not random. Moreover, §5.3 shows that >95% of vectors follow one template; Somers' D on such an imbalanced ordinal predictor cannot detect non-monotonic or threshold effects. The significant log-rank results are dismissed without reporting the magnitude or direction of the differences other than the near-zero D. I recommend softening the title/RQ2 claim to "no monotonic association is detectable in the current data" and adding an analysis that conditions on the dominant vector combination or uses regression with clustered standard errors.
minor comments (6)
  1. [Table 5] The confidence intervals are reported as [-0.0,-0.0] or [-0.01,-0.01]; please report raw Somers' D values to at least three decimal places and state the number of comparable pairs used for each metric.
  2. [Figure 2] Because one commit can contribute to multiple annotation panels, the caption should state explicitly that the bars do not sum to 100% across panels; currently this is only implied in a parenthetical.
  3. [§5.4] The log-rank robustness check is mentioned in the text but the test statistic, degrees of freedom, and p-values are not reported, and the method is not described in Section 3. Add details or remove the reference.
  4. [§5.2] The spot check is described as 20 random large commits plus 3 added edge cases. Please report how the 3 additional commits were selected and whether any of the 20 were excluded after review, so readers can assess the generalizability of the qualitative findings.
  5. [Table 1] The 'Unique CVE' column counts the same CVE in multiple LTS rows; this should be stated in the caption to avoid the impression that the rows are disjoint.
  6. [§8.1.1] The text calls the gradient a "simple interpretation" of Section 5.5. This should be explicitly tied to the within-CVE analysis requested above; as written it reads as endorsing a causal interpretation of a cross-sectional comparison.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper's empirical claims are measured from independent data, not derived from their inputs.

full rationale

The paper is an observational study, not a derivation. Time-to-fix is defined as the difference between a dyad-inferred introducing-commit timestamp and the earliest fixing-commit timestamp per LTS branch (Section 3, Eq. 1), while the predictors—CVSS v3.1 vectors from NVD and LTS branch identity—are external to the outcome construction. The CVSS null result is a direct rank association (Somers' D) between externally assigned metadata and measured fix latency; no CVSS parameter is fitted to latency and then 'predicted'. The recency gradient (D_xy=0.13, medians 1,112 days in 6.12 vs 2,677 days in 5.4) is an empirical contrast between branch survival curves; a branch label is not defined in terms of fix time, and the sign of the association is not forced by construction. The acknowledged limitations (dyad-inferred introduction times, the 2005 BitKeeper-to-Git import commit, branch-composition confounding) are construct-validity and confounding concerns, not circular steps: they question whether the measured quantity is unbiased, not whether the result is equivalent to an input. Self-citations are limited to tool attribution (PatchScope [31]), an earlier CVE-lifetime study [37], and a position paper [26]; none is used as a load-bearing uniqueness theorem or as a substitute for the present data analysis. Therefore the paper is self-contained for its empirical conclusions and should not receive an elevated circularity score.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central claims rest on inferred commit mappings and branch-level comparability; no fitted model parameters or invented entities are introduced. The main burden is data-provenance assumptions.

assumptions (5)
  • domain assumption dyad's inferred vulnerability-introducing commits accurately represent introduction times for the CVE-to-fix timeline.
    All time-to-fix and commit-size analyses start from these inferred mappings; Section 3 and Section 5.2 acknowledge approximations but the quantitative results assume the bias is not material.
  • domain assumption The kernel CVE repository and NVD provide complete and correct CVE-fix-commit links and CVSS metadata for the six LTS branches.
    Data collection relies on strak/dyad/verhaal and NVD API; missing links or retroactive assignments would alter survival and severity analyses (Section 4).
  • domain assumption Right-censored survival observations are exchangeable across LTS branches, with no unmeasured branch-age composition confound.
    Median fix times are compared directly across branches in Section 5.5; if newer branches contain a larger share of recently introduced CVEs, the recency gradient is partly an artifact.
  • domain assumption PatchScope default settings classify changed lines into code/doc/config/test categories validly for comparing commit structures.
    Section 3.1 uses PatchScope with default settings; annotation errors would bias the RQ1 asymmetry.
  • domain assumption Line churn (LOC) is a meaningful proxy for the 'cost' and complexity of a change.
    The paper explicitly defines cost as LOC churn; this is a construct assumption, acknowledged in Section 1 and Threats to Validity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Linux Kernel Recency Matters, CVE Severity Doesn't, and History Fades." pith.science (2026). https://pith.science/paper/HFLFGAU4

@misc{pith2026260122196,
  author       = {Pith},
  title        = {Pith review of: Linux Kernel Recency Matters, CVE Severity Doesn't, and History Fades},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HFLFGAU4}},
  note         = {Machine review of arXiv:2601.22196}
}
read the original abstract

In 2024, the Linux kernel became its own Common Vulnerabilities and Exposures (CVE) Numbering Authority (CNA), formalizing how kernel vulnerabilities are identified and tracked. We analyze the anatomy and dynamics of kernel CVEs using metadata, associated commits, and patch latency to understand what drives patching. Results show that severity and Common Vulnerability Scoring System (CVSS) metrics have a negligible association with patch latency, whereas kernel recency is a reasonable predictor in survival models. Kernel developers fix newer kernels sooner, while older ones retain unresolved CVEs. Commits introducing vulnerabilities are typically broader and more complex than their fixes, though often only approximate reconstructions of development history. The Linux kernel remains a unique open-source project -- its CVE process is no exception.

Figures

Figures reproduced from arXiv: 2601.22196 by the authors.

Figure 1
Figure 1. Data collection pipeline in which CVEs and fix [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Distribution of commit sizes by annotation type for vulnerability-introducing (top row) and fixing (bottom row) [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. CVSS v3.1 distribution (radar plot) in Linux LTS 5.4 [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Survival analysis of CVE fix latency across Linux [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

54 extracted references · 6 canonical work pages

  1. [1]

    2015.Improving the Linux kernel with upstream contributions

    Engineering at Meta. 2015.Improving the Linux kernel with upstream contributions. Retrieved October 20, 2025 from https://engineering.fb.com/2015/10/05/open- source/improving-the-linux-kernel-with-upstream-contributions/

    2015

  2. [2]

    Benjamin E. C. Boyter. 2025.Sloc Cloc and Code (scc). scc: v3.5.0. Retrieved October 20, 2025 from https://github.com/boyter/scc/

    2025

  3. [3]

    Gerardo Canfora, Michele Ceccarelli, Luigi Cerulo, and Massimiliano Di Penta

  4. [4]

    2024.Cyber Resilience Act, Article 14—Reporting obliga- tions of manufacturers

    European Commission. 2024.Cyber Resilience Act, Article 14—Reporting obliga- tions of manufacturers. Retrieved October 20, 2025 from https://www.european- cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html

    2024

  5. [5]

    2024.Cyber Resilience Act (CRA)

    European Commission. 2024.Cyber Resilience Act (CRA). Retrieved October 20, 2025 from https://www.european-cyber-resilience-act.com/Cyber_Resilience_ Act_Articles.html

    2024

  6. [6]

    2023.Reducing kernel-maintainer burnout

    Jonathan Corbet. 2023.Reducing kernel-maintainer burnout. Retrieved October 20, 2025 from https://lwn.net/Articles/952034/

    2023

  7. [7]

    2024.A turning point for CVE numbers

    Jonathan Corbet. 2024.A turning point for CVE numbers. Retrieved October 20, 2025 from https://lwn.net/Articles/961978

    2024

  8. [8]

    Stefan Frei, Martin May, Ulrich Fiedler, and Bernhard Plattner. 2006. Large-scale vulnerability analysis. InProceedings of the 2006 SIGCOMM Workshop on Large- Scale Attack Defense, LSAD ’06, Pisa, Italy, September 11-15, 2006. ACM, 131–138. doi:10.1145/1162666.1162671

    arXiv 2006

Show all 54 references
  1. [9]

    2024.How CrowdStrike Stopped Everything

    David Geer. 2024.How CrowdStrike Stopped Everything. Retrieved October 20, 2025 from https://cacm.acm.org/news/how-crowdstrike-stopped-everything

    2024

  2. [10]

    2024.Common Vulnerability Scoring System version 4.0: Specification Document

    CVSS Special Interest Group. 2024.Common Vulnerability Scoring System version 4.0: Specification Document. Retrieved December 6, 2025 from https://www.first. org/cvss/v4-0/specification-document

    2024

  3. [11]

    Householder, Jeff Chrabaszcz, Trent Novelly, David Warren, and Jonathan M

    Allen D. Householder, Jeff Chrabaszcz, Trent Novelly, David Warren, and Jonathan M. Spring. 2020. Historical Analysis of Exploit Availability Timelines. In13th USENIX Workshop on Cyber Security Experimentation and Test, CSET 2020, August 10, 2020, Tamara Denning and Tyler Moor...

    2020

  4. [12]

    Ayelet Israeli and Dror G Feitelson. 2010. The Linux kernel as a case study in software evolution.Journal of Systems and Software83, 3 (2010), 485–501. doi:10.1016/j.jss.2009.09.042

    2010 doi

  5. [13]

    Oskar Jarczyk, Blazej Gruszka, Szymon Jaroszewicz, Leszek Bukowski, and Adam Wierzbicki. 2014. GitHub Projects. Quality Analysis of Open-Source Software. In Social Informatics - 6th International Conference, SocInfo 2014, Barcelona, Spain, November 11-13, 2014. Proceedings (Le...

    2014

  6. [14]

    Yujuan Jiang, Bram Adams, and Daniel M. German. 2013. Will My Patch Make It? And How Fast?: Case Study on the Linux Kernel. InProceedings of the 10th Working Conference on Mining Software Repositories(San Francisco, CA, USA) (MSR ’13). IEEE Press, 101–110. doi:10.1109/MSR.2013.6624016

    2013

  7. [15]

    E. L. Kaplan and Paul Meier. 1958. Nonparametric Estimation from Incomplete Observations.J. Amer. Statist. Assoc.53, 282 (1958), 457–481. doi:10.1080/01621459. 1958.10501452

    1958

  8. [16]

    2018.What Stable Kernel Should I Use

    Greg Kroah-Hartman. 2018.What Stable Kernel Should I Use. Retrieved October 20, 2025 from http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel- should-i-use/

    2018

  9. [17]

    Greg Kroah-Hartman. 2019.CVEs are dead, long live the CVE!Retrieved October 20, 2025 from https://www.youtube.com/watch?v=HeeoTE9jLjM Presented at the Kernel Recipes 2019, Paris, France, Sep 25–27, 2019

    2019

  10. [18]

    2023.Demystifying the Linux kernel security pro- cess

    Greg Kroah-Hartman. 2023.Demystifying the Linux kernel security pro- cess. Retrieved October 20, 2025 from https://www.youtube.com/watch?v= 2TZe5EROFhE Presented at the Kernel Recipes 2019, Paris, France, Sep 25–27, 2023

    2023

  11. [19]

    2024.CVEs are alive, but no not panic!Retrieved October 20, 2025 from https://kernel-recipes.org/en/2024/cves-are-alive-but-no-not-panic/

    Greg Kroah-Hartman. 2024.CVEs are alive, but no not panic!Retrieved October 20, 2025 from https://kernel-recipes.org/en/2024/cves-are-alive-but-no-not-panic/

    2024

  12. [20]

    2024.Linux is a CNA

    Greg Kroah-Hartman. 2024.Linux is a CNA. Retrieved October 20, 2025 from http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/

    2024

  13. [21]

    2024.Linux is now a CNA

    Greg Kroah-Hartman. 2024.Linux is now a CNA. Retrieved October 20, 2025 from https://social.kernel.org/notice/Aeroz3uO3oYwL7Y5qK

    2024

  14. [22]

    2024.Linux Kernel CVEs: What Has Caused So Many to Suddenly Show Up?The Linux Foundation

    Greg Kroah-Hartman. 2024.Linux Kernel CVEs: What Has Caused So Many to Suddenly Show Up?The Linux Foundation. Retrieved October 20, 2025 from https://www.youtube.com/watch?v=KumwRn1BA6s

    2024

  15. [23]

    2024.Official CVE definition of vulnerability

    Greg Kroah-Hartman. 2024.Official CVE definition of vulnerability. Retrieved October 20, 2025 from https://git.kernel.org/pub/scm/linux/security/vulns.git/ tree/cve/vulnerability.txt

    2024

  16. [24]

    Greg Kroah-Hartman. 2024.Repo for tracking and maintaining the CVE identifiers reserved and assigned to the Linux kernel project.Retrieved October 20, 2025 from https://git.kernel.org/pub/scm/linux/security/vulns.git

    2024

  17. [25]

    2025.Linux Stable Commit Parse and Query Tool - Sourcehut Git

    Greg Kroah-Hartman. 2025.Linux Stable Commit Parse and Query Tool - Sourcehut Git. Retrieved October 20, 2025 from https://git.sr.ht/~gregkh/verhaal

    2025

  18. [26]

    Gunnar Kudrjavets. 2025. Patch Me If You Can—Securing the Linux Kernel. In 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR). 142–143. doi:10.1109/MSR66628.2025.00031

    2025

  19. [27]

    Upstream First

    Michael Larabel. 2021.Google Finally Shifting To "Upstream First" Linux Kernel Approach For Android Features. Retrieved October 20, 2025 from https://www. phoronix.com/news/Android-Linux-Upstream-First

    2021

  20. [28]

    2025.AUTOSEL: Modern AI-powered Linux Kernel Stable Back- port Classifier

    Sasha Levin. 2025.AUTOSEL: Modern AI-powered Linux Kernel Stable Back- port Classifier. Retrieved October 20, 2025 from https://lwn.net/ml/all/aBj_ SEgFTXfrPVuj@lappy/

    2025

  21. [29]

    2012.Survival Analysis: Models and Applications

    Xian Liu. 2012.Survival Analysis: Models and Applications. John Wiley & Sons, Hoboken, NJ, USA. doi:10.1002/9781118307656

    2012 doi

  22. [30]

    Antonio Nappa, Richard Johnson, Leyla Bilge, Juan Caballero, and Tudor Du- mitras. 2015. The Attack of the Clones: A Study of the Impact of Shared Code on Vulnerability Patching. In2015 IEEE Symposium on Security and Privacy, SP 2015, San Jose, CA, USA, May 17-21, 2015. IEEE C...

    2015 doi

  23. [31]

    Jakub Nar e ¸bski, Mikołaj Fejzer, Krzysztof Stencel, and Piotr Przymus. 2025. PatchScope—A Modular Tool for Annotating and Analyzing Contributions. In Proceedings of the 34th ACM SIGSOFT International Symposium on Software Test- ing and Analysis(Clarion Hotel Trondheim, Trond...

    2025

  24. [32]

    2022.CVEs and the NVD Process

    National Institute of Standards and Technology. 2022.CVEs and the NVD Process. Retrieved October 20, 2025 from https://nvd.nist.gov/general/cve-process

    2022

  25. [33]

    Roger B Newson. 2010. Comparing the predictive powers of survival models using Harrell’s C or Somers’ D.The Stata Journal10, 3 (2010), 339–358. doi:10. 1177/1536867X10010003

    2010

  26. [34]

    2022.Removing the stigma of a CVE

    Madison Oliver. 2022.Removing the stigma of a CVE. Retrieved October 20, 2025 from https://github.blog/security/vulnerability-research/removing-the-stigma- of-a-cve/

    2022

  27. [35]

    2024.A script to calculate the number of Linux kernel CVEs published and rejected

    SeongJae Park. 2024.A script to calculate the number of Linux kernel CVEs published and rejected. Retrieved October 20, 2025 from https://github.com/sjp38/ lazybox/blob/master/cve_stat/vulns_stat.sh

    2024

  28. [36]

    2018.FedRAMP Vulnerability Scanning Requirements

    Federal Risk and Authorization Management Program. 2018.FedRAMP Vulnerability Scanning Requirements. Retrieved December 6, 2025 from https://www.fedramp.gov/resources/documents/rev4/REV_4_CSP_ Vulnerability_Scanning_Requirements.pdf

    2018

  29. [37]

    Piotr Przymus, Mikołaj Fejzer, Jakub Nare ¸bski, and Krzysztof Stencel. 2023. The Secret Life of CVEs. In2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR). IEEE, 362–366. doi:10.1109/msr59073.2023.00056

    2023

  30. [38]

    Piotr Przymus, Witold Weiner, Krzysztof Rykaczewski, and Gunnar Kudrjavets

  31. [39]

    Naveen Raman, Minxuan Cao, Yulia Tsvetkov, Christian Kästner, and Bogdan Vasilescu. 2020. Stress and burnout in open source: toward finding, understanding, and mitigating unhealthy interactions. InProceedings of the ACM/IEEE 42nd International Conference on Software Engineerin...

    2020

  32. [40]

    2024.The EU Cyber Resilience Act: Strengthening Digital Security across Europe

    The Horizon Europe Research and Innovation Project DOSS. 2024.The EU Cyber Resilience Act: Strengthening Digital Security across Europe. Retrieved October 20, 2025 from https://dossproject.eu/the-eu-cyber-resilience-act-strengthening- digital-security-across-europe/

    2024

  33. [41]

    Lucas Serrano, Van-Anh Nguyen, Ferdian Thung, Lingxiao Jiang, David Lo, Julia Lawall, and Gilles Muller. 2020. SPINFER: Inferring Semantic Patches for the Linux Kernel. InProceedings of the 2020 USENIX Conference on Usenix Annual Technical Conference (USENIX ATC’20). USENIX As...

    2020

  34. [42]

    Duck, Shin Hwei Tan, Julia Lawall, and Abhik Roychoudhury

    Ridwan Shariffdeen, Xiang Gao, Gregory J. Duck, Shin Hwei Tan, Julia Lawall, and Abhik Roychoudhury. 2021. Automated patch backporting in Linux (experience paper). InProceedings of the 30th ACM SIGSOFT International Symposium on Soft- ware Testing and Analysis(Virtual, Denmark...

    2021

  35. [43]

    Forrest Shull, Janice Singer, and Dag I. K. Sjøberg. 2008.Guide to Advanced Empirical Software Engineering. Springer, London

    2008

  36. [44]

    Xin Tan and Minghui Zhou. 2019. How to Communicate When Submitting Patches: An Empirical Study of the Linux Kernel.Proc. ACM Hum.-Comput. Interact.3, CSCW, Article 108 (nov 2019), 26 pages. doi:10.1145/3359210

    2019 doi

  37. [45]

    2025.How the development process works

    The kernel development community. 2025.How the development process works. Retrieved October 20, 2025 from https://www.kernel.org/doc/html/v6.16/process/ 2.Process.html

    2025

  38. [46]

    2012.Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)

    Linus Torvalds. 2012.Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1). Retrieved October 20, 2025 from https: //lkml.org/lkml/2012/12/23/75

    2012

  39. [47]

    2024.A Look at 3 Months of Linux Kernel CVEs

    TuxCare. 2024.A Look at 3 Months of Linux Kernel CVEs. Retrieved October 20, 2025 from https://tuxcare.com/wp-content/uploads/2024/07/TuxCare-Report-3- Months-of-Kernel-CVEs.pdf Linux Kernel Recency Matters, CVE Severity Doesn’t, and History Fades MSR ’26, April 13–14, 2026, R...

    2024

  40. [48]

    Mario Linares Vásquez, Gabriele Bavota, and Camilo Escobar-Velasquez. 2017. An empirical study on Android-related vulnerabilities. InProceedings of the 14th International Conference on Mining Software Repositories, MSR 2017, Buenos Aires, Argentina, May 20-28, 2017, Jesús M. G...

    2017 doi

  41. [49]

    2023.Long-term support for Linux kernel to be cut as maintenance remains under strain

    Steven Vaughan-Nichols. 2023.Long-term support for Linux kernel to be cut as maintenance remains under strain. Retrieved October 20, 2025 from https://www.zdnet.com/article/long-term-support-for-linux-kernel-to-be- cut-as-maintenance-remains-under-strain/

    2023

  42. [50]

    Michael Wedel, Uwe Jensen, and Peter Göhner. 2008. Mining software code repositories and bug databases using survival analysis models. InProceedings of the Second International Symposium on Empirical Software Engineering and Measurement, ESEM 2008, October 9-10, 2008, Kaisersl...

    2008

  43. [51]

    2025.Triaging Security Issues Reported by Third Parties

    Nick Wellnhofer. 2025.Triaging Security Issues Reported by Third Parties. Re- trieved October 20, 2025 from https://gitlab.gnome.org/GNOME/libxml2/-/issues/ 913

    2025

  44. [52]

    Su Yang, Yang Xiao, Zhengzi Xu, Chengyi Sun, Chen Ji, and Yuqing Zhang. 2023. Enhancing OSS Patch Backporting with Semantics. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security(Copenhagen, Denmark)(CCS ’23). Association for Computing Machin...

    2023

  45. [2011]

    In18th Working Conference on Reverse Engineering, WCRE 2011, Limerick, Ireland, October 17-20, 2011, Martin Pinzger, Denys Poshyvanyk, and Jim Buckley (Eds.)

    How Long Does a Bug Survive? An Empirical Study. In18th Working Conference on Reverse Engineering, WCRE 2011, Limerick, Ireland, October 17-20, 2011, Martin Pinzger, Denys Poshyvanyk, and Jim Buckley (Eds.). IEEE Computer Society, 191–200. doi:10.1109/WCRE.2011.31

    2011 doi

  46. [2026]

    Linux Kernel Recency Matters, CVE Severity Doesn’t, and History Fades

    Replication package for survival analysis of CVE lines in Linux kernel repository: "Linux Kernel Recency Matters, CVE Severity Doesn’t, and History Fades". (1 2026). doi:10.6084/m9.figshare.31144963.v1

    2026 doi

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.