It’s Not As Simple As “Use A Memory Safe Language @S4Events
It’s Not As Simple As “Use A Memory Safe Language  @S4Events
Uploaded March 2025 | Updated September 2026, 1 week ago
The US and other governments, OWASP, and almost every authoritative source prioritizes using memory-safe programming languages, discouraging the use of C and C++ and proactively recommending Rust. This is great if you are starting over or can rewrite your codebase.

This session focuses on what is also needed, guidance on how to incrementally move C and C++ forward. The ease of writing memory-safe C++ is getting closer to Rust, WebAssembly can further sandbox code without sacrificing performance, and for projects using languages that are not memory safe, they should publish their security programs and demonstrate their comprehensiveness if they are to be considered for critical infrastructure.

Colin offers a practitioner's perspective on memory-safe languages, formal verification, making quality visible, sandboxing with WebAssembly, and embeddeding open-source code written in memory-unsafe languages.

Future software should be memory safe, but secure code is about a lot more than memory safety.
It’s Not As Simple As “Use A Memory Safe LanguageIs Rust Really Safe? #shortsS4 Great Debate: Cyber Resilience Act ImpactOT Environments Are Unique (Not) #shortsCloud As A Governance PlaneClarotys Session In The S4x26 POC PavilionCyber Detection Initiated Safety And ProtectionIt’s Not About Consequences. It’s About Connection.How Complete Is Your Asset Visibility? A Metrics AnswerWater: The (Potentially) Most Cyber-Resilient CI SectorOperating With Adversary Supplied ComponentsConverting A C++ Codebase To Rust
S4 Events |

It’s Not As Simple As “Use A Memory Safe Language"

SHARE TO X SHARE TO REDDIT SHARE TO FACEBOOK WALLPAPER