💻 computer science

Vulnerability Abundance: A formal proof of infinite vulnerabilities in code

이 논문은 단일 C 프로그램인 '취약점 공장 (Vulnerability Factory)'이 무한히 많은 고유한 취약점을 포함할 수 있음을 형식적으로 증명하고, 이를 통해 소프트웨어의 전체 취약점 집합이 무한하며, 실제 악용 사례는 취약점의 풍부함과 소프트웨어의 시장 점유율에 따라 결정된다는 '취약점 풍부성 (Vulnerability Abundance)' 개념을 제시합니다.

원저자: Eireann Leverett, Jeroen van der Ham-de Vos

게시일 2026-04-10

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Eireann Leverett, Jeroen van der Ham-de Vos

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

1. 핵심 발견: "취약점 공장 (Vulnerability Factory)"

저자들은 C 언어로 작성된 아주 작은 프로그램 하나를 만들었습니다. 이 프로그램의 이름은 **'취약점 공장'**입니다.

비유: 이 공장은 마치 무한한 종류의 도구를 찍어내는 기계와 같습니다.
어떻게 작동하나요? 이 공장은 실행될 때마다 숫자 (1, 2, 3...) 를 하나씩 늘려가며, 그 숫자에 맞춰 새로운 소프트웨어 조각을 만듭니다.
무엇을 만드나요? 각 조각마다 고유의 '해킹 구멍'이 하나씩 박혀 있습니다. 숫자가 100 이 되면 100 번 째 구멍이 생기고, 숫자가 1000 이 되면 1000 번 째 구멍이 생깁니다.
결론: 이 공장은 이론상 무한히 많은 (셀 수 있는 무한대) 서로 다른 해킹 구멍을 만들어낼 수 있습니다. 즉, 소프트웨어에 숨겨진 구멍은 우리가 생각했던 것보다 훨씬 더 많고, 끝이 없다는 것이 수학적으로 증명된 것입니다.

2. 중요한 구분: "구멍"과 "해킹 도구"는 다릅니다

이 논문에서 가장 중요한 점은 **"구멍이 무한하다고 해서, 해커가 그걸 다 이용할 수 있는 건 아니다"**라고 강조한다는 것입니다.

비유 (화학 원소와 산업):
- 우주에는 수소, 헬륨, 금, 우라늄 등 수많은 원소가 있습니다. (이것이 '무한한 취약점'에 비유됩니다.)
- 하지만 우리가 일상에서 실제로 많이 쓰는 것은 철, 알루미늄, 구리 등 몇 가지 원소뿐입니다. (이것이 '실제 해킹에 쓰이는 취약점'에 비유됩니다.)
- 우주에 금이 아주 많다고 해서, 우리가 금으로 만든 물건을 매일 쓰는 건 아닙니다.
현실: 연구에 따르면, 발표된 해킹 구멍 (CVE) 중 실제로 해커들이 공격에 사용하는 경우는 약 6% 미만입니다. 나머지 94% 이상은 구멍이 있긴 하지만, 해커들이 "이걸로 뭘 해볼 가치가 없다"고 생각하거나, 해킹 도구를 만드는 비용이 너무 비싸서 그냥 지나칩니다.

3. 새로운 개념: "취약점의 풍부함 (Vulnerability Abundance)"

저자들은 화학에서 쓰는 **'원소의 풍부함'**이라는 개념을 소프트웨어에 적용했습니다.

비유:
- C/C++ 언어: 마치 석유처럼, 여기저기서 많이 쓰이지만 누출 (해킹) 이 자주 발생하는 위험한 원료입니다. (메모리 관련 구멍이 매우 풍부함)
- Rust/Python 언어: 마치 전기나 태양광처럼, 석유처럼 누출이 적지만 다른 방식의 문제 (로직 오류 등) 가 발생할 수 있습니다.
의미: 우리가 어떤 언어로 프로그램을 많이 만들느냐에 따라, 세상에 떠도는 해킹 구멍의 종류와 비율이 달라집니다. 언어가 바뀌면 구멍의 종류도 바뀝니다.

4. 왜 이것이 중요한가요? (실제 영향)

이론적으로 구멍이 무한하다고 해서 우리가 "아, 포기하자"라고 할 수는 없습니다. 오히려 다음과 같은 전략이 필요합니다.

