Rust has been the most loved programming language on Stack Overflow developer survey for seven consecutive years. But developer affection does not automatically translate into production adoption in security-critical systems. The real question is whether Rust is actually displacing C and C++ in the places where memory safety matters most.
The answer is complicated. And it matters deeply for anyone concerned about software supply chain security.
Where Rust Is Actually Being Adopted
The Linux kernel accepted its first Rust code in version 6.1, released in December 2022. This is a landmark moment. The kernel is arguably the most security-critical piece of software on the planet, and the decision to allow Rust alongside C signals a genuine shift in how the systems programming community thinks about memory safety.
Google has been aggressive about Rust adoption in Android. They reported that the percentage of memory safety vulnerabilities in Android dropped from 76% in 2019 to 35% in 2022, correlating directly with the shift toward writing new code in Rust and Kotlin. They did not rewrite existing C code -- they simply ensured that new code was written in memory-safe languages.
Microsoft has invested heavily in Rust for Windows components. Their security team has repeatedly published data showing that approximately 70% of CVEs they address are memory safety issues. The economic case for Rust in new Microsoft code is straightforward: fewer CVEs means less incident response, fewer patches, and less customer disruption.
Amazon Web Services uses Rust for performance-sensitive infrastructure like Firecracker (the microVM technology behind Lambda and Fargate) and Bottlerocket (a container-optimized Linux distribution). Cloudflare has rewritten significant portions of their edge infrastructure in Rust.
Where Rust Is Not Being Adopted
Despite these high-profile examples, vast swaths of security-critical infrastructure remain firmly in C territory. OpenSSL, the most widely deployed TLS library, is written in C. While alternatives like rustls exist, OpenSSL installed base is enormous and migration is slow.
Most embedded systems continue to use C. The toolchain support, hardware vendor SDKs, and existing codebases all favor C. Rust embedded ecosystem is maturing but remains less complete than what C offers.
The networking stack in most operating systems is C. Filesystems are C. Device drivers are overwhelmingly C. Database engines like SQLite, PostgreSQL, and MySQL are all C. These are not going to be rewritten anytime soon.
Legacy cryptographic libraries, compression utilities, and parsing libraries that form the backbone of the software supply chain are C. They have decades of optimization, testing, and real-world hardening. Rewriting them introduces the risk of new bugs -- potentially including new security vulnerabilities -- even if the new code is memory-safe.
The Supply Chain Implications
For supply chain security, the relevant question is not whether Rust is theoretically superior to C for memory safety. It obviously is. The question is what happens during the transition period, which will last at least a decade and probably longer.
Mixed codebases create new risks. When Rust code calls C code through FFI (Foreign Function Interface), the safety guarantees of Rust do not extend across the boundary. A Rust application that shells out to a C library for XML parsing is still vulnerable to memory corruption in the C code. The unsafe keyword in Rust exists precisely because sometimes you need to bypass the safety system, and unsafe blocks are common at FFI boundaries.
Dependency confusion expands. As libraries are rewritten in Rust, there will be a period where both the original C version and the new Rust version coexist. Developers must carefully choose which to depend on, and the Rust version may not have the same level of real-world testing as the battle-hardened C original.
New vulnerability classes emerge. Rust prevents memory safety bugs, but it does not prevent logic bugs, authentication bypasses, SQL injection, or supply chain attacks at the package level. The crates.io ecosystem is still relatively young compared to npm or PyPI, but it has already seen instances of typosquatting and malicious packages.
What Rust Does and Does Not Solve
Rust eliminates buffer overflows, use-after-free, double-free, and data races in safe code. These account for a significant percentage of the most severe vulnerabilities in C and C++ code. That alone justifies adoption.
Rust does not eliminate:
- Logic vulnerabilities. An authentication bypass is a logic error, and Rust type system cannot prevent all logic errors.
- Cryptographic misuse. Using AES-ECB mode instead of AES-GCM is a design flaw, not a memory safety issue.
- Supply chain attacks. A malicious crate on crates.io is just as dangerous as a malicious npm package.
- Denial of service. Algorithmic complexity attacks, resource exhaustion, and infinite loops are all possible in Rust.
- Unsafe code. Rust allows
unsafeblocks where the programmer takes responsibility for memory safety. Bugs inunsafecode can be just as severe as bugs in C.
Practical Recommendations
For new projects: If you are starting a new systems programming project and Rust is a viable option, use it. The memory safety guarantees are real and significant.
For existing C codebases: Do not attempt a wholesale rewrite. Instead, identify the most security-sensitive components -- parsers, network protocol handlers, cryptographic operations -- and consider rewriting those in Rust while maintaining C for the rest.
For dependency selection: When choosing between a mature C library and a newer Rust alternative, evaluate both carefully. A well-audited C library with years of fuzzing coverage may actually be safer than a young Rust library that has not been battle-tested.
For SCA and SBOM: Your tooling needs to handle mixed-language dependency trees. A Rust project that depends on C libraries through build.rs scripts or system library links needs those C dependencies tracked and monitored just like the Rust ones.
The Timeline
Rust adoption in security-critical software is real but measured in years and decades, not months. The transition will be gradual, uneven, and punctuated by setbacks. During this period, the software supply chain will include a complex mix of C, C++, Rust, and other languages, all interacting through FFI boundaries that require careful security attention.
The organizations that navigate this transition best will be those with clear visibility into their full dependency tree, regardless of language boundaries.
How Safeguard.sh Helps
Safeguard.sh supports multi-language dependency analysis across Rust, C, C++, and other ecosystems. Our SBOM generation captures dependencies across FFI boundaries, tracking both Rust crates and the native C libraries they link against. When vulnerabilities are discovered in either ecosystem, Safeguard.sh maps the impact to your specific applications and provides actionable remediation guidance, helping you manage the complexity of mixed-language supply chains.