Comment by Aachen

2 days ago

That wasn't the claim. The claim is that stable code (that isn't changed except to fix bugs) has fewer bugs than code someone newly wrote and we haven't had as much time to run into or otherwise uncover flaws. I never meant that all old C code is bug-free craftsmanship or something xD

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.

A literal interpretation of the claim is, quoted directly, "old code has fewer bugs than new code". Now you've clarified that you meant "stable code", which is fair. But stability is not a guarantee of correctness. Perhaps you meant "correct code", and not necessarily "old" or "stable" code.

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.

  • Reading back, yeah I can see the alternative interpretation of what I wrote, that's fair

    > 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

    • What I'm trying to get at is that age and stability are only loosely correlated with correctness. I'll give you credit for calling out the tautology, and I don't think there is a way around it. Any code that is written without rigor is going to be buggy. The age/stability thing is a category error.

      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.