Disclaimer: This post is a research trend overview for informational purposes. Specific findings, statistics, and claims should be verified against the original papers before citation in academic work.

Memory Safety at the Tipping Point: How Rust Drove Android Vulnerabilities Below 20%

For decades, memory safety vulnerabilities—buffer overflows, use-after-free errors, null pointer dereferences—have constituted the majority of severe security bugs in systems software. Microsoft reported in 2019 that roughly 70% of its CVEs over the previous decade stemmed from memory safety issues. Google's Project Zero found similar proportions across major software projects. The pattern was so consistent that it began to feel like a law of nature: write systems code in C or C++, and roughly two-thirds of your critical vulnerabilities will be memory bugs.

That ratio is now changing. Google's Android team reports that memory safety vulnerabilities have dropped below 20% of total vulnerabilities for the first time. The mechanism is not better C++ practices, not more sophisticated static analysis, and not more thorough code review—though all of those help at the margins. The primary driver is writing new code in Rust, a language that enforces memory safety at compile time through its ownership and borrowing system.

The Android Evidence

Android is a compelling case study because of its scale and heterogeneity. The Android Open Source Project comprises millions of lines of code spanning kernel drivers, system services, media codecs, networking stacks, and hardware abstraction layers—exactly the kind of performance-critical, hardware-adjacent code that has historically been written in C and C++ because "you need the control."

Google's approach was not to rewrite existing C/C++ code in Rust—a strategy that would be prohibitively expensive and would introduce its own bugs during translation. Instead, they adopted a policy of writing new code in Rust while allowing existing C/C++ code to age in place. The rationale is that most vulnerabilities cluster in recently modified code: the older a piece of code is, the more it has been tested by real-world usage, and the fewer bugs remain. New code, by contrast, is where fresh memory safety bugs are introduced.

This "Safe Coding" strategy produces a counterintuitive result: even though the total amount of C/C++ code still vastly exceeds Rust code in Android, the share of memory safety vulnerabilities declines steadily because the new vulnerability introduction rate drops to near zero in Rust modules.

The Institutional Cascade

What distinguishes the current moment from earlier advocacy for memory-safe languages is the institutional weight behind the shift. This is no longer a debate among programming language enthusiasts on forums; it is a matter of national security policy.

The NSA published guidance in November 2022 recommending that organizations transition to memory-safe languages, specifically naming Rust, Go, C#, Java, Swift, and Python. CISA followed with its own guidance emphasizing memory safety as a key component of secure-by-design software development. The White House ONCD issued a technical report in February 2024 calling on the technology ecosystem to adopt memory-safe languages and formally treat memory unsafety as a class of defect to be eliminated rather than managed.

Most concretely, DARPA's TRACTOR program (Translating All C to Rust) funds research into automated translation of existing C codebases to Rust. The program name is both literal and aspirational: the goal is not merely to demonstrate that translation is possible for small programs, but to build tools capable of handling the millions of lines of C that underpin operating systems, embedded systems, and critical infrastructure.

MIT's declaration that memory safety has reached a "tipping point" reflects this convergence of technical evidence (Android's numbers), institutional policy (NSA/CISA/ONCD), and active investment (DARPA TRACTOR).

The Criticism Worth Taking Seriously

The case for memory-safe languages is strong, but several counterarguments deserve honest engagement rather than dismissal.

Performance overhead: Rust's borrow checker enforces safety at compile time with zero runtime cost, but the language's safety guarantees can force programmers into patterns that are less cache-friendly or require more allocations than equivalent unsafe C. In latency-critical systems—real-time audio processing, certain kernel paths, high-frequency trading—these differences can matter. The response that "Rust is zero-cost" is technically correct about the borrow checker but misleading about the broader programming patterns the language encourages.

Unsafe blocks: Rust allows unsafe blocks that bypass the borrow checker, and these are necessary for low-level systems programming—interfacing with hardware, implementing data structures that require pointer arithmetic, calling foreign functions. The proportion of unsafe code in real Rust projects varies widely. If critical vulnerabilities cluster in unsafe blocks, the effective safety improvement is smaller than the language-level guarantee suggests.

Translation fidelity: DARPA TRACTOR's ambition to translate C to Rust at scale faces the fundamental challenge that C and Rust have different memory models. A faithful translation preserves the original program's semantics, but those semantics may include the very undefined behaviors that Rust is designed to prevent. An idiomatic translation that restructures code to use Rust's ownership model may change program behavior in subtle ways.

