Adaptive OSS Vulnerability Harness — Controlled Diversity 기반 AI Security Research

OSS v2·Adaptive v3 연구 계보 · 직접 귀속 공개 CVE 11건

Linux Kernel에서 검증한 External Signal 원칙을 다중 언어 OSS로 일반화하고, controlled comparison과 adaptive multi-session search를 결합한 AI-assisted vulnerability research system을 설계했습니다.

왜 Linux Kernel에서 범용 OSS로 확장했는가

선행 Kernel Codex Harness 프로젝트에서 제가 설계한 External Signal 기반 하네스가 실제 Linux 조사에 효과적으로 동작하는 것을 확인했습니다. 그래서 같은 증거 계약을 유지한 채 분석 표면을 kernel에서 web application, backend, parser, native library와 mixed-language repository로 넓혔습니다.

이 프로젝트는 Kernel v2 뒤에 직선으로 이어진 버전이 아닙니다. 2026년 4월 5일 Kernel v1 공통 기반 위에 Generic OSS Harness를 새 package로 작성했고, 9분 뒤 동일한 source snapshot을 standalone OSS v2로 분리했습니다. 즉 Kernel v1에서 갈라진 직접적인 연구 분기이지만, 커널 규칙을 그대로 옮긴 단순 포팅은 아닙니다.

PROJECT OVERVIEW

항목	내용
기간	2026.04–현재
형태	개인 OSS 보안 연구 · Public AI-assisted research tooling
해결하려던 문제	저장소마다 language·framework·entrypoint와 trust boundary가 다른 환경에서 하나의 prompt나 ranking이 만드는 편향과 조기 수렴
대상·환경	Web application · backend service · native library · parser · CLI · mixed-language OSS · Codex CLI · Python · Bash · Docker
분석·구현 범위	project policy, multi-language targeting, import graph·semantic hint, Git·advisory·crash·SBOM signal, blind/signal/dual comparison, isolated multi-session search, strict review·repro·report
버전 계보	Kernel v1 공통 기반 → Generic OSS branch → OSS v2 — Controlled Signal Comparison → Adaptive v3 — Controlled Search Diversity
결과	직접 귀속 공개 CVE 11건 · 식별자 부여 후 upstream publication 대기 3건 · 통합 CVE 1건의 두 variant 기여 · CVE 없는 GitHub-reviewed advisory 1건

https://github.com/foxirain/codex-adaptive-oss-vuln-harness

핵심 질문 — External Signal은 서로 다른 OSS에서도 탐색 위치를 설명 가능하게 바꿀 수 있는가? 그리고 하나의 ranking이 가진 편향을 서로 다른 search hypothesis와 동일한 evidence contract로 줄일 수 있는가?

Project Flow

단계	연구 질문	설계 변화
1. 범용화	커널 전용 가정을 제거해도 동일한 조사 계약을 유지할 수 있는가	kernel profile을 project policy와 language·framework signal로 대체
2. OSS v2	External Signal이 실제로 ranking을 어떻게 바꾸는가	blind·signal-aware·dual search를 독립 실행하고 provenance를 보존
3. 운영 실험	다양한 target에서 어느 신호와 prompt가 실패하는가	bootstrap·audit·follow-up·review·repro·report의 bounded workflow
4. Adaptive v3	한 번의 ranking이 만드는 조기 수렴을 어떻게 줄일 것인가	default·nosignal·coldrisk·hotrisk를 격리한 multi-session search
5. Adaptive tail	고정 순위 이후 남은 예산을 어디에 배분할 것인가	fixed prefix 30개와 reward·exploration 기반 tail shortlist 15개
6. Human closure	여러 session의 강한 주장을 어떻게 같은 기준으로 비교할 것인가	strict schema, deterministic merge, positive·negative validation과 responsible disclosure

ROLE

AI-Assisted Vulnerability Researcher · Security Research Systems Engineer

연구 방법 설계 — External Signal을 controlled search variable로 바꾸고 blind·signal·adaptive exploration의 비교 구조를 설계했습니다.

분석 엔진 구현 — policy, language·framework detection, graph·semantic analysis, advisory·crash·SBOM와 Git signal을 결합했습니다.

멀티 세션 오케스트레이션 — isolated search mode, fixed prefix, adaptive tail, bounded retry·follow-up과 deterministic merge를 구현했습니다.

검증·공개 — source hypothesis를 runtime·authorization·protocol·memory boundary 검증으로 닫고 maintainer와 coordinated disclosure를 진행했습니다.

TECH STACK

Python · Bash · Codex CLI · Git · Docker · SBOM · GitHub Security Advisory · ASan/UBSan · Multi-Language Static Heuristics

MY WORK

1. Kernel 하네스의 운영 골격을 범용 OSS 엔진으로 분기했습니다

