Which study? Old software has bugs that live for decades, even security bugs. I don't have a study to cite, just open bug trackers and CVE lists.
Which study? Old software has bugs that live for decades, even security bugs. I don't have a study to cite, just open bug trackers and CVE lists.
Found the reference (bless bookmark managers): https://security.googleblog.com/2024/09/eliminating-memory-s...
Relevant bits:
> vulnerabilities decay exponentially.
> A large-scale study of vulnerability lifetimes² published in 2022 in Usenix Security confirmed this phenomenon. Researchers found that the vast majority of vulnerabilities reside in new or recently modified code: [plot]
> This confirms and generalizes our observation⁴, published in 2021, that the density of Android’s memory safety bugs decreased with the age of the code, primarily residing in recent changes.
² https://www.usenix.org/conference/usenixsecurity22/presentat...
⁴ https://security.googleblog.com/2021/04/rust-in-android-plat...
Citing from [4]:
> The above analysis of the age of memory safety bugs in Android (measured from when they were first introduced) demonstrates why our memory-safe language efforts are best focused on new development and not on rewriting mature C/C++ code. Most of our memory bugs occur in new or recently modified code, with about 50% being less than a year old.
I admit it is difficult to infer your intention on the classification of "old code vs new code". I don't see evidence that new code is inherently worse than old code, including in the cited study. There is correlation that people forget lessons learned in the past, but that's as far as I would evaluate the data.
> vulnerabilities decay exponentially.
Because they get fixed over time. That isn't controversial. They also persist over time. The quoted observation depends on proactive maintenance. But proactive maintenance is also the only cause of new bugs by definition. "Recently modified code" stands out in the last paragraph. This study is not talking about stable code.
> Perhaps you meant "correct code", and not necessarily "old" or "stable" code.
That sounds like a circular statement to me: if the code is correct, it can't have bugs, because bugs are when it does something wrong. Calling it stable seems fair to me, idk which would be most precise and bestest choice of words but that hopefully conveys the concept of some software product that hasn't majorly changed but also isn't just abandoned (say, a part of Firefox that hasn't been rewritten in forever, but Mozilla continues to apply any fixes to it when bugs are reported), for which I think the statement holds
> The quoted observation depends on proactive maintenance.
Yeah, that's the issue with my original wording of "old", where I can totally see the other interpretation coming to mind first. It's not that people who lived longer ago wrote better code :p. Quite the opposite: the effect of awareness increases over the decades is very visible in my work as security tester
The only thing I can conclude is that a more rigorous methodology for authoring code is more valuable than cleaning up after oneself later.
> the effect of awareness increases over the decades is very visible in my work as security tester
This absolutely matches my own feeling on the value of experience. Knowing what not to do is where practically all of my efficiency comes from, having learned that the hard way.