Rust는 5회 연속 가장 사랑받는 프로그래밍 언어로 선정되었습니다. 과연 우리의 새로운 보안 구원자가 될 수 있을까요?

지난 몇 년간 전 세계 소프트웨어 엔지니어들은 Rust에 열광해 왔습니다. Mozilla가 개발한 이 비교적 새로운 시스템 프로그래밍 언어는 Stack Overflow 커뮤니티의 마음을 사로잡았습니다. 까다롭기로 유명한 개발자들이 5년 연속으로 이 언어를 "가장 사랑받는 프로그래밍 언어"로 선정했다는 점은 우리가 주목해야 할 중요한 신호입니다.

Rust 프로그래밍 언어는 기존 언어들의 기능적 요소를 통합하면서도 복잡성을 배제하고 성능과 안전성을 높이는 차별화된 철학을 따릅니다. 학습 곡선이 존재하고 아직 많은 개발자가 이를 충분히 활용할 기회를 얻지 못해 Stack Overflow 설문조사 응답자 중 5.1%만이 이 언어를 주로 사용하고 있습니다. 그럼에도 불구하고 Rust는 C나 C++ 같은 기존 언어보다 훨씬 강력한 보안 성능을 갖춘 흥미로운 언어임이 분명합니다. 대중적인 도입을 위해서는 행동 및 기술적 변화가 필요하겠지만, 현재 개발자들은 이론적인 측면에서 이 언어에 큰 관심을 보이고 있습니다.

하지만 한 가지 더 짚고 넘어가야 할 점이 있습니다. Rust는 메모리 안전성을 최우선으로 하며, 일반적인 메모리 관리 문제와 관련된 보안 취약점을 근본적으로 제거하는 언어라는 사실입니다. 이러한 문제들은 매우 중요하며(AppSec 팀의 골칫거리이기도 하죠), 하지만 우리가 직면한 보안 코딩 과제가 이것뿐만은 아닙니다.

Rust는 정확히 무엇을 방지할까요? 그리고 보안 환경에서 여전히 노출된 부분은 어디일까요? 최신 프로그래밍의 유니콘이라 불리는 Rust에 대해 자세히 알아보겠습니다.

현대적이고 메모리 안전한 시스템 프로그래밍의 새로운 지평

Mozilla의 연구 개발 팀은 놀라운 프로젝트들을 수행해 왔으며, 오픈 소스의 선구자로서 Rust 프로그래밍에 투자한 것 역시 예외는 아닙니다. 그들의 소개 영상은 그들의 철학을 잘 보여주며, 핵심 주제는 명확합니다. 현재의 소프트웨어 보안 접근 방식에는 결함이 있으며, Rust는 그 문제의 상당 부분을 해결하기 위해 설계되었다는 것입니다.

최근 EasyJet 사례와 같이 매일같이 엄청난 데이터 유출 사고가 발생하는 상황에서 이는 너무 단순한 해결책처럼 보일 수 있습니다. 수백만 건의 데이터 기록이 빈번하게 유출되는데, 이는 거의 항상 웹 애플리케이션 취약점, 보안 설정 오류, 또는 피싱 공격 때문입니다. C++와 같은 언어는 수십 년 동안 존재해 왔지만, 개발자들이 보안 코딩 모범 사례를 완벽히 구현할 만큼 숙달되기에는 충분한 시간이 아니었습니다. Rust라고 다를까요? 새로운 언어들은 이전에도 등장했지만, 공통적인 취약점을 근절하거나 컴파일된 코드가 마법처럼 완벽함을 보장하는 방법을 찾지는 못했습니다.

개념은 단순할지 몰라도, 때로는 단순한 해답이 복잡한 문제를 해결하기도 합니다. Rust는 말 그대로 메모리 안전 시스템 프로그래밍의 혁명이며 여러 면에서 그 약속을 지키고 있습니다. 또한, 감지되지 않으면 큰 문제를 일으킬 수 있는 오류를 범하기 쉬운 개발자들을 구원해 줍니다. Java, C, C++는 물론 Kotlin이나 Golang 같은 최신 언어들도 보안에 익숙하지 않은 개발자에게는 여전히 가혹합니다. 이러한 언어들에는 내장된 경고 기능이 없으며, 방금 컴파일한 훌륭한 기능 속에 보안 결함이 숨어 있는지 알려주는 특별한 신호도 없습니다.

