jeffvanderstoep on Nostr: I joined npub12ps2k…z9csg and npub1kk092…vvn9f on the Security Cryptography ...
I joined npub12ps2kznrptk0dunqew9az9sugtuwevzlj45mnk2h7u96y4zcu8pqjz9csg (npub12ps…9csg) and npub1kk092v80l00axsvyem8tufu20uxmhvdtx6alrhungcytyumunsaqcvvn9f (npub1kk0…vn9f) on the Security Cryptography Whatever podcast to talk about our latest blogpost:
https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
Something that Thomas said in the podcast really stood out to me. He said “the blog post undersells it. …. This is a lot more interesting than it looks like on the tin.”
I agree with this. It feels like we discovered a game-changer not just in memory safety, but in security more generally - that doing something very practical results in major security improvements for non-obvious reasons. Focusing on new code is disproportionately effective, exponentially.
Thomas also said “And that observation about the half life of vulnerabilities, if that’s true, says something pretty profound about what the work looks like to shift to a memory safe future.”
Or as Deidre said: “You can get really big bang for your buck, which is if you have something new, just write it in the Rust or another memory safe language and make it interop with the rest of your project and you will in fact, get really good returns on mitigating your memory safe vulnerabilities, which is the majority of your vulnerabilities, period.”
Agreed. We’re already prioritizing differently based on this data. It was a fun conversation, and we believe that it applies to a lot more than just memory safety.
https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
Something that Thomas said in the podcast really stood out to me. He said “the blog post undersells it. …. This is a lot more interesting than it looks like on the tin.”
I agree with this. It feels like we discovered a game-changer not just in memory safety, but in security more generally - that doing something very practical results in major security improvements for non-obvious reasons. Focusing on new code is disproportionately effective, exponentially.
Thomas also said “And that observation about the half life of vulnerabilities, if that’s true, says something pretty profound about what the work looks like to shift to a memory safe future.”
Or as Deidre said: “You can get really big bang for your buck, which is if you have something new, just write it in the Rust or another memory safe language and make it interop with the rest of your project and you will in fact, get really good returns on mitigating your memory safe vulnerabilities, which is the majority of your vulnerabilities, period.”
Agreed. We’re already prioritizing differently based on this data. It was a fun conversation, and we believe that it applies to a lot more than just memory safety.