Codex Vulnerability Research Harness — Linux Kernel에서 Adaptive OSS까지

🧭

한 줄 요약

대규모 코드베이스를 LLM에 그대로 맡기는 대신, 모델 밖에서 계산한 신호로 조사 대상을 좁히고, 세션 상태·저장소 provenance·증거 계약·사람의 재현 검증을 결합해 AI 보안 연구를 반복 가능한 시스템으로 만들었습니다.

항목	내용
기간	2026.04–2026.08 · 공개 Git 이력 기준
수행 형태	개인 보안 연구·Python 도구 개발 · 4개 공개 저장소
역할	연구 문제 정의, 타깃 랭킹, 세션 오케스트레이션, 실험 설계, 안전 경계, 재현·공개
기술	Python · Bash · Codex CLI · Git · Linux Kernel · syzbot · SBOM · GitHub Actions · ASan/UBSan
핵심 원칙	Priority is not proof. Diversity is not consensus.

🏁

공개 결과

이 하네스 계열을 활용한 조사 결과로 저장소에 직접 귀속된 공개 CVE는 13건입니다. Kernel track 2건, OSS v2 3건, Adaptive track 8건이며, 이와 별도로 통합 CVE 1건에 authorization-bypass variant 2개를 기여했고 CVE가 없는 GitHub-reviewed advisory 1건이 공개됐습니다. 모델이 자동으로 13건을 확정했다는 뜻은 아니며, 최종 reachability·impact 검증과 disclosure는 사람이 수행했습니다.

왜 이 프로젝트를 시작했는가 네 저장소를 하나로 묶은 이유 시스템 아키텍처 1. 모델 호출 전 — 설명 가능한 후보 랭킹 2. 모델 호출 중 — 좁은 조사 단위와 상태 계약 3. 모델 호출 후 — provenance와 증거 검증 내가 설계하고 구현한 핵심 A. Attention allocation을 독립 계층으로 분리 B. 장시간 연구를 durable state machine으로 전환 C. External Signal을 통제 변수로 만든 비교 실험 D. 재현성과 탐색성을 함께 보존한 Adaptive search E. 신뢰할 수 없는 입력과 agent 실행 경계를 hardening 시행착오가 설계를 바꾼 지점 공개 성과와 검증 범위 엔지니어링 검증 한계와 다음 단계 이 프로젝트가 보여주는 역량 Sources Primary implementation Key evolution commits Internal research context

왜 이 프로젝트를 시작했는가

Linux Kernel처럼 큰 코드베이스를 한 번에 LLM에 맡기면 컨텍스트가 빠르게 분산됐습니다. 모델은 눈에 띄는 API나 이미 익숙한 hot path에 집중했고, copy_from_user, allocator, 인증 함수처럼 위험해 보이는 토큰의 존재를 실제 공격 가능성과 혼동했습니다. 실행 횟수를 늘리는 것만으로는 같은 영역의 반복 조사와 false positive가 늘어났습니다.

문제를 모델 성능이 아니라 조사 예산을 어디에 배분하고, 어떤 증거를 통과시킬 것인가의 문제로 다시 정의했습니다.

Attention allocation — 모델 실행 전에 재현 가능한 신호로 조사 순서를 결정합니다.

Evidence contract — confidence보다 entrypoint, attacker control, invariant 또는 sink, impact, 기존 방어의 부재를 요구합니다.

Provenance — 강한 finding에도 branch, HEAD, dirty state, known reference를 남깁니다.

Controlled diversity — 하나의 ranking이 만든 편향을 서로 다른 탐색 가설로 분리합니다.

Human closure — 후보 생성과 취약점 증명을 분리하고, 마지막 판단은 재현과 책임 있는 공개로 닫습니다.

💡

높은 점수는 취약점 확률이 아니고, 여러 세션의 동의도 증명이 아닙니다. 점수와 reward는 다음 조사 대상을 고르는 값으로만 사용했습니다.

네 저장소를 하나로 묶은 이유

네 저장소는 같은 실행 파일의 단순 버전업은 아닙니다. 하나의 연구 질문에서 갈라진 두 개의 트랙으로 보는 것이 가장 정확합니다.

ℹ️