Ecosystem maturity: The C and C++ ecosystems have decades of tooling, libraries, and developer expertise. Rust's ecosystem is growing rapidly but remains thinner in domains like embedded systems, legacy kernel modules, and certain scientific computing niches.

Open Questions

The decline of memory safety vulnerabilities below 20% in Android is not the end of a story but the validation of a hypothesis: that a class of vulnerability responsible for the majority of severe security bugs can be systematically eliminated through language choice rather than developer discipline. Whether this success generalizes to less well-resourced organizations and less modern codebases remains the central question.

면책 조항: 이 게시물은 정보 제공 목적의 연구 동향 개요이다. 학술 연구에서 인용하기 전에 특정 연구 결과, 통계 및 주장을 원본 논문과 대조하여 검증해야 한다.

전환점에 선 메모리 안전성: Rust가 어떻게 Android 취약점을 20% 미만으로 낮췄는가

수십 년 동안 메모리 안전성 취약점—버퍼 오버플로우, use-after-free 오류, null 포인터 역참조—은 시스템 소프트웨어에서 발생하는 심각한 보안 버그의 대다수를 차지해 왔다. Microsoft는 2019년 지난 10년간 자사 CVE의 약 70%가 메모리 안전성 문제에서 비롯되었다고 보고했다. Google의 Project Zero도 주요 소프트웨어 프로젝트 전반에 걸쳐 유사한 비율을 발견했다. 이 패턴은 너무나 일관적이어서 마치 자연 법칙처럼 느껴지기 시작했다. C 또는 C++로 시스템 코드를 작성하면 치명적 취약점의 약 3분의 2가 메모리 버그가 될 것이라는 법칙 말이다.

이제 그 비율이 변화하고 있다. Google의 Android 팀은 메모리 안전성 취약점이 처음으로 전체 취약점의 20% 미만으로 감소했다고 보고한다. 그 원동력은 더 나은 C++ 관행도, 더 정교한 정적 분석도, 더 철저한 코드 리뷰도 아니다—물론 이 모두가 주변적으로는 도움이 되지만. 핵심 동인은 소유권 및 차용 시스템을 통해 컴파일 타임에 메모리 안전성을 강제하는 언어인 Rust로 새로운 코드를 작성하는 것이다.

Android의 사례

Android는 그 규모와 이질성 때문에 설득력 있는 사례 연구 대상이다. Android Open Source Project는 커널 드라이버, 시스템 서비스, 미디어 코덱, 네트워킹 스택, 하드웨어 추상화 계층에 걸쳐 수백만 줄의 코드로 구성되어 있다. 이는 "제어가 필요하다"는 이유로 역사적으로 C와 C++로 작성되어 온 성능 중심적이고 하드웨어에 근접한 코드의 전형이다.

Google의 접근 방식은 기존 C/C++ 코드를 Rust로 재작성하는 것이 아니었다. 그 전략은 엄청난 비용이 들고 변환 과정에서 새로운 버그를 도입할 수 있다. 대신 그들은 기존 C/C++ 코드는 그대로 유지하면서 새로운 코드를 Rust로 작성하는 정책을 채택했다. 그 근거는 대부분의 취약점이 최근 수정된 코드에 집중된다는 것이다. 코드가 오래될수록 실제 사용 환경에서 더 많이 테스트되어 남아있는 버그가 줄어든다. 반대로 새로운 코드는 새로운 메모리 안전성 버그가 도입되는 곳이다.

이 "안전한 코딩(Safe Coding)" 전략은 직관에 반하는 결과를 낳는다. Android에서 C/C++ 코드의 총량이 여전히 Rust 코드를 압도적으로 넘어서지만, Rust 모듈에서 새로운 취약점 도입률이 거의 0에 가깝게 떨어지기 때문에 메모리 안전성 취약점의 비율은 꾸준히 감소한다.

기관의 연쇄적 호응

현재 시점을 메모리 안전 언어에 대한 이전의 지지 움직임과 구별 짓는 것은 이 전환 뒤에 있는 기관의 무게감이다. 이것은 더 이상 포럼에서 프로그래밍 언어 애호가들 사이의 논쟁이 아니다. 이제 이것은 국가 안보 정책의 문제이다. NSA는 2022년 11월 조직들이 메모리 안전 언어로 전환할 것을 권고하는 지침을 발표하면서, 구체적으로 Rust, Go, C#, Java, Swift, Python을 명시하였다. CISA는 메모리 안전성을 보안 설계(secure-by-design) 소프트웨어 개발의 핵심 요소로 강조하는 자체 지침을 뒤이어 발표하였다. 백악관 ONCD는 2024년 2월 기술 보고서를 발간하여 기술 생태계가 메모리 안전 언어를 채택하고, 메모리 비안전성을 관리 대상이 아닌 제거해야 할 결함의 한 범주로 공식적으로 다룰 것을 촉구하였다.

