In fact, these results imply that the benefits of re-writing the world are limited in terms of security. This raises the cost-benefit ratio of keeping mature legacy code and only using memory-safe languages for new code.

This also implies that languages and tooling with robust support for integrating with unsafe legacy code are even more desirable.

Rewrites are so expensive that they're going to be very rare. But incremental nibbling at the edges is very effective.

I wonder if there's a "bathtub curve" effect for very old code. I remember when a particularly serious openssl vulnerability (heartbleed?) caused a lot of people to look at the code and recoil in horror at it.

From security perspective I agree but what if you want to be rid of GC or just reduce your overall resource consumption?

I'm here with you for the downvotes.

This essay takes some interesting data from very specific (and unusual) projects and languages from a very specific (and unusual) culture and stridently extrapolates hard numeric values to all code without qualification.

> For example, based on the average vulnerability lifetimes, 5-year-old code has a 3.4x (using lifetimes from the study) to 7.4x (using lifetimes observed in Android and Chromium) lower vulnerability density than new code.

Given this conclusion, I can write a defect-filled chunk of C code and just let it marinate for 5 years offline in order for it become safe?

I'm pretty sure there are important data in this research and there is truth underneath what is being shared, but the unsupported confidence and overreach of the writing is too distracting for me.

Individual bugs triggered in normal operation ought to decay over time on software that is maintained. If bugs cause problems, someone may report them and some fraction of them will be fixed. That's a decay mechanism.

Not-yet exploited vulnerabilities, though, don't have that decay mechanism. They don't generate user unhappiness and bug reports. They just sit there, until an enemy with sufficient resources and motivation finds and exploits them.

There are more enemies in that league than there used to be.

> vulnerabilities decay exponentially

This should be true not just of vulnerabilities, but bugs of any kind. I certainly see this in testing of the free software project I'm involved with (SBCL). New bugs tend to be in parts that have been recently changed. I'm sure you all have seen the same sort of effect.