Git 계보에 대한 정확한 표현

Kernel v1과 v2는 최초 2개 커밋을 공유한 뒤 갈라졌습니다. OSS v2와 Adaptive는 서로 다른 root commit을 가지지만 Adaptive 초기 snapshot과 OSS v2의 2026-04-10 snapshot은 공통 파일 다수를 동일한 blob으로 공유합니다. Kernel과 OSS 사이의 연결은 공개 Git parent 관계라기보다, 내부 R&D 기록과 설계 원칙에서 확인되는 연구 계보입니다. 따라서 포트폴리오에서는 하나의 상위 프로젝트 아래 두 트랙으로 묶되, 단일 선형 branch처럼 표현하지 않았습니다.

단계	핵심 질문	주요 변화	근거
Kernel v1	대규모 커널에서 어디를 먼저 볼 것인가?	경로·lexical pattern·syzbot overlap으로 파일을 랭킹하고 target별 prompt/snippet 생성	repository · targeting.py
Kernel v2	강한 finding을 어떤 기준점에서 검토할 것인가?	branch·HEAD·dirty state·known reference를 이용한 fail-closed review bucket	repository · finding_triage.py
OSS v2	External Signal의 효과를 어떻게 분리해 볼 것인가?	다중 언어 policy·graph·Git·advisory·crash·SBOM과 blind/signal/dual 비교	repository · dual.py
Adaptive v3	한 ranking의 조기 수렴을 어떻게 줄일 것인가?	4개 격리 세션, fixed prefix 30개, adaptive tail 15개, deterministic review merge	repository · autopilot.py

시스템 아키텍처

1. 모델 호출 전 — 설명 가능한 후보 랭킹

Kernel track은 6개 subsystem profile을 사용해 .c·.h 파일의 path weight, usercopy·allocation·refcount·size·lifetime 관련 line signal, 저장된 syzbot overlap을 합산했습니다. 동일 점수는 경로 순으로 정렬해 결과를 결정적으로 만들었습니다. 점수는 “취약할 확률”이 아니라 제한된 시간에 먼저 볼 파일의 순서입니다.

OSS track에서는 Python AST와 다른 언어의 lightweight symbol extraction, import/reference graph, project policy, Git history, advisory·crash·sanitizer signal, SBOM context를 추가했습니다. 생성물·header·반복 토큰에 대한 penalty와 강한 evidence의 retention exemption을 함께 두어, 단순 토큰 빈도만으로 후보가 사라지거나 과대평가되지 않게 했습니다. (OSS targeting)

2. 모델 호출 중 — 좁은 조사 단위와 상태 계약

각 candidate는 targets.json, score reason, local snippet, prompt bundle로 저장됩니다. 한 번에 하나의 target과 정확히 하나의 next target만 다루며, follow-up 깊이와 동일 target 재시도를 제한했습니다. 수동 검토와 autopilot이 같은 review_state.json과 verdict parser를 사용해 중단 후에도 이어갈 수 있게 했습니다.

Pending target이 없는 오래된 응답, timeout, parse error, 인증 만료, nonzero exit는 finding으로 승격하지 않습니다. Adaptive v3에서는 state를 temporary file에 쓴 뒤 atomic replace하고, 세 번 실패한 target은 durable exhausted state로 남겨 다음 실행에서 무한 반복되지 않도록 했습니다. (session state · retry handling)

3. 모델 호출 후 — provenance와 증거 검증

Kernel v2는 strong verdict를 바로 “새 취약점”으로 기록하지 않습니다. Git 상태를 확인할 수 없으면 provenance_unknown, repository 또는 target이 수정돼 있으면 dirty_tree_suspect, 관련 CVE·known marker·HEAD에 포함된 fix가 있으면 known_issue, 그 외에만 new_candidate로 분류합니다. new_candidate조차 novelty proof가 아니며 모든 결과의 novelty_proven은 false입니다.

OSS review는 attacker control, reachability, entrypoint, sink 또는 invariant, evidence location, concrete impact, blocking gap을 요구합니다. S/A tier는 실제 repository-relative path와 구체적 impact가 없으면 통과하지 못하고, merge에서는 tier가 confidence와 session rank보다 우선합니다.