가장 구체적인 사례로, DARPA의 TRACTOR 프로그램(Translating All C to Rust)은 기존 C 코드베이스를 Rust로 자동 변환하는 연구에 자금을 지원한다. 이 프로그램의 명칭은 문자 그대로이자 열망적 의미를 동시에 담고 있다. 즉, 목표는 소규모 프로그램에 대해 변환이 가능함을 단순히 입증하는 것이 아니라, 운영체제, 임베디드 시스템, 핵심 인프라를 뒷받침하는 수백만 줄의 C 코드를 처리할 수 있는 도구를 구축하는 것이다.

MIT가 메모리 안전성이 "전환점(tipping point)"에 도달했다고 선언한 것은 기술적 증거(Android의 수치), 기관 정책(NSA/CISA/ONCD), 그리고 적극적 투자(DARPA TRACTOR)라는 흐름의 수렴을 반영한다.

진지하게 받아들일 만한 비판

메모리 안전 언어를 지지하는 논거는 강력하지만, 몇 가지 반론은 일축하기보다 솔직하게 검토할 필요가 있다.

성능 오버헤드: Rust의 빌림 검사기(borrow checker)는 런타임 비용 없이 컴파일 타임에 안전성을 강제하지만, 언어의 안전성 보장은 프로그래머로 하여금 동등한 unsafe C보다 캐시 친화성이 낮거나 더 많은 할당을 필요로 하는 패턴을 사용하도록 강제할 수 있다. 실시간 오디오 처리, 일부 커널 경로, 고빈도 거래 등 지연 시간이 중요한 시스템에서는 이러한 차이가 문제가 될 수 있다. "Rust는 비용이 없다(zero-cost)"는 반응은 빌림 검사기에 관해서는 기술적으로 정확하지만, 언어가 권장하는 더 넓은 프로그래밍 패턴에 대해서는 오해를 불러일으킬 수 있다.

Unsafe 블록: Rust는 빌림 검사기를 우회하는 unsafe 블록을 허용하며, 이는 저수준 시스템 프로그래밍—하드웨어 인터페이스, 포인터 산술이 필요한 자료구조 구현, 외부 함수 호출—에 필수적이다. 실제 Rust 프로젝트에서 unsafe 코드의 비율은 매우 다양하다. 만약 치명적 취약점이 unsafe 블록에 집중된다면, 실질적인 안전성 개선은 언어 수준의 보장이 시사하는 것보다 작아진다.

변환 충실도: C를 대규모로 Rust로 변환하려는 DARPA TRACTOR의 야망은, C와 Rust의 메모리 모델이 다르다는 근본적인 문제에 직면한다. 충실한 변환은 원래 프로그램의 의미론을 보존하지만, 그 의미론에는 Rust가 방지하도록 설계된 바로 그 미정의 동작(undefined behavior)이 포함될 수 있다. Rust의 소유권 모델을 활용하도록 코드를 재구성하는 관용적(idiomatic) 변환은 프로그램 동작을 미묘한 방식으로 바꿀 수 있다.

생태계 성숙도: C와 C++ 생태계는 수십 년에 걸친 툴링, 라이브러리, 개발자 전문성을 보유하고 있다. Rust의 생태계는 빠르게 성장하고 있지만, 임베디드 시스템, 레거시 커널 모듈, 일부 과학 컴퓨팅 틈새 분야에서는 여전히 얇은 편이다.

미해결 과제

Android에서 메모리 안전성 취약점이 20% 이하로 감소한 것은 하나의 이야기의 끝이 아니라 하나의 가설에 대한 검증이다. 즉, 심각한 보안 버그의 대다수를 차지하는 취약점 분류가 개발자의 규율이 아닌 언어 선택을 통해 체계적으로 제거될 수 있다는 가설이다. 이러한 성공이 자원이 부족한 조직과 덜 현대적인 코드베이스에도 일반화될 수 있는지의 여부는 여전히 핵심적인 질문으로 남아 있다.