(This is not to say all bugs are in recent code. We've all seen bugs that persist undetected for years. The question for those should be how did testing miss them.)

So this suggests testing should be focused on recently changed code. In particular, mutation testing can be highly focused on such code, or on code closely coupled with the changed code. This would greatly reduce the overhead of applying this testing.

Google has had a system where mutation testing has been used with code reviews that does just this.

This is why I advise most folks to not take the latest point release of your language or libraries.

The bleeding edge is where many of the new vulns are. In general the oldest supported release is usually the safest.

The trade-off is when newer versions have features which will add value, of course. But usually a bad idea to take any version that ends “.0” IMO.

Or an alternative approach: only compile the subset of features you explicitly need.

Obviously there’s a ton of variance in how practical this is any place, but it’s less common than it should be.

> that it would be even better for security to stop adding new features when they aren't absolutely necessary

Even if features aren't necessary to sell your software, new hardware and better security algorithms or full on deprecation of existing algos will still happen. Which will introduce new code.

That makes sense because the #1 reason I have had to roll back my own C++ commits is due to crashes from some dumb failure to check whether a null pointer is null. If Rust is going to prevent that issue and other similar issues of stupid coding, you would expect whole classes of rollbacks to go away.

That’s very kind, thank you.

A few thoughts:

People who care about this issue, especially in the last few years, have been leaning into a "memory safe language" vs "non memory safe language" framing. This is because it gets at the root of the issue, which is safe by default vs not safe by default. It tries to avoid pointing fingers at, or giving recommendations for, particular languages, by instead putting the focus on the root cause.

In the specific case of Android, the subject of this post, I'm not aware of attempts to move into other MSLs than those. But I also don't follow Android development generally, but I do follow these posts pretty closely, and I don't remember any of them talking about stuff other than Rust or Kotlin.

It's not just Rust—rewriting a C network service into Java or Python or Go is also an example of transitioning to memory safe languages. The point is that you're not exposed to memory safety bugs in your own code. Arguably it's much better to choose a language without Rust-like manual memory management when you don't absolutely need it.

Android talked more about the memory-safe languages they're using in a previous blog post: https://security.googleblog.com/2022/12/memory-safe-language...

Google also published their perspective on memory safety in https://security.googleblog.com/2024/03/secure-by-design-goo..., which also goes over some of the memory-safe languages in use like Java, Go and Rust.

There are many and google uses several - rust, python, java, and go among them. But low-level code for Android has historically been in c++ and Rust is the primary memory-safe replacement for the stuff they're building.

There are many memory safe languages, but not many of those are compiled and able to offer performance that is in the same ballpark as C.

Rust and Swift are the two most widely used.

Interestingly, Swift had interoperating with C as an explicit design goal, while Rust had data race safety as a design goal.

Now we have data race safety added in the latest version of Swift, and Rust looking to improve interoperability with C.

Java and Kotlin are used for apps. Rust is used for new system software.

Across Google, Go is used for some system software, but I haven't seen it used in Android.

Kotlin is memory-safe. It runs with a GC.

    > memory safe languages

Edit: I forgot Golang!

That is the separation between abstract considerations and a given projects constraints. In a given project there might be few choices, but if you talk about fundamental phenomena, you have to reason about arbitrary projects. And of course, there are plenty of alternatives to Rust. Even limited to Android, there are several choices, even if they might be a smaller set.

Google has always tried to use a small set of languages. For Android they try to use C/C++, Java/Kotlin, and now Rust. The same lessons still apply in rampantly polyglot environments though.

Perhaps they are even considering carbon to be memory safe

> what if older code isn't being looked at as hard and therefore vulnerabilities aren't being discovered?

It wasn’t being look at as hard before either. I don’t think that’s changed.

They don’t give a theory for why older code has fewer bugs, but I’ve got one: they’ve been found.

If we assumed that any piece of code has a fixed amount of unknown bugs per 1000 lines, it stands to reason that overtime the sheer number of times the code is run with different inputs in prod makes it more and more likely they will be discovered. Between fixing them and the code reviews while fixing them the hope would be that on average things are being made better.

So overtime, there are fewer bugs per thousand lines in existing code. It’s been battle tested.

As the post says, if you continue introducing new bugs at the same rate you’re not going to make progress. But if using a memory safe language means you’re introducing fewer bugs in new features then overtime the total number of bugs should be going down.

I don’t understand this point. The project under scrutiny is Android and people are detecting vulnerabilities both manually and automatically based on source code/binary, not over commit logs. Why would the commit logs be relevant at all to finding bugs?

The commits are just used for attribution. If there was some old lib that hasn’t been changed in 20 years that’s passed fuzzing and manual code inspection for 20 years without updates, chances are it’s solid.

I wasn’t entirely satisfied with the assertion that older code has fewer vulnerabilities either. It feels like there could be explanations other than age for the discrepancy.

For example: maybe the engineers over the last several years have focused on rewriting the riskiest parts in a MSL, and were less likely to change the lower risk old code.

Or… maybe there was a process or personnel change that led to more defects.

With that said, it does seem plausible to me that any given bug has a probability of detection per unit of time, and as time passes fewer defects remain to be found. And as long as your maintainers fix more vulnerabilities than they introduce, sure, older code will have fewer and the ones that remain are probably hard to find.

Their concern is not with theoretical vulnerabilities, but actual ones that are being exploited. If an attacker never tries to find a vulnerability in some code, then it might as well not have it.

Apple is still adding large amounts of new Objective-C code in each new macOS version [0].

I haven't found any language usage numbers for recent versions of Windows, but Microsoft is using Rust for both new development and rewriting old features [1] [2].

[0] Refer to section "Evolution of the programming languages" https://blog.timac.org/2023/1128-state-of-appkit-catalyst-sw...

[1] https://www.theregister.com/2023/04/27/microsoft_windows_rus...

[2] https://www.theregister.com/2024/01/31/microsoft_seeks_rust_...

> while Windows still uses primarily uses C or C++.

Do you have data for that? My impression is that a large fraction of Windows development is C# these days. Back when I was at EA, nearly fifteen years ago, we were already leaning very heavily towards C# for internal tools.

For more information on our safe coding approach, as applied to the web domain, check out this paper (https://static.googleusercontent.com/media/research.google.c...) or this talk (https://www.youtube.com/watch?v=ccfEu-Jj0as).

The counter intuitive part is that there is now more code written in memory unsafe languages than there was before. Even if it's just bug fixing.

It's not as if bug fixes haven't resulted in new memory bugs, but apparently that rate is much lower in bug fixes than it is in brand new code.

I think the standard assumption would be that you need to start replacing older code with memory safe code to see improvements.

Instead they’ve shown that only using memory safe languages for new code is enough for the total bug count to drop.

You can't really write a library in Java or Go that a C program can use. The real magic is memory safety without GC and a huge runtime. But if you point that out people will call you a fanboy.

Is it?

If you add up all the JavaScript, C#, Java, Python, and PHP being written every year, that’s a lot of code.

Are we sure that all that combined isn’t more than C/C++? Or at least somewhat close?

Doesn't libc interface requirement of C/C++ use, create massive downstream challenges for other languages to gain super mass adoption (at the OS level).

Neither Pascal nor Ada are memory-safe.

60 years since NEWP/ESPOL/JOVIAL.

ESPOL is one of the first recorded uses of unsafe code blocks, 1961.

Well, that tells us something...

People have a finite amount of time and effort they can spend on making the code correct. When the language is full of traps, spec gotchas, antiquated misfeatures, gratuitous platform differences, fragmented build systems, then a lot of effort is wasted just on managing all of that nonsense that is actively working against writing robust code, and it takes away from the effort to make a quality product beyond just the language-wrangling.

You can't rely on people being perfect all the time. We've been trying that for 50 years, and only got an endless circle of CVEs and calls to find better programmers next time.

The difference is how the language reacts to the mistakes that will happen. It could react with "oops, you've made a mistake! Here, fix this", and let the programmer apply a fix and move on, shipping code without the bug. Or the language could silently amplify smallest mistakes in the least interesting code into corruption that causes catastrophic security failures.

When concatenating strings and adding numbers securely is a thing that exists, and a thing that requires top-skilled programmers, you're just wasting people's talent on dumb things.

No, this just isn't how it works. You'll find business logic, domain-specific, and systems programming security errors on every platform, but you don't find them with the density and the automatic severity you do memory safety issues. This is not about "language hipsters".

> You have a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. They write code with memory safety bugs.

We should really stop putting the blame on developers. The issue is not that developers are sub-par, but that they are provided with tools making it virtually impossible to write secure software. Everyone writes memory safety bugs when using memory-unsafe languages.

And one helpful insight here is that the security posture of a software application is substantially an emergent property of the developer ecosystem that produced it, and that includes having secure-by-design APIs and languages. https://queue.acm.org/detail.cfm?id=3648601 goes into more details on this.

I mostly agree with you but take the opposite position: attacking memory safety bugs has been so successful that we should use the same pattern on other large classes of bugs.

It's absolutely possible to write a reasonably usable language that makes injection/escaping/pollution/datatype confusion errors nearly impossible, but it would involve language support and rewriting most libraries--just like memory safety did. Unfortunately we are moving in the opposite direction (I'm still angry about javascript backticks, a feature seemingly designed solely to allow the porting of php-style sql injection errors)

It is 100-1000 times harder to find application-level security bugs than it is to find memory safety bugs.

It is also far easier to apply formal analysis to code if you don't have to model arbitrary pointers.

Android has hard evidence that just eliminating memory safety makes a significant difference.

> There's a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques.

…which are?

> old, well documented, stable, memory-safe functions and techniques.

I'm sorry, are we still talking about C here? Where the old functions are the ones that are explicitly labelled as too dangerous to use, like strcmp()?

I think it is somewhat about security. The "Nobody can write secure C/C++ code" nonsense translates to "We are not at fault that are products are broken garbage, because it is simply impossible to write secure code." Now we can pretend to fix "a whole class of errors" (as long as there is no "unsafe" anywhere) by imposing Rust on programmers (and the open-source community that then will produce memory safe code for free for some to use) and while this may indeed help a bit, one can hope to avoid being really being held responsible for product security for another decade or so.

Having the tool actively prevent classes of errors is a worthwhile endeavor, but I do agree it gets overly focused on alone when several other _massive_ classes of vulnerabilities continue to be introduced. At a high level though, it is a lot easier to just have a framework enforce 'x' on all devs to raise the minimum bar. It doesn't help that the average Rust-bro, from which a lot of these memory safety arguments come from, is utterly terrible at making that case in reality. Case example: https://github.com/pyca/cryptography/issues/5771.

I think a lot of the arguments around C++ for example being 'memory unsafe' is a bit ridiculous because its trivial to write memory safe C++. Just run -Wall and enforce the use of smart pointers, there are nearly zero instances in the modern day where you should be dealing with raw pointers or performing offsets that lead to these bugs directly. The few exceptions are hopefully with devs that are intelligent enough to do so safely with modern language features. Unfortunately, this rarely gets focused on by security teams it seems since they are instead chasing the newest shiny language like you mention.