내가 설계하고 구현한 핵심

A. Attention allocation을 독립 계층으로 분리

LLM에게 “전체를 봐 달라”고 요청하는 대신, source observation을 먼저 계산하고 그 이유를 candidate와 함께 남기는 scanner를 구현했습니다. 이 구조 덕분에 모델이 왜 특정 파일을 받았는지, 어떤 신호가 ranking을 바꿨는지 사후 검토할 수 있습니다.

B. 장시간 연구를 durable state machine으로 전환

Prompt 생성, Codex 실행, ingest, follow-up, finding 보존을 하나의 상태 머신으로 묶었습니다. stale artifact를 다른 target에 잘못 연결하지 않도록 격리하고, parse failure가 rank를 완료 처리하지 않으며, resume 시 가장 낮은 미완료 rank부터 복구하도록 개선했습니다.

C. External Signal을 통제 변수로 만든 비교 실험

OSS v2에서는 source-only baseline에 가까운 blind, external evidence를 포함한 signal, 두 결과를 diversity-aware 방식으로 병합한 dual을 분리했습니다. Candidate에는 각 arm의 rank와 provenance를 남겨 “신호가 있었다”는 사실과 취약점 증명을 구분했습니다. Blind도 policy·lexical·graph를 사용하므로 완전한 no-prior baseline이라고 과장하지 않았습니다.

D. 재현성과 탐색성을 함께 보존한 Adaptive search

Adaptive v3는 default, nosignal, coldrisk, hotrisk 네 가설을 독립 session state로 실행합니다. 먼저 rank 1–30을 원래 순서대로 처리해 재현 가능한 prefix를 보존하고, 이후에만 상위 15개 tail shortlist를 재계산합니다.

동적 점수는 normalized rank 65%, raw score 35%에 subsystem·target reward, exploration bonus, runtime cost, retry·timeout penalty를 결합합니다. Reward는 다음 조사 예산의 proxy일 뿐 CVE 가능성이 아닙니다. 네 session은 같은 model·repository·policy를 공유하므로 통계적으로 독립된 실험으로도 해석하지 않았습니다. (fixed/adaptive selection)

E. 신뢰할 수 없는 입력과 agent 실행 경계를 hardening

Codex subprocess 기본 sandbox를 read-only로 설정했습니다.

full-auto + read-only처럼 의미가 충돌하는 조합을 거부했습니다.

absolute path, traversal, Windows drive, UNC, multiline path와 repository symlink를 차단했습니다.

실패한 task가 이전 response·review·report를 재사용하지 못하게 했습니다.

repro package의 파일 수·총 크기·필수 파일·출력 경계를 검사하고 자동 실행하지 않았습니다.

이 설계는 “sandbox가 있으니 안전하다”는 주장이 아닙니다. Read-only는 target mutation을 줄이지만 host에서 읽을 수 있는 secret의 기밀성을 보장하지 않으므로, 실제 연구는 credential-free disposable environment를 전제로 합니다. (path boundary · executor)

시행착오가 설계를 바꾼 지점

관찰한 실패	원인	후속 설계
동적 프롬프트 압축 실험에서 품질 하락	분석 agent에게 정책 변경까지 맡겨 실행마다 컨텍스트가 흔들림	Policy와 signal을 명시적 artifact·CLI flag로 분리
`not_cve`가 positive substring으로 오인됨	자유 형식 응답과 느슨한 parser	정확히 하나의 verdict label, duplicate·negative prose 거부, 회귀 테스트 추가
Hard cooling이 한 subsystem을 과도하게 제외	반복 방지를 이진 차단으로 처리	감쇠 reward·cost·exploration·retry penalty를 이용한 우선순위 조정
강한 finding의 기준점이 불명확	dirty tree, 기존 fix, CVE reference가 같은 큐에 섞임	fail-closed Git provenance bucket과 structured JSONL
실패 응답과 stale artifact가 결과를 오염	semantic verdict와 operational failure가 분리되지 않음	timeout·parse·nonzero를 별도 상태로 보존하고 durable retry exhaustion 구현

