So we have it now. Rust solved a large number of the safety problems of the system language level. Not everything ofc, but still. Lot of them. And it is actually being adopted.
So I have a question for my cybersecurity/infosec crowd.
Have you introspected why 3 decades of yelling about that stuff got no results, 3 decades of sanitisers and fuzzers barely moved the needle, but Rust slam dunked it?
Where is the retrospective of what went wrong? Where are the learnings?
@Di4na We should recognise the possibility that it may have simply been random factors that caused the adoption of Rust where other solutions didn't take off; that there wasn't something specific Rust did right or the others did wrong.
@Di4na Lots and lots of devs don't get to choose what language they use to solve a problem.
For example, the problem may be in an existing codebase that's not theirs. Most of the problems Rust might fix are problems with existing codebases. The question was what made it successful at that.
@Di4na the way I heard it put is: Rust provides a great user experience, so of course it gets loved and adopted.
And a major (necessary but not sufficient) reason for why Rust provides such a great experience is that, initially, large companies invested like $100M into making it happen. Basically a team of many motivated talented people were working on solving this problem and making good UX for many years, full-time, not having to think about housing or food.
And we didn't see that kind of investment into any other tooling. And if we had, perhaps we would have other great things, too.
False on the second. After asking the question a lot, a conservative budget for Rust pre 2018 edition is around 10 to 20M over 10 years, only Mozilla funding. Nothing else.
Half the team was interns for most of that time, because of the low budget. And it was already the most loved language. It was not money.
But you are right with good UX. I think there is a little other aspect you missed, but it comes along.
@Di4na It made it easy. While Rust is a complex language, it made it comparatively easy to not run into lots of the common security issues, especially in the domain it is specifically applicable to (we don't really need to replace Java applications in terms of memory safety, for example).
I think there are other examples like that as well: Passkeys, for one. They make it easy to actually use public key cryptography for authentication, unlike physical FIDO tokens.
Let's Encrypt is a similar case.
They either just make life easier and produce better security as a by-product, or at least make better security not a huge PITA.
There are other spheres of security where we haven't yet achieved that. I'm mostly thinking about infrastructure security here: Most issues are about asset lists, keeping your systems up-to-date and knowing what you're running. Probably the solution will look like something that's using SBOMs, IaC and some automation waves frantically -- but it's not fully fleshed out yet.
> They either just make life easier and produce better security as a by-product, or at least make better security not a huge PITA.
In case of Rust, it's even making other things than security easier and thus improved the quality of life of devs, same for passkeys. Let's Encrypt didn't improve the QoL of those who didn't do HTTPS yet, but at least it made it substantially easier to run HTTPS.
@Di4na I feel like we're arguing quite confrontional despite being on the same page?
I'm not saying devs are lazy or love insecure software, far from it. They're just overworked, have a lot of things to juggle and honestly, many solutions required quite some specialization in security in order to use them. I.e., they were useless.
It doesn't matter that they wanted HTTPS if they don't find the time to roll it out. Neither whether they want memory safety.
Why I'm making a distinction b/w HTTPS and Rust is that using HTTPS does not make your developer's life easier. Shipping a website over HTTPS does not add the feature you've been crunching on for some weeks, it doesn't fix the weird layout glitch on that weird platform, it doesn't help with all the other tasks a developer is swamped with. (Okay, it can make the website faster because HTTP/2 only works through HTTPS IIRC but that's not relevant to the discussion.)
Rust, however, does even make the developer's life easier when completely excluding security because of great tooling and less crashes.
So while Let's Encrypt made it incredibly easy to roll-out HTTPS, security wasn't a byproduct. It was the main product, just easy to use.
Rust OTOH made (some benefits in) security a complete byproduct.
@Di4na Okay, the way you phrased it sounded like you were disagreeing with my understanding why Rust and LE worked, despite having agreed to the same understanding beforehand.
To your questions at hand and what's changing, I initially wrote:
> There are other spheres of security where we haven't yet achieved that. I'm mostly thinking about infrastructure security here: Most issues are about asset lists, keeping your systems up-to-date and knowing what you're running. Probably the solution will look like something that's using SBOMs, IaC and some automation waves frantically -- but it's not fully fleshed out yet.
This gives a glimpse onto what the security world is talking and changing: Automation around dependency issues, reproducibility in infrastructure, etc. But those are baby steps, there's no finished "product" like Rust or LE but mostly just techniques that some tools already employ but aren't yet user friendly in the wide world. Think Ada SPARK instead of Rust.
I'm currently doing a lot of infrastructure work, so forgive me if I'm a bit out-of-the-loop when it comes to appsec (despite actually that being my passion). That being said, there's some work for better sandboxing mechanisms and compiler tooling.
@Di4na A lot of those improvements are more incremental though than Rust, and also they ideally don't even affect the developer. If I can "just" sandbox/jail an application, I've won a lot w/o the dev needing to put in work. So what I'm seeing here are things like hardened and stricter memory protection through compilers and kernels, separate call stacks, etc. No big product like Rust, but as I said: Incremental steps and I think the "Next Big Thing" will be in infra, not appsec.
Now, where is the money? Well, big security corps don't have much of an interest in this, right? They don't profit from Rust, they didn't profit from LE. Those things weren't developed by the security world, while still being shaped by the security world and the insights we've gathered over the last decades.
The offensive security world is mostly focused on ... well, offensive/destructive security. The incident response security world is mostly already pre-occupied with putting the fires out. And the defensive security product companies don't have an interest :-p
So that's what I see as the next step as well. Offensive security researches new attack vectors, IR teams and defensive research enumerates them and someone:tm: in the OSS scene will probably build a tool that actually ties things neatly together.
@Di4na Also note that building those solutions requires dev knowledge. We're not devs. We don't build good tools, frankly, they're all quite shitty.
We can provide good insight, but please for the love of God, don't let us security folx develop the solution or wait for us to do it. It'd be bad, even if we tried lol.
@ljrk right so what you are telling me is that this discussion is not happening, that Rust being successfully brought to exist was indeed a stroke of luck and that we will probably wait another 3 decades throwing money by the windows before any progress. Fair.
@Di4na Imo, Rust made working in a memory-unsafe manner non-default, and in fact quite onerous. The compiler itself, not developer convention, is enforcing the memory safety in a way that leaves little room for error.
i am genuinely interested. It is a domain I keep being surprised not finding discussions about. And I feel like I must be missing. I am probably not looking in the right place.
So I am asking the internet to do its magic and point me to these places please :)
@Di4na I think the magic is in the adoption part. One can only hope the language gets the same presence as c/c++ and the programmers keep a low mileage on the unsafe-keyword. You can’t say the exponential CVE-number and various ransoms didn’t nudge some parties in a better direction.
@Di4na I wish I had a clue about that other than the time is finally right. I do think that there is more awareness at leadership level as breaches cost money. Business case to support language that ‘solves’ the issue is easier to produce.
@darkcyberman But honestly, that is my pov. It may not be the story, or maybe just a part of it. My question is more. If you do not have a clue, why are you not faced with a deep introspection and wanting to find out?
Because I mean. They did what this field failed, coming from left field. Maybe there is something to learn? So I would recommend to not take my answer as the truth. But to sit down and spend time researching it for yourself.
@darkcyberman Also note. It is not the business side that made Rust work. It is the devs. They force sneaked it into everything until the business had no other choice but to accept that yeah, they were wrong.
@darkcyberman But here is a trail to follow. Check what the people that did the cheerleading and evangelism work for Rust actually used as argument to sell it. What new converts talked about. You may be surprised.
@Di4na Thank you for your line of thoughts. I wish I had your optimism one the global dev adoption of rust. I hope you’re right and the world is going to be a safer place due to the wider use of rust. I don’t think infosec has had the postion of forcing technology. Best one can do is support efforts on safer tech like rust.
@darkcyberman My question is not how to force tech. That is the point. Rust was not forced to anyone. It got adopted.
So maybe ask yourself what Rust did that infosec did not. You know. Do what I asked. Introspect and learn, so that tomorrow you can get secure stuff adopted.
@Di4na@darkcyberman it’s also an indictment of functional programming, for which many trees and pixels were sacrificed and yet produced little security, efficiency or concurrency
@darkcyberman@Di4na perhaps the forcing function for picking a new language is moore’s law. By eliminating race conditions on multicore cpus, Rust is both more secure and more efficient
@wwarner@darkcyberman I am sure this is the reason that devs put it as the most loved language 8 year in a row in the SO survey, before anyone in the business side got in the hype train. Definitely. Oooooooor maybe you should go ask the question yourself and think about it? :D
@Di4na I am programming in C++. Over the past decades, C++ evolved at such a pace that approximately every solution proposal and every textbook has been rendered completely invalid. So the engineering part that you requested in your article has taken place regularly, since 2011 in a 3-year cadence and it has brought us memory safety on an unprecedented level. I do not need another PL to be memory-safe. I just use the **latest version **of C++.
@markuswerle I am not sure I understand? Are you telling me that the, well documented, failure of even the latest C++ version, to incorporate stuff like actionable error messages, text formatting and escape, nice and efficient build system that are humane to use, and all that stuff...
@Di4na Yes, you are missing a lot IMHO. Nearly the complete list you mention has been addressed in the past years and the tooling has massively improved. Let's take the tour.
Have you ever compared C++ compiler error messages from 10 years ago with what you get today? Huge academic effort went into clang and forced gcc developers to catch up.
If you have trouble with template error messages, then that is why I write "nearly".
@Di4na Nice and efficient build system that are humane to use:
Well, this is the topic that most work went into. Look at what happened to #CMake within the past ten years. This is a completely different system now.
@markuswerle i did. I think these changes are far from impactful. The fact we think they are is exactly the kind of things i call out as us missing the reality out there
@markuswerle i do not disagree it is huge. But the "outside the C++ bubble" is the point. Things getting better is good. But the fact it still does not cross the bar after so much effort should be a good call to reconsider the direction.
Add comment