Git 기록상 Generic OSS Harness는 4월 5일 00:30에 Kernel v1 저장소 안의 새로운 “oss_harness” package로 처음 작성됐고, 00:39에 standalone OSS v2의 root commit으로 추출됐습니다. 두 시점의 OSS source·config·document 18개 파일은 Git blob ID가 동일합니다.

다음 운영 골격은 Kernel에서 계승했습니다.

scan → rank → bundle → focused prompt

Codex exec → ingest → session state

single best next target과 bounded follow-up

finding promotion과 human proof의 분리

반면 분석 엔진은 새로 일반화했습니다.

kernel subsystem profile → target별 Markdown policy

ioctl·usercopy·refcount → 언어별 entrypoint·sink·trust boundary

syzbot 중심 signal → Git·advisory·crash·sanitizer·SBOM

C source 중심 탐색 → Python, JavaScript/TypeScript, Go, Rust, C/C++, Java/Kotlin, PHP, Ruby

따라서 이 프로젝트는 같은 철학을 가진 직접 후속이지만, 새로운 분석 표면과 실험 질문을 위해 다시 설계한 별도 연구 단계입니다.

2. OSS v2에서 target-specific policy와 multi-language signal을 만들었습니다

저장소마다 공격면과 금지할 finding이 다르기 때문에 하나의 범용 규칙 파일 대신 target별 policy를 사용했습니다.

Policy는 다음을 분리했습니다.

in-scope와 out-of-scope surface

entrypoint, hot path와 preferred sink

preferred bug class와 forbidden finding

include·exclude path

language와 framework hint

소스 분석에는 language marker, framework manifest, import graph, symbol·handler hint와 entrypoint–sink proximity를 사용했습니다. Python은 AST 기반 symbol indexing을 적용하고, 다른 언어는 lightweight extraction을 사용했습니다. 이 결과는 compiler-grade semantic proof가 아니라 후보의 상대적인 review order입니다.

3. External Signal을 “추가 점수”에서 “통제 변수”로 발전시켰습니다

OSS v2의 핵심은 신호를 많이 넣는 것이 아니라, 넣었을 때와 뺐을 때를 분리한 것입니다.

Blind arm — explicit External Signal과 Git history를 제거한 source-driven baseline

Signal-aware arm — policy, Git, advisory, crash와 SBOM evidence를 포함한 ranking

Dual arm — 두 ranking을 번갈아 소비하고 path·subsystem·exposure diversity를 보존한 merge

Merged candidate에는 blind rank, signal rank, source arm과 final rank를 남겼습니다. 여기서 novelty는 새로운 취약점 수가 아니라 두 탐색 분포에서 후보가 얼마나 달라졌는가를 뜻합니다.

External evidence should change where the investigation looks, not what the investigation is allowed to conclude.

4. 실제 OSS 반복 실행으로 일반화가 깨지는 지점을 찾았습니다

복원된 Docker 환경에는 관련 Codex session 125개가 남아 있습니다. gRPC와 CEL의 반복 audit·follow-up·review를 중심으로 SentencePiece, FlatBuffers, protobuf, V8과 OpenThread 등 서로 다른 target의 흔적이 확인됩니다.

이 과정에서 다음 문제가 드러났습니다.

generated artifact가 source candidate를 밀어내는 문제

native exposure와 wrapper code를 같은 방식으로 평가하는 오류

특정 subsystem과 follow-up branch에 예산이 고착되는 현상

schema를 만족하지 않은 강한 문장이 finding으로 승격되는 문제

timeout·nonzero exit·missing response를 semantic verdict와 혼동하는 문제

이를 generated-artifact suppression, exposure classification, strict promotion field, branch cooling과 operational failure 분리로 보강했습니다.

5. Adaptive v3에서 Controlled Diversity를 구현했습니다

OSS v2의 두 ranking 비교를 네 개의 독립적인 search hypothesis로 확장했습니다.

Mode	탐색 역할
default	bootstrap이 만든 project-specific signal을 그대로 사용
nosignal	external signal JSON 없이 source·policy·graph 중심으로 탐색
coldrisk	덜 주목받는 boundary와 낮은 heat 경로를 강조
hotrisk	advisory·CVE·crash·sanitizer 인접 variant에 집중

각 mode는 독립된 session state, target manifest, response와 review artifact를 가집니다. 여러 agent의 다수결을 만들려는 것이 아니라 서로 다른 탐색 분포를 의도적으로 격리하려는 설계입니다.

상위 30개는 원래 rank 순서대로 실행해 reproducible prefix를 보존했습니다. 이후에는 raw score, subsystem·target reward, exploration bonus, retry penalty와 runtime cost를 이용해 tail shortlist 15개를 다시 계산했습니다. 이 reward는 CVE 가능성이 아니라 남은 조사 예산의 배분값입니다.

6. 모든 session을 동일한 evidence contract로 다시 합쳤습니다