모든 구멍을 막을 수 없다: 구멍이 무한히 많으므로, 하나하나 다 찾아서 고치는 것은 '시시포스의 일' (끝없는 노동) 입니다.
주요 목표에 집중하라: 해커들은 구멍이 많은 곳보다는 **사람들이 많이 쓰는 곳 (시장 점유율이 높은 소프트웨어)**을 노립니다.
- 비유: 바다에 물고기가 무한히 많다고 해서, 모든 바다를 다 낚시할 수는 없습니다. 대신 물고기가 가장 많이 모인 어장을 찾아서 그곳을 보호하는 것이 훨씬 효율적입니다.
경제적 접근: 구멍을 막는 비용과 해킹으로 인한 손실 비용을 따져보고, 가장 많이 쓰이는 소프트웨어의 가장 흔한 구멍 (풍부한 구멍) 부터 막는 것이 현명합니다.

5. 결론: 바다를 비우지 말고, 흐름을 읽자

이 논문의 결론은 매우 명확합니다.

"소프트웨어의 해킹 구멍은 무한한 바다입니다. 우리는 이 바다를 완전히 비울 수 없습니다. 하지만 우리는 이 바다의 흐름을 이해할 수 있습니다. 어떤 종류의 구멍이 가장 흔한지, 어디에 가장 많이 분포하는지, 그리고 해커들이 어디로 몰려드는지를 파악하여, 우리의 방어선을 지혜롭게 배치해야 합니다."

한 줄 요약:

"소프트웨어에는 끝없는 해킹 구멍이 있지만, 해커들은 그중에서도 가장 많이 쓰이는 프로그램의 흔한 구멍만 노립니다. 따라서 우리는 모든 구멍을 다 막으려 애쓰기보다, **어떤 구멍이 가장 위험한지 (풍부한지)**를 분석하여 집중적으로 방어해야 합니다."

1. 연구 배경 및 문제 제기 (Problem)

소프트웨어 보안 분야에서 가장 근본적인 논쟁 중 하나는 "소프트웨어 취약점은 본질적으로 유한한가, 무한한가?" 입니다.

희소성 (Sparse) 가설: 취약점이 유한하며, 발견하고 패치할수록 보안이 강화된다는 관점.
밀도 (Dense) 가설: 취약점이 무한하거나 고갈되지 않는다는 관점. (Geer 등)
기존 연구의 한계: Spring 과 Illari 와 같은 이전 연구들은 계산 이론 (정지 문제, Rice 의 정리) 을 통해 취약점이 무한할 가능성이 있다고 추론했지만, 구체적인 실행 가능한 예시나 형식적 증명은 부족했습니다.
핵심 질문: 하나의 프로그램이 실제로 무한히 많은 고유한 CVE(공통 취약점 및 노출) 를 가질 수 있는가? 그리고 이것이 전체 소프트웨어 생태계에 어떤 의미를 갖는가?

2. 방법론 (Methodology)

저자들은 다음과 같은 다층적 접근 방식을 사용하여 문제를 해결했습니다.

A. 구성적 증명 (Constructive Proof): "Vulnerability Factory"

Vulnerability Factory: 622 줄의 C 언어 프로그램으로, 실행될 때마다 새로운 모듈을 생성하는 자기 재생산 메커니즘을 가집니다.
구조:
1. Base Set (B): 11 개의 기본 함수로 구성되며, 각각 11 가지 서로 다른 CWE(약점 분류) 클래스 (예: 스택 버퍼 오버플로우, 포맷 문자열, 정수 오버플로우 등) 의 취약점을 포함합니다.
2. Generator (G): 매 실행 시 정수 카운터 $n$ 을 읽어서 새로운 C 소스 파일 (vuln_module_n.c) 을 생성합니다.
3. 매개변수화 (Parameterization): 생성된 모듈 $M_n$ 은 $n$ 에 따라 버퍼 크기, 오버플로우 임계값, 할당 크기 등이 달라지는 5 가지 취약점을 포함합니다.
CVE 할당 규칙 준수: MITRE 의 CVE Counting Rules 에 따라, 각 모듈은 별도의 컴파일 단위 (공유 라이브러리) 이며, 독립적으로 수정 가능하고 고유한 패치 Payload 를 필요로 하므로 각각 별도의 CVE 를 부여받을 수 있습니다.

B. 형식적 분석 및 수학적 모델링

