Loading story…
Recent developments in compiler technology are enhancing both the safety and security of code used in critical and regulated environments. The Ferrocene Rust compiler toolchain has achieved IEC 61508 (SIL 2) certification for portions of its core library, enabling the use of memory-safe Rust code in devices that must meet stringent electronic system safety standards. This certification is expected to facilitate the adoption of Rust in industries where reliability and memory safety are paramount, potentially reducing memory-related vulnerabilities that are common in C and C++-based embedded systems.
Separately, Trail of Bits has introduced constant-time coding support for LLVM, which will provide compiler-level guarantees to prevent timing side-channel vulnerabilities in cryptographic code. This enhancement, slated for inclusion in LLVM 22, introduces new intrinsics and infrastructure to ensure that compiler optimizations do not inadvertently introduce data-dependent branches that could leak sensitive information. Together, these advancements represent significant progress in making both safety- and security-critical software more robust against common classes of vulnerabilities, particularly in environments where failure or compromise can have severe consequences.
See the reporting duties and controls this puts on the clock.
3 events from the most recent confirmed update back to the earliest known activity.
Trail of Bits published details of its LLVM/Clang constant-time coding support, explaining how the new intrinsics prevent compiler optimizations from reintroducing timing side channels into cryptographic code.
By December 2025, Trail of Bits' implementation adding __builtin_ct_select and llvm.ct.select.* intrinsics, with architecture-specific lowerings for x86-64 and AArch64, was under review for inclusion in LLVM 22.
In August 2025, Trail of Bits posted an RFC on LLVM Discourse proposing compiler-level constant-time support to preserve cryptographic constant-time semantics through optimization.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See what this changes for your reporting obligations and which controls it puts on the clock.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Google has reported a significant reduction in memory safety vulnerabilities in Android, attributing this improvement to the adoption of the Rust programming language. According to Google, the proportion of memory safety bugs in Android has dropped below 20% for the first time, with Rust code demonstrating a 1000x reduction in vulnerability density compared to C and C++. The transition to Rust has also led to operational benefits, such as a lower rollback rate and faster code review cycles, and Google plans to expand Rust's use to additional components of the Android ecosystem, including the kernel, firmware, and key applications. Security experts emphasize that secure coding should focus on principles like secure by default and secure by design, rather than simply identifying vulnerabilities. The integration of Rust into Android's codebase exemplifies how adopting memory-safe languages can serve as a practical application of these secure coding principles, reducing the burden on developers and improving overall software security. Google's experience also highlights the importance of a defense-in-depth approach, as even memory-safe languages like Rust can have vulnerabilities if unsafe code is used, as demonstrated by the discovery and patching of a buffer overflow in the CrabbyAVIF parser before public release.
Jun 29, 2026
Microsoft has announced a strategic initiative to eliminate all C and C++ code from its software portfolio by 2030, aiming to rewrite its codebase in the memory-safe language Rust. The company is leveraging a combination of AI and advanced algorithms to automate the translation of legacy code, with the goal of enabling a single engineer to convert up to one million lines of code in a month. This effort is supported by the development of new internal tools and the recruitment of specialized engineers to drive the transition, as detailed by Microsoft distinguished engineer Galen Hunt. The move to Rust is motivated by the language's inherent memory safety features, which help prevent vulnerabilities such as out-of-bounds reads, writes, and use-after-free errors—common attack vectors in C and C++ applications. Microsoft’s leadership has publicly advocated for the adoption of memory-safe languages to reduce technical debt and improve software security, aligning with broader industry and governmental calls for safer software development practices.
Jun 29, 2026
A FOSDEM talk by **René Meusel** (maintainer of the *Botan* cryptography library) warned that modern compiler optimizations—particularly in **GCC**—can inadvertently undermine security properties that cryptographic developers intentionally implement. The core issue is that compilers may remove or transform code patterns used to enforce *constant-time* behavior, potentially reintroducing **timing side channels** that leak sensitive information (e.g., how many characters of a password guess are correct based on response-time differences). This can occur when the compiler “simplifies” Boolean logic or other masking techniques that were meant to prevent observable timing variance. Mitigations discussed include using more defensive coding patterns to prevent “helpful” optimization (e.g., carefully chosen bitwise operations, `inline` assembly, and other obfuscation-like techniques), but these approaches increase complexity and the chance of developer error. Meusel also emphasized the importance of understanding compiler behavior and validating implementations with analysis tooling (e.g., *Valgrind*), and advised against rolling bespoke cryptography in favor of contributing to established libraries where these pitfalls are more likely to be identified and addressed.
Jun 29, 2026