ChatGPT Pro·Enterprise·Business·Edu
Codex Security, 18%가 전부라는 공식 수치가 있습니다
OpenAI가 120만 커밋을 스캔해 취약점 1만 건을 발견했다고 발표했습니다. 숫자만 보면 압도적입니다. 그런데 같은 시기 나온 Semgrep 벤치마크는 정반대 분위기를 전합니다. 정탐률 18%이고, XSS·SQL Injection 탐지는 0건이었다고요. 둘 다 공식 자료입니다. 이 두 숫자를 같이 놓고 봐야 Codex Security가 진짜 무엇인지 보입니다.
Codex Security란 무엇이고 어디서 쓸 수 있나
Codex Security는 OpenAI가 2026년 3월 6일 공개한 AI 기반 애플리케이션 보안 에이전트입니다. 코드 저장소를 분석해 취약점을 찾고, 샌드박스에서 재현한 뒤, 수정 코드까지 제안하는 세 단계로 작동합니다. 원래 Aardvark라는 이름으로 2025년 10월 비공개 베타를 돌렸고, 이번에 Codex Security라는 이름으로 리서치 프리뷰 상태로 공개됐습니다.
현재 ChatGPT Pro, Enterprise, Business, Edu 플랜에서 쓸 수 있고, 출시 후 1개월간은 무료 사용 구간이 있습니다. 무료 티어나 ChatGPT Plus 플랜에서는 쓸 수 없습니다. 공식 문서는 developers.openai.com/codex/security에 있고, 오픈소스 프로젝트는 별도 신청 링크를 통해 접근할 수 있습니다.
Codex CLI와 Codex 웹 앱을 통해 접근하며, 두 경로 모두 동일한 보안 에이전트 루프를 사용합니다. 단, 이 글 기준(2026.03.23)은 여전히 리서치 프리뷰이고, 지원하는 언어 생태계와 프레임워크 커버리지가 전부 완성된 상태는 아닙니다.
SAST를 버린 이유 — 공식 문서에 나온 3가지 실패 패턴
기존 보안 도구의 왕좌는 SAST(정적 분석)였습니다. 소스 입력을 추적해서 위험한 출구에 닿는지 확인하는 방식인데, 빠르고 확장성이 좋아서 CI/CD 파이프라인에 붙이는 게 업계 표준이었습니다. OpenAI는 2026년 3월 16일 공식 문서를 통해 Codex Security가 SAST 리포트를 시작점으로 삼지 않는다고 직접 설명했습니다.
💡 공식 발표문과 실제 에이전트 작동 흐름을 같이 놓고 보니 SAST를 쓰지 않는 이유가 더 명확하게 보였습니다.
- 첫째, 탐색 범위가 미리 좁혀집니다. SAST 리포트는 이미 그 도구가 본 영역의 지도입니다. 에이전트가 거기서 시작하면 SAST가 애초에 들여다보지 않은 영역을 놓칩니다.
- 둘째, 검증이 이뤄지지 않은 판단이 그대로 넘어옵니다. SAST 결과에는 “이 구간이 안전하다”는 암묵적 가정이 섞여 있습니다. 그 가정이 틀렸어도 에이전트는 그대로 이어받습니다.
- 셋째, 에이전트 자체의 실력을 측정할 수 없어집니다. SAST 결과와 에이전트 분석이 섞이면, 어느 쪽이 취약점을 찾아낸 건지 분리가 안 됩니다. 시스템이 개선되려면 이 두 가지를 명확히 구분해야 합니다.
OpenAI가 제시한 구체적 예시가 있습니다. CVE-2024-29041, Express.js의 오픈 리다이렉트 취약점입니다. 데이터 흐름만 보면 URL을 허용목록 정규식으로 검증하고 리다이렉트하는 깔끔한 코드입니다. 그런데 정규식 검증 이후에 URL 디코딩이 일어나고, 그 디코딩된 값이 리다이렉트 핸들러로 넘어갑니다. SAST는 “검증 단계가 존재한다”고 보고하지만, 검증이 디코딩 이후에도 유효한지는 확인하지 못합니다. 실제로 이 순서 오류가 악용됐고 CVE가 났습니다. (출처: OpenAI 공식 블로그, 2026.03.16)
120만 커밋·1만 건이 말해주지 않는 것
OpenAI 공식 발표 수치입니다. 베타 기간 30일 동안 외부 저장소 120만 커밋을 스캔했고, 치명적 취약점 792건, 고위험 취약점 10,561건을 탐지했습니다. 같은 기간 오탐률은 50% 이상 감소했고, 과대 보고된 심각도 분류는 90% 이상 줄었습니다. (출처: OpenAI 공식 블로그, codex-security-now-in-research-preview, 2026.03.06)
💡 OpenAI 수치와 독립 벤치마크 수치를 나란히 두고 보니 보이지 않던 간극이 드러났습니다.
OpenAI 발표에서 “792건+10,561건 탐지”는 실제 취약점인지 확인된 건수가 아니라, 에이전트가 플래그를 세운 총 건수입니다. 오탐률 50% 감소는 이전 버전 대비 비율이지, 현재 오탐이 0에 가깝다는 뜻이 아닙니다. 공식 문서에서 별도 정탐률 수치를 따로 밝히지 않았습니다.
Semgrep이 2025년 9월 실시한 독립 벤치마크가 이 공백을 채워줍니다. 실제 Python 웹 애플리케이션 11개(Django·Flask·FastAPI)를 대상으로 Codex(v0.2.0, o4-mini 기반)를 돌렸을 때 전체 정탐률은 18%였습니다. 400건 이상의 탐지 결과를 모두 수동 검토한 수치입니다. OpenAI가 스스로 발표한 대규모 스캔 결과와 독립적으로 측정된 정탐률을 같이 봐야 하는 이유가 바로 이것입니다. 10,561건 중 같은 비율을 적용하면 실제 취약점은 약 1,900건 수준으로 추정됩니다. 여전히 상당한 숫자지만, 표제 숫자와는 다릅니다.
정탐률 18%의 구조 — 왜 XSS·SQL Injection이 0건인가
Semgrep 벤치마크 데이터를 취약점 유형별로 쪼개면 편차가 극단적입니다. 경로 순회(Path Traversal)는 47%로 선방했지만, XSS, SQL Injection, IDOR(객체 직접 참조)는 정탐률이 0%였습니다. 전체 28건의 XSS 탐지 결과 중 올바른 건 단 한 건도 없었습니다. (출처: Semgrep Research, September 2025)
| 취약점 유형 | Codex 정탐률 | Claude Code 정탐률 |
|---|---|---|
| 인증 우회 (Auth Bypass) | 13% (5/37) | 10% (6/58) |
| 객체 직접 참조 (IDOR) | 0% (0/5) | 22% (13/59) |
| 경로 순회 (Path Traversal) | 47% (8/17) | 13% (5/36) |
| SQL Injection | 0% (0/5) | 5% (2/38) |
| SSRF | 34% (8/23) | 12% (8/65) |
| XSS | 0% (0/28) | 16% (12/74) |
출처: Semgrep Research, 2025년 9월. Codex v0.2.0 (o4-mini), Claude Code v1.0.32 (Sonnet 4), Python 웹 앱 11개 기준.
Semgrep은 이 결과의 원인을 “절차 간 오염 흐름(inter-procedural taint flow) 추론의 한계”로 짚었습니다. SAST가 구조적으로 약한 지점이 AI 에이전트에도 그대로 남아 있다는 뜻입니다. XSS와 SQL Injection은 정확히 이 오염 흐름을 추적해야 탐지되는 유형입니다. 두 클래스가 동시에 0건이라는 건 우연이 아닙니다.
추가로 Semgrep은 비결정성 문제를 지적했습니다. 같은 코드베이스에 동일한 프롬프트를 3회 반복 실행했을 때, 탐지 건수가 3건, 6건, 11건으로 매번 달랐습니다. 취약점 관리 시스템에서 “이전에 없던 결과”를 수정 완료로 해석하면 잘못된 판단으로 이어질 수 있습니다.
AI 코딩 에이전트가 공통으로 놓치는 취약점 패턴
DryRun Security가 2026년 3월 Codex(GPT-5.2 기반), Claude Code(Sonnet 4.6 기반), Gemini(2.5 Pro 기반)를 같은 조건에서 비교했습니다. 30개 풀 리퀘스트 중 26개에서 취약점이 하나 이상 발견됐습니다. 87%입니다. 이건 AI가 만든 코드의 위험도를 보여주는 수치입니다.
💡 세 에이전트를 동시에 같은 조건으로 비교하니, 도구와 관계없이 반복되는 공통 실패 패턴이 드러났습니다.
- WebSocket 인증 누락: REST 인증 미들웨어는 세 에이전트 모두 정확하게 연결했습니다. 그런데 WebSocket 업그레이드 핸들러에 그 미들웨어를 연결하지 않았습니다. 세 에이전트 전부 동일한 패턴입니다.
- 클라이언트 신뢰 오류: 게임 점수·잔액 등 민감한 값을 클라이언트에서 받아서 서버 측 검증 없이 처리했습니다. 비즈니스 로직 레이어의 구조적 문제입니다.
- OAuth CSRF 및 2FA 우회: OAuth state 파라미터가 모든 소셜 로그인 구현에서 빠져 있었고, Claude Code에서는 2FA 비활성화 우회 경로가 단독으로 발견됐습니다.
이 패턴이 의미하는 건 간단합니다. AI 에이전트는 코드 패턴을 보고 구현하지, 보안 정책이 전체 연결 유형에 적용됐는지를 검토하지 않습니다. REST 인증은 정책 준수처럼 보이지만, 동일 정책이 WebSocket에도 필요하다는 인식은 에이전트의 체크리스트에 없습니다. 이건 Codex Security의 탐지 단계 문제가 아니라, AI가 코드를 작성하는 방식의 문제입니다. (출처: DryRun Security Research, 2026.03)
지금 당장 쓸 수 있는 조건과 실제 접근 방법
Codex Security를 쓰려면 ChatGPT Enterprise, Business, Edu, 또는 Pro 플랜이 필요합니다. 현재(2026년 3월 기준) 1개월 무료 사용 구간이 열려 있습니다. 접속은 Codex 웹 앱을 통해 합니다. CLI 경로도 있고, GitHub 저장소를 직접 연동하는 방식으로 작동합니다.
실제로 쓸 만한 상황과 그렇지 않은 상황이 나뉩니다. 메모리 안전 문제나 경로 순회처럼 구조적으로 보이는 취약점은 탐지율이 의미 있는 수준(47%까지)입니다. 반면 XSS·SQL Injection 등 오염 흐름 추적이 필요한 유형은 현 단계에서 Codex Security에 의존하는 건 위험합니다. 결과를 그대로 신뢰하기보다 “이 부분을 한 번 더 확인하라”는 신호로 활용하는 게 현실적입니다.
그리고 한 가지 실용적인 포인트가 있습니다. OpenAI는 SAST를 버린 게 아니라 시작점으로 삼지 않겠다고 했습니다. 기존 SAST 도구와 병렬로 돌리는 게 오히려 더 촘촘한 커버리지를 줍니다. Codex Security는 SAST가 놓치는 논리·상태·불변식 문제를 겨냥하고, SAST는 알려진 패턴과 오염 흐름을 잡습니다. 두 도구는 경쟁하지 않고 보완합니다.
Q&A
Codex Security는 무료로 쓸 수 있나요?
리서치 프리뷰 출시 후 1개월간 ChatGPT Pro·Enterprise·Business·Edu 플랜에서 무료 사용이 가능합니다. 무료 플랜이나 Plus 플랜에서는 현재 지원하지 않습니다. 오픈소스 프로젝트는 별도 신청을 통해 무료 접근 경로가 있습니다.
SAST 도구를 쓰고 있다면 Codex Security로 교체해야 하나요?
교체보다 병행이 맞습니다. OpenAI 공식 문서도 SAST가 알려진 패턴 탐지에 효과적임을 인정하고 있습니다. Codex Security는 SAST가 구조적으로 접근하기 어려운 논리·상태 취약점을 대상으로 합니다. 두 도구를 함께 쓰면 커버리지가 더 넓어집니다.
18% 정탐률이면 쓸 가치가 있나요?
유형에 따라 다릅니다. 경로 순회(47%)나 SSRF(34%) 같은 구조적 취약점에서는 충분히 의미 있는 수치입니다. 반면 XSS·SQL Injection은 현 단계에서 Codex Security 단독으로 커버하기 어렵습니다. 결과를 “확정된 취약점”이 아닌 “검토 필요 신호”로 처리하면 실용적입니다.
Codex Security가 찾은 CVE는 실제로 패치됐나요?
GnuTLS, GnuPG, GOGS, Thorium 등 오픈소스 프로젝트에서 발견된 CVE들이 실제로 CVE 데이터베이스에 등록됐습니다. GnuPG의 CVE-2026-24881, CVE-2026-24882 등은 공식 CVE 레코드에서 확인 가능합니다. 수정 패치가 함께 제안됐으며, 각 프로젝트 측에서 반영 여부를 결정합니다.
Codex Security와 Claude Code Security 중 어느 쪽이 나은가요?
Semgrep 벤치마크 기준으로 전체 정탐률은 Codex 18%, Claude Code 14%로 Codex가 소폭 높지만, IDOR 탐지에서는 Claude Code가 22%로 Codex(0%)를 압도했습니다. 어느 쪽이 낫다고 단정하기 어렵고, 두 도구가 잘 잡는 취약점 유형이 달라서 상호 보완적으로 사용하는 방향이 현실적입니다.
마치며
Codex Security는 지금까지 보안 도구가 건드리지 못했던 논리·상태 레벨 취약점에 접근한다는 점에서 방향이 맞습니다. 120만 커밋 스캔이라는 규모도 허세가 아닙니다. 실제로 CVE가 나왔고, 오픈소스 프로젝트의 취약점을 잡아냈습니다.
다만 18%라는 정탐률, XSS·SQL Injection 0건이라는 유형별 편차, 그리고 같은 코드를 돌릴 때마다 결과가 달라지는 비결정성 문제는 지금 당장 보안의 전부를 맡기기에 넘어야 할 산이 있다는 걸 보여줍니다. AI가 만든 코드의 87%에서 취약점이 발견됐다는 DryRun 수치까지 포함하면, Codex Security는 도구 이전에 AI 코딩 자체의 보안 공백을 메우는 작업이기도 합니다.
솔직히 말하면, 지금 단계에서 가장 실용적인 사용법은 SAST와 함께 돌리는 겁니다. 둘이 보는 곳이 다르기 때문에, 겹치게 하는 게 손해가 아닙니다.
본 포스팅 참고 자료
- OpenAI 공식 블로그 — Codex Security Research Preview (openai.com/index/codex-security-now-in-research-preview, 2026.03.06)
- OpenAI 공식 블로그 — Why Codex Security Doesn’t Include SAST (openai.com/index/why-codex-security-doesnt-include-sast, 2026.03.16)
- The Hacker News — OpenAI Codex Security Scanned 1.2 Million Commits (thehackernews.com, 2026.03.07)
- AdwaitX — OpenAI Codex Security No SAST Report (adwaitx.com, 2026.03)
- DryRun Security Research — AI Agent Security Study, 2026.03
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 이 글은 2026년 3월 23일 기준으로 작성됐으며, Codex Security는 현재 리서치 프리뷰 상태로 정식 출시 이후 수치와 기능이 달라질 수 있습니다. 모든 보안 판단은 반드시 공식 문서와 전문가 검토를 병행하세요.
댓글 남기기