집합론적 증명: 생성된 취약점 집합 $V$ 가 가산 무한 (Countably Infinite, $\aleph_0$ ) 임을 증명했습니다.
튜링 기계 (Turing Machine) 모델링: Vulnerability Factory 를 튜링 기계로 추상화하여, 취약점 생성 메커니즘이 계산 가능 (Computable) 하고 구조적으로 투명함을 보였습니다.
모델 체킹 (Model Checking): 상태 전이 시스템을 통해 취약점 수가 임의의 유한 상한 $C$ 를 초과할 수 있음을 확인했습니다.

C. 취약점 풍부성 (Vulnerability Abundance) 개념 도입

화학의 '원소 풍부성 (Elemental Abundance)' 개념을 차용하여, 소프트웨어 코퍼스 (Corpus) 내에서의 취약점 클래스의 비율적 분포를 정량화하는 새로운 프레임워크를 제안했습니다.

3. 주요 기여 (Key Contributions)

무한한 취약점의 형식적 증명: 하나의 C 프로그램 (Vulnerability Factory) 이 가산 무한한 수의 고유하고 CVE 할당이 가능한 취약점을 생성함을 수학적으로 증명했습니다.
재사용 가능한 증명 산물 (Proof Artifact): Vulnerability Factory 를 튜링 기계로 형식화하여, 향후 취약점 이론 연구의 기초적인 '테스트 객체'로 사용할 수 있도록 했습니다.
취약점 풍부성 (Vulnerability Abundance) 프레임워크: 취약점의 절대적 수보다는 언어, 아키텍처, 배포 환경에 따른 취약점 클래스의 분포 비율을 분석하는 새로운 관점을 제시했습니다.
무한한 취약점 vs 유한한 악용 (Exploit) 의 구분: 취약점은 무한하지만, 실제 악용되는 사례는 매우 드물며 (약 6% 미만), 이는 소프트웨어의 시장 점유율과 밀접한 연관이 있음을 실증적 데이터로 설명했습니다.
예측적 사이버 리스크 분석: 취약점 풍부성과 배포 점유율의 상호작용을 통해 미래의 사이버 리스크를 예측하는 실용적 가치 제시.

4. 연구 결과 (Results)

정리 4.4 (Main Theorem): Vulnerability Factory 가 생성하는 취약점 집합 $V$ 는 가산 무한하며, 모든 원소는 CVE 할당 규칙을 만족합니다.
정리 9.1: 하나의 프로그램이 무한한 취약점을 가지므로, 모든 소프트웨어의 취약점 집합 또한 무한합니다.
실증적 발견:
- 생성된 취약점 중 실제 악용 (Exploitation) 비율은 매우 낮음 (약 2.6% ~ 6%).
- 악용 빈도는 취약점의 풍부성뿐만 아니라 해당 소프트웨어의 시장 점유율 (Deployment Share) 에 의해 결정됨.
- 소수의 주요 소프트웨어 스택 (Monoculture) 에 대한 몇 가지 악용 코드만으로도 전 세계 시스템의 대부분을 위협할 수 있음 (Small-Exploit Principle).

5. 의의 및 중요성 (Significance)

패치 전략의 재정의: "모든 취약점을 찾아서 고치는 것"이 불가능하므로 (Sisyphean labour), 리소스를 가장 풍부한 취약점 클래스와 가장 널리 배포된 소프트웨어에 집중해야 함을 시사합니다.
프로그래밍 언어 설계의 중요성: 언어 선택 (예: 메모리 안전 언어인 Rust vs C) 이 취약점의 '스펙트럼'을 결정합니다. 언어의 변화는 취약점 풍부성의 분포를 근본적으로 바꿀 수 있습니다.
경제적 관점의 확장: 보안 실패는 기술적 결함뿐만 아니라 경제적 인센티브의 불일치에서 비롯되며, '취약점 풍부성' 데이터를 통해 투자 대비 효과 (ROI) 가 높은 예방 조치를 식별할 수 있습니다.
이론적 한계의 명확화: 유한한 데이터베이스나 스캐너가 모든 취약점을 찾을 수 없다는 것을 증명하여, 완전한 보안 (Perfect Security) 이 불가능함을 다시 한번 확인시켰습니다.

결론

이 논문은 "취약점은 무한하며, 이를 제거하는 것은 불가능하다" 는 사실을 형식적으로 증명함으로써, 보안 패러다임을 '모든 취약점 제거'에서 '취약점 풍부성 분석과 위험 기반 관리' 로 전환해야 함을 강력하게 주장합니다. Vulnerability Factory 는 이 이론적 전환을 뒷받침하는 구체적인 도구이자, 미래 보안 연구의 기준점이 될 것입니다.