I’m super excited about this blogpost. The approach is so counterintuitive, and yet the results are so much better than anything else that we’ve tried for memory safety. We finally understand why.

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

@jeffvanderstoep Just realized I can write directly to an author :)

I have some doubts about this "half-life" metric, but maybe I don't get the full picture:

https://infosec.place/notice/AmO2BAowHxngnThcjg

@buherator

Why? It's consistent across all projects that the cited "large scale" study analyzed. It's also consistent when we looked at Android, which was not part of the study. When we change the behavior of development within Android, the result matched what we would expect based on the half-life metric.

When you look at studies that analyze how this works from the opposite angle "how much does it cost to find the next vulnerability in the same codebase?" you'll see a similar result. E.g. "On the Exponential Cost of Vulnerability Discovery" https://mboehme.github.io/paper/FSE20.EmpiricalLaw.pdf

There's a finite number of vulnerabilities within a code base. As the density drops, the cost of finding the next vulnerability will rise.

@jeffvanderstoep Thanks for your reply! I don’t doubt the validity of your measurement. I’d argue about two things:

• The simpler thing is communication: the phrase “half-life” or “decay” implies that vulns disappear without explicit dev intervention, e.g. as a side-effect of unrelated code changes (or even the passage of time!). While this may be true in some cases I don’t see how the data would (or could) support such an observation.
• My understanding is that when we look at overall results of different vuln discovery strategies (your study) or applying the same strategy with “more force” (Böhme-Falk) we basically see the effects of testing coverage, and it’s no surprise we can grow coverage faster in new code. What I think would be more revealing is looking at new vulns(/LoC?) vs code age when a new discovery method (e.g. a new sanitizer or more intelligent test-case generation ) is introduced. FTR: I bet such data would actually confirm your results, but without data about the effect of new discovery methods I think drawing conclusions about code “maturity” is much harder.