OpenAI, Codex Security가 SAST 리포트로 시작하지 않는 이유 설명

OpenAI는 2026년 3월 16일 Codex Security의 설계 원칙을 설명하는 글을 공개하며, 이 제품이 static application security testing(SAST) 리포트를 먼저 불러와 분류하는 방식으로 시작하지 않는다고 밝혔다. 회사 설명에 따르면 Codex Security는 repository 자체를 읽고, architecture와 trust boundary, 그리고 코드가 의도한 동작을 먼저 이해한 뒤 실제 취약점 가설을 검증하는 agent로 설계됐다. 목표는 사람이 검토해야 할 의심 사례를 많이 나열하는 것이 아니라, 높은 신뢰도의 finding만 올려서 AppSec triage 비용을 낮추는 데 있다.

OpenAI의 핵심 논지는 중요한 취약점 상당수가 단순한 source-to-sink 문제로 환원되지 않는다는 점이다. 글에서는 코드가 security check를 호출하는 것처럼 보여도 그 check가 시스템이 기대하는 속성을 실제로 보장하지 못하는 사례를 강조했다. 예시로는 web application이 redirect_url 값을 allowlist regex로 검사한 뒤 URL-decode를 수행하고 redirect handler에 넘기는 패턴이 제시됐다. 이 경우 데이터 흐름 자체는 쉽게 보이지만, decode와 normalization, parsing 이후에도 원래의 제약이 유지되는지가 진짜 보안 질문이라는 설명이다. OpenAI는 Express의 CVE-2024-29041을 이런 유형의 현실 사례로 언급했다.

그래서 Codex Security는 behavior를 먼저 보고 그다음 검증하는 구조를 택했다. OpenAI에 따르면 시스템은 repository 전체 문맥에서 관련 code path를 읽고, 의심 구간을 작은 testable slice로 줄여서 살펴보며, 필요하면 micro-fuzzer를 작성한다. 복잡한 constraint 문제에는 Python 환경의 z3-solver 같은 도구를 활용할 수 있고, 가능할 때는 sandboxed validation 환경에서 실제로 가설을 실행해 본다. 회사는 이 과정을 통해 “문제일 수 있다”와 “실제로 재현되는 문제다”를 구분하는 것이 가장 비용이 큰 보안 작업이며, Codex Security는 სწორედ 그 지점을 최적화하려 한다고 설명했다.

OpenAI는 이 접근이 SAST 자체를 부정하는 것은 아니라고 분명히 했다. SAST는 secure coding standard를 강제하고, 예측 가능한 source-to-sink 계열 bug와 알려진 패턴을 대규모로 찾는 데 여전히 유용하며 defense-in-depth의 일부라는 입장이다. 다만 Codex Security를 SAST finding 목록에서 출발시키면 탐색 범위가 너무 빨리 좁아지고, sanitization과 validation, trust boundary에 대한 기존 도구의 가정을 그대로 이어받을 수 있으며, agent가 스스로 찾아낸 내용을 평가하기도 어려워진다고 본다. 이번 설명은 Codex Security를 기존 scanner의 wrapper가 아니라, 복잡하고 맥락 의존적인 취약점을 repository 문맥에서 reasoning하고 검증하는 layer로 포지셔닝한 셈이다.