초기 시행착오는 로컬 R&D 기록의 codex-oss-vuln-harness v1 & v2, ossharness-base-engine-testcold, ossharness-base-engine-fox 페이지와 후속 공개 커밋을 대조해 정리했습니다. 설계안으로만 남은 attack-chain 자동화와 내부 semi-benchmark 수치는 완성 성과에서 제외했습니다.

공개 성과와 검증 범위

연구 범위	대표 결과	보안 경계
Linux Kernel · memory safety	CVE-2026-31720	USB gadget audio control request의 host-controlled length와 4-byte stack object 경계
Linux Kernel · authorization	CVE-2026-53075	PPP administrative ioctl과 target network namespace의 `CAP_NET_ADMIN` 검증
Web · SSRF / authorization / OAuth	CVE-2026-33953 · CVE-2026-33954 · CVE-2026-34460	목적지 검증 불일치, interface 간 권한 불일치, OAuth state binding 부재
Native / Embedded	CVE-2026-33636 · CVE-2026-41429 · CVE-2026-45815	AArch64 OOB, network parser memory corruption, BLE ATT parser assertion
Policy / AI / CI	CVE-2026-33729 · CVE-2026-47391 · CVE-2026-48168	Authorization cache-key collision, unauthenticated agent-to-eval path, PR metadata의 shell injection

전체 공개 결과와 attribution boundary

별도 기여

CVE-2026-34584 — 여러 연구자의 보고가 통합된 CVE에 authorization-bypass variant 2개 기여. 단독 발견으로 계산하지 않음.

GHSA-gx7w-56w6-g48x — GitHub-reviewed advisory, CVE 없음.

해석 원칙

“직접 귀속”에는 공개 advisory의 finder·reporter·acknowledgement 등 서로 다른 credit 유형이 포함될 수 있으며, 모든 항목을 단독 보고로 해석하지 않습니다.

과거 per-finding mode log가 완전하지 않아 각 CVE를 특정 blind, signal, default, hotrisk session이나 현재 main commit에 사후 귀속하지 않습니다.

공개 전 finding의 세부 정보와 자체 CVSS는 포트폴리오에서 제외했습니다.

엔지니어링 검증

저장소	현재 regression test	최신 HEAD	최신 CI 확인
Kernel v1	6	`006d323e`	success · 2026-08-09
Kernel v2	16	`d5846732`	success · 2026-08-09
OSS v2	56	`9e9a572a`	success · 2026-08-09
Adaptive v3	62	`879ff924`	success · 2026-08-09

네 저장소의 현재 test case를 합치면 140개이며 버전 간 공통 회귀 계약이 포함됩니다. CI는 Ubuntu의 Python 3.11·3.12에서 unit test, shell syntax, wheel build/install, CLI smoke test를 수행합니다. 네 저장소 모두 runtime dependency 없이 표준 라이브러리 중심으로 구성했고 Apache-2.0으로 공개했습니다.

한계와 다음 단계

탐지 성능 benchmark 부재 — 공개 CVE는 operational outcome이지 precision·recall 또는 discovery-rate를 증명하는 통계가 아닙니다.

Heuristic analysis — compiler-grade call graph, interprocedural data flow, symbolic execution을 대체하지 않습니다. Python은 AST를 사용하지만 다른 언어는 경량 extraction의 비중이 큽니다.

Correlated search modes — 네 adaptive session은 같은 model·repository·policy를 공유하므로 독립 표본이 아닙니다. 초기 verdict를 reward로 재사용해 잘못된 판단이 tail budget에 영향을 줄 수도 있습니다.

Historical provenance gap — 초기 연구의 model·mode·prompt·target commit을 finding별로 완전하게 보존하지 못했습니다.

Isolation boundary — read-only sandbox는 secret confidentiality를 보장하지 않으며, untrusted repository는 별도 container/VM과 제한된 egress가 필요합니다.

Platform scope — 공개 CI는 Linux/Python 3.11·3.12 중심입니다. macOS path alias와 다른 런타임을 포함한 cross-platform 검증은 보강할 부분입니다.

다음 단계는 Clang/tree-sitter 기반 symbol·call graph, immutable per-finding manifest, held-out corpus를 사용한 signal ablation, session 간 실제 coverage diversity 측정, secret 없는 disposable runner와 egress policy의 통합입니다.