Update on our advocacy for memory-safety
To lift the veil a bit: the upcoming milestone in this effort is a joint statement about memory safety for security by design, from various European stakeholders. This statement calls for decisive action from European decision makers and industry leaders to prioritize memory safety as part of a comprehensive "secure-by-design" approach.
How it started
For us, our current non-profit efforts are a natural progression of the longstanding convictions that underlie everything we do, including our commercial work. And these convictions aren’t just ours - others are making waves with the same or similar principles.
Software must become safer
We’ve been saying that ‘software must become safer’ for years. It’s not just another marketing slogan; rather it's a deep conviction that was formed over several years of being confronted with buggy, unsafe and unsecure software. And seeing these vulnerabilities make headlines. And actually getting tired of it.
For example, as we’re writing this, the Dutch Public Prosecution Service has fallen victim to a hack due to a memory safety vulnerability in Citrix. This illustrates the kind of real-life consequences that we think are no longer acceptable.
As figure 1 below shows, the vast majority (roughly 70%) of vulnerabilities stem from memory unsafety, meaning they would be eliminated entirely if we use memory-safe technology. In fact, modern memory-safe tech (which is already available to us!) is one of the most impactful decisions a manufacturer of digital products can make to improve cybersecurity.
Frankly, we also have a long-term business interest in people being aware of these numbers and being more open to using memory-safe technology, Rust in particular. As a consequence, becoming more vocal about this topic has evolved naturally.
Figure 1: This figure, published by Microsoft 6 years ago, is central to the advocacy around memory safety, showing that the percentage of memory safety related vulnerabilities is around 70% (on average, in large memory-unsafe code bases). This number has been confirmed in several studies after (e.g. 1, 2). Although it’s easy to treat this as “just another statistic”, try to let the implication sink in: Using memory safe tech actually prevents 70% of vulnerabilities you would otherwise create! This is a massive safety, security and economic gain for both software producers as well as consumers. This is one of the most impactful decisions a manufacturer digital products can make to improve cybersecurity.
Memory safety in the US
We started working on one of our first “C to Rust” projects for the Internet Security Research Group (ISRG)’s Prossimo project in 2022. The Prossimo project’s mission is to create a ‘future for the Web that is more memory safe and more secure - and that benefits everyone using it’.
In November of 2023, we sponsored and attended Prossimo’s first memory safety event called Tectonics, in San Francisco. Tectonics was all about how to get to a more memory-safe future, faster, bringing together (mostly) US industry and government stakeholders.
Not coincidentally, the event was held shortly after CISA, the US’s Cybersecurity and Infrastructure Security Agency, had launched their Secure by Design campaign (in April 2023). This campaign would continue to raise awareness for the topic over various publications in the years to come, up to the point of calling buffer overflows in your code an “unforgivable defect".
In the US, the stage was set.
The European Cyber Resilience Act
In Europe, the most recent relevant development is the CRA, or Cyber Resilience Act, which entered into force in November 2024, and will be fully in effect in December 2027. It affects all parties that produce products with digital elements that they want to sell on the European market; It “aims to safeguard consumers and businesses buying software or hardware products with a digital component” by “requiring manufacturers and retailers to ensure cybersecurity throughout the lifecycle of their products”.
Although the standards for the CRA are still being developed, the CRA demands, amongst other things, the application of secure by design principles to software development, and taking a risk-based approach, reducing the attack surface as much as possible.
For a more detailed insight into the process and timeline of CRA standardization, and some advice on how to deal with the ambiguity of the period between Nov 2024 and Dec 2027, we suggest you read this excellent article by Sarah Fluchs.
We’ve had a look into an early draft of the base ‘Type A’ standard of the CRA and are convinced that using memory-safe technology will help companies immensely to comply with the CRA. Conversely, the CRA coming into effect can be a significant positive stimulus on the adoption of memory-safe tech.
Because of this, we feel that the stage is being set in the EU at this very moment - an excellent reason for you to get into this topic now; and to boost awareness in the EU, much like has previously been done in the US by CISA, the Whitehouse, and others.
Current status
So, what have we been doing lately? For one, we’ve been posting frequently on LinkedIn about memory safety and the CRA (1, 2, 3, 4, 5, 6 to name just a few). This is to keep everyone in our network on their toes.
We’ve also submitted comments about memory safety to the draft standard mentioned above that’s currently being developed. The first public commenting round is expected to open at the end of August 2025.
Then in September, my colleague Marc Schoolderman and I will give a talk about memory safety at OneConference in The Hague, The Netherlands called ‘You’re not Secure by Design, if You’re Not Memory-Safe’.
Towards a European Statement
Most notably, we’re in the process of publishing a statement about the importance of memory safety - similar to the publications in CISA’s Secure by Design campaign. This is a joint effort with Sovereign Tech Agency, and several other European stakeholders from both government and industry.
This initiative was kicked off at RustWeek in May of this year, the 2025 edition of the yearly Dutch Rust conference that we co-organize. There, we held the first Memory Safety in the EU meeting, to discuss the joint draft statement we’d started preparing in April.
Expected publication is in September or October of this year.
Once it’s out, we will use it to inform key industry decision makers and EU and national policy makers, striving for the use of memory-safe tech to become a no-brainer, and eventually a proven best practice, at least for developing new software.
What can you do?
If you, like us, believe that the adoption of memory-safe tech, be it Rust or another memory-safe language, is crucial for developing systems that are truly secure by design, here’s what you can do now:
First, if you’re a policy maker, get informed about the significant positive (both economic and cybersecurity) impact of large-scale adoption of memory-safe tech. If you have a bit of a technical background, this is an excellent article for diving in deeper. If you’re planning to attend OneConference, attend our talk!
Second, if you’re with an organization that might be willing to support the statement, check it out on GitHub, and send me an email if you wish to stay informed.
Last, if you’re in industry and you need to make choices about your future tech stack in light of the CRA: don’t discard the topic for later; don’t procrastinate; don’t wait until the first penalties have been issued. Instead, inform yourself now about the gains of adopting memory-safe tech and what investments you will need to make; you might even still benefit from some first-mover advantage!
Need more pointers on where to start? Feel free to reach out to me directly via email, LinkedIn or Bluesky.