그럼 더 자세히 파헤쳐 보겠습니다.

Rust가 그토록 안전한 이유는 무엇일까요?

일반적으로 개발자의 주된 목표는 기능을 구축하고, 그것이 잘 작동하며 사용자 친화적인지 확인하는 것입니다. 어쩌면 이력서에 자랑스럽게 내세울 수 있는 성과를 만드는 것이 목표일 수도 있습니다. 개발자가 훌륭한 소프트웨어를 만들고 배포한 뒤 다음 프로젝트로 넘어가는 것은 매우 자연스러운 일입니다. 이 시점에서 보안 팀이 취약점을 점검하고, 발견되면 "완성된" 애플리케이션은 수정 작업을 위해 다시 개발 팀으로 돌아갑니다. 문제는 간단할 수도 있지만, 개발자가 해결하기에는 범위를 완전히 벗어난 것일 수도 있습니다.

문제는 표면적으로는 보안 버그가 전혀 드러나지 않는다는 점입니다. 스캔, 테스트, 수동 코드 검토에서 이를 잡아내지 못하면 공격자는 그 작은 기회를 틈타 버그를 악용할 수 있습니다.

이제 Rust는 많은 취약점이 코드에 유입되는 것 자체를 막으려 합니다. 구문 오류나 SDLC 전반에 걸쳐 생산 문제를 일으키는 메모리 안전 버그가 있으면 아예 컴파일되지 않기 때문입니다. 이는 설계 단계부터 메모리 안전 프로그래밍을 지향하여, 소프트웨어가 어떻게 실행되든 유효하지 않은 메모리에 접근할 수 없도록 보장합니다. 전체 보안 버그의 70%가 메모리 관리 관련 문제라는 점을 고려하면, 이는 대단한 성과입니다.

Rust는 다음을 표시하고 방지합니다:

• 버퍼 오버플로우
• Use after free
• Double-free
• Null 포인터 역참조
• 초기화되지 않은 메모리 사용

Rust 코드 조각을 C++와 비교해 보면, Rust가 기본적으로 얼마나 안전한지 분명해집니다. 버퍼 오버플로우 버그의 다음 예시를 확인해 보세요:

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // b의 길이가 a보다 길어 버퍼 오버플로우 발생
std::cout << a << "; " << b << std::endl;
}

대

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust는 보안 경고를 발생시키며, 런타임에 copy_from_slice 함수에 도달하면 버퍼 오버플로우를 방지하기 위해 패닉을 일으킵니다. 다만 컴파일 타임에는 이를 감지하지 못합니다.

그런 의미에서 Rust는 "왼쪽부터 시작하는(start left)" 언어에 가깝습니다. 오류를 강조하고 개발자가 메모리 관련 보안 버그를 방지하는 올바른 코딩 방식을 강제로 익히게 하므로, 마감 기한을 맞추려면 개발자가 주의를 기울이고 문제를 수정하며 올바른 개발 경로를 유지해야 합니다.

이 언어의 접근 방식은 단순해 보이지만, 강력한 로직을 구현해 낸 것은 놀라운 성과이며 실제로 그 가치를 증명하고 있습니다. 보안 관점에서 Rust는 거대한 도약입니다. 더 많은 사람이 사용한다면 말이죠. Dropbox와 같은 기업들이 대규모 기업 환경에서 Rust 도입을 선도하고 있다는 점은 매우 고무적입니다. 하지만 단순히 도입 문제만이 더 안전한 미래를 가로막는 유일한 걸림돌이라고 결론짓기 전에 고려해야 할 사항들이 더 있습니다.

Rust의 심판.

몇 가지 작지만(사실은 큰) 문제가 있습니다. Rust로 프로그래밍할 때 생각보다 버그가 발생할 여지가 많다는 점입니다. Rust는 결코 보안 침해, 지연, 그리고 안전하지 않은 코딩 관행을 유발하는 OWASP Top 10 취약점을 모두 해결해주지 않습니다. 또한 천사와 악마의 역학 관계, 즉 더 잘 알려진 Safe Rust와 Unsafe Rust라는 개념이 존재합니다.
‍

As is explained in the official documentation, Safe Rust is the "true" form of Rust, and Unsafe Rust includes functions that are deemed "definitely not safe", although they are sometimes necessary - such as if integration with something in another language is required. However, even with Unsafe Rust, the list of additional functionalities is still limited. In Unsafe Rust, it is possible to do the following within unsafe blocks:

• 원시 포인터 역참조
• 안전하지 않은 함수 호출(C 함수, 컴파일러 내장 함수, 원시 할당자 포함)
• 안전하지 않은 트레이트 구현
• 정적 변수 변경
• 공용체 필드 접근.

소위 "안전하지 않은(unsafe)" 모드에서도 Rust 프로그래밍의 핵심 강점인 "소유권 검사기(borrow checker)"는 여전히 작동합니다. 이는 정적 코드 분석을 통해 메모리 문제, 병렬 계산 시 충돌 및 기타 여러 버그를 일반적으로 방지하며, unsafe 블록 내에서도 이러한 분석은 계속 수행됩니다. 단지 특정 상황에서 컴파일러의 안내 없이 안전하지 않은 구조를 작성하려면 훨씬 더 많은 노력이 필요할 뿐입니다.

대부분의 숙련된 개발자에게는 큰 문제가 아닐 수 있습니다. 우리는 애플리케이션의 성능을 극대화하고 더 멋진 기능을 구현하기 위해 항상 고민하니까요. 하지만 이는 심각한 설정 오류와 보안 취약점으로 이어질 수 있는 블랙홀, 즉 정의되지 않은 동작(undefined behavior)을 초래할 위험이 있습니다. Rust로 프로그래밍하면(안전하지 않은 방식으로 사용하더라도) C나 C++에 비해 취약점 발생 가능성을 상당히 잘 차단하지만, 정의되지 않은 동작을 호출하는 것은 여전히 위험 요소입니다.

개발자 주도의 보안 코딩에 대한 의존은 이제 끝난 것일까요?

앞서 Rust가 잘 알려진 언어들의 구성 요소를 가지고 있다고 했던 것을 기억하시나요? Rust의 주요 보안 취약점 중 하나는 바로 잘 알려진 언어, 즉 C의 구성 요소를 포함하고 있다는 점입니다.

Rust는 여전히 "안전한 프로그래밍 언어"이지만, 사용자가 개입하는 순간 문제가 발생할 수 있습니다. 개발자는 오류를 표시하지 않도록 코드를 수정할 수 있으며(더 많은 기능을 사용할 수 있다는 점에서 매력적인 제안입니다), 본질적으로 안전한 상태에서도 개발자는 원하는 만큼 "안전하지 않게" 코딩할 수 있습니다. 상황이 완전히 잘못되기 전에 안내와 보호 계층이 존재할 뿐입니다.

위의 두 시나리오 모두 깊이 파고들수록 더 위험해집니다. Rust의 결과물은 스캔 도구와 비슷하기 때문입니다. 모든 취약점, 공격 벡터, 문제를 스캔하는 만능 SAST/DAST/RAST/IAST 도구가 없듯이 Rust도 마찬가지입니다. Rust를 사용하더라도 일부 취약점은 여전히 쉽게 유입될 수 있습니다.

Unsafe Rust 실행 시 발생하는 정의되지 않은 동작의 위험은 정수 오버플로우 문제를 야기할 수 있습니다. 일반적으로 안전한 설정이라 하더라도 보안 설정 오류, 비즈니스 로직상의 실수, 또는 알려진 취약점이 있는 구성 요소 사용으로 인한 인적 오류를 완전히 막을 수는 없습니다. 이러한 문제는 패치되지 않으면 여전히 실질적인 위협이 되며, 진정한 Rust와 같이 "안전하다고 가정되는" 환경에서는 모든 주요 문제가 자동으로 해결될 것이라고 믿는 안일한 태도를 유발할 수도 있습니다.

저는 Rust가 프로그래밍 멘토와 비슷하다고 생각합니다. 경험이 부족한 개발자 옆에 앉아 작업을 검토하고, 잠재적인 버그를 보여주며, 효율성을 지적하고, 때로는 코드가 올바르게 작성될 때까지 컴파일을 막아주는 시니어 엔지니어와 같죠. 하지만 Rust 프로그래머는 이론을 배우고 스스로 모범 사례를 실천하는 것이 훨씬 좋습니다. 멘토가 언제든 떠날 수 있고, 혼자 남겨지는 상황을 원하지는 않을 테니까요.

지금 바로 일반적인 Rust 취약점을 찾고 수정할 준비가 되셨나요? 챌린지에 참여하세요.