여러 session에서 나온 강한 finding을 단순 합산하지 않았습니다. Structured review는 다음을 요구했습니다.

attacker control

reachability

entrypoint와 sink

repository-relative evidence location

invariant break와 impact

blocking gap과 next action

존재하지 않는 path, placeholder evidence와 schema error는 merge에서 제외했습니다. Tier가 confidence와 session rank보다 먼저 오도록 하고, 같은 것으로 grouping된 review는 가장 강한 representative와 모든 session hit를 함께 보존했습니다.

Repro와 report 단계에서도 model이 artifact directory를 임의로 쓰게 하지 않고, 최종 output을 하네스가 검증한 뒤 structured artifact로 기록했습니다. 생성된 repro는 자동 실행하지 않고 격리 환경에서 사람이 검토했습니다.

7. 후보를 공개 가능한 보안 주장으로 닫았습니다

하네스는 어디를 보고 어떤 가설을 반증할지 제안했습니다. 최종 disclosure에서는 사람이 다음을 다시 확인했습니다.

실제 entrypoint와 attacker-controlled input

existing verifier 또는 authorization check의 부재

positive case와 negative control

affected version, upstream state와 patch

runtime·protocol·memory 또는 trust-boundary impact

maintainer와 공개 시점 및 attribution boundary

보존되지 않은 per-finding mode는 사후에 추정해 특정 session에 귀속하지 않았고, 여러 연구자의 보고가 통합된 결과도 sole discovery로 계산하지 않았습니다.

RESULTS

직접 귀속 공개 CVE 11건

OSS v2 — 3건: CVE-2026-33953, CVE-2026-33954, CVE-2026-34460

Adaptive v3 — 8건: CVE-2026-33398, CVE-2026-33636, CVE-2026-33729, CVE-2026-41429, CVE-2026-45692, CVE-2026-45815, CVE-2026-47391, CVE-2026-48168

별도로 구분한 결과

식별자 부여·upstream publication 대기 3건 — CVE-2026-33546, CVE-2026-33547, CVE-2026-41210. 공개 전 경계를 지키기 위해 기술 세부사항은 적지 않았습니다.

통합 CVE 기여 — 여러 연구자의 보고가 합쳐진 CVE-2026-34584에 authorization-bypass variant 2개를 기여했습니다. sole discovery로 계산하지 않았습니다.

CVE 없는 공개 결과 — Caddy의 GHSA-gx7w-56w6-g48x가 GitHub-reviewed advisory로 공개됐으며 CVE 합계에서는 제외했습니다.

프로젝트가 남긴 것

Kernel v1 공통 기반에서 OSS branch가 갈라진 정확한 Git 계보 복원

OSS v2의 Controlled Signal Comparison에서 Adaptive v3의 Controlled Search Diversity로 이어지는 연구 발전

관련 Docker Codex session 125개와 반복 audit·follow-up·review 기록

직접 귀속 공개 CVE 11건과 공개 책임에 맞춘 attribution boundary

모델의 confidence가 아닌 동일한 structured evidence contract로 여러 탐색 결과를 비교하는 시스템

한계

human-labeled benchmark가 없어 precision·recall 또는 AI 사용 전후의 배수 개선을 주장하지 않습니다.

Python 외 언어의 semantic extraction은 compiler-grade AST·call graph와 동일하지 않습니다.

historical per-finding mode log가 완전하지 않아 각 CVE를 특정 default·nosignal·coldrisk·hotrisk session에 귀속하지 않습니다.

public repository의 current main은 7월 이후 containment·schema·retry·CI hardening을 포함하므로 실제 발견 당시 snapshot과 동일하다고 주장하지 않습니다.

여러 session의 반복 발견이나 heuristic grouping은 unique vulnerability 또는 CVE 수를 의미하지 않습니다.

하네스는 autonomous scanner, novelty oracle 또는 exploit validator가 아니며 최종 proof는 사람의 검증에 의존합니다.

배운 점과 다음 단계

Kernel 단계에서 배운 “Priority is not proof”는 OSS 단계에서 “Diversity is not consensus”로 발전했습니다. 여러 search mode가 같은 후보를 말하더라도 그것은 증명이 아니며, 서로 다른 후보를 말하더라도 같은 evidence contract로 비교해야 합니다.

다음 단계는 더 많은 agent를 실행하는 것이 아니라 untrusted repository를 다루는 identity, filesystem, network egress와 secret boundary를 분리하고, discovery 이후의 reproduction·negative control을 독립 QA 단계로 만드는 것입니다.

전체 기록과 원본

Controlled comparison 구현 — codex-oss-vuln-harness-v2

Adaptive multi-session 구현 — codex-adaptive-oss-vuln-harness

공개 CVE 증거와 재현 자료 — CVE-public

비공개 연구 원본 — Docker Codex session store, campaign artifact와 disclosure 전 자료는 공개 경계를 지키며 별도 보관