OpenAI, Codex Security는 SAST findings list보다 behavior 검증에서 출발해야 한다고 설명

OpenAI가 말하는 SAST-first 접근의 한계

OpenAI는 March 16, 2026 공개한 글에서 Codex Security가 의도적으로 SAST report를 시작점으로 삼지 않는다고 설명했다. 회사에 따르면 실제 repository에서 중요한 취약점 상당수는 단순 source-to-sink dataflow보다 validation logic, canonicalization order, trust boundary, business invariant가 어긋날 때 나타난다.

OpenAI는 이를 설명하기 위해 URL path를 decode하기 전에 allowlist regex로 검사하는 패턴을 예로 들었다. source 형태에서는 정책이 안전해 보일 수 있지만 URL decoding 이후에는 전혀 다른 값이 되면서 open redirect 같은 문제가 생길 수 있다는 설명이다. 회사는 이런 failure mode가 Express의 CVE-2024-29041에서 드러난 미묘한 logic bug와 같은 부류라고 짚었다.

Codex Security는 어떻게 repository를 본다고 하나

OpenAI에 따르면 Codex Security는 먼저 repository를 읽고, 코드가 지켜야 할 intended security property와 architecture를 파악한다. 그 다음 의심 구간을 작고 testable한 단위로 좁히고, 필요하면 micro-fuzzers를 작성하며, sandboxed environment에서 hypothesis를 검증한다. 또한 Python environment에서 z3-solver 같은 도구를 사용해 edge case를 더 엄밀하게 따질 수 있다고 설명했다.

OpenAI는 SAST가 무의미하다고 주장하지는 않았다. secure coding standard enforcement와 known pattern detection에는 여전히 가치가 있다고 했다. 다만 agent를 처음부터 SAST findings list에 묶어두면 search space가 잘못된 abstraction에 고정되고, 잘못된 가정을 그대로 가져오며, 무엇을 실제로 독립적으로 찾아냈는지 평가하기도 어려워진다는 것이 핵심 주장이다.

이 글은 agentic security tooling의 방향을 보여준다. 대규모 repository를 autonomous하게 review하겠다는 제품이 늘고 있지만, 실제 품질 차이는 scanner output을 요약하느냐, 아니면 adversarial input 아래의 behavior를 직접 확인하느냐에서 갈린다. OpenAI는 Codex Security를 기존 scanner 결과 요약기가 아니라 hypothesis-driven security investigator에 가깝게 포지셔닝하고 있다.

• Codex Security는 설계상 SAST report에서 시작하지 않는다.
• 핵심은 repository behavior, intended security property, executable test 검증이다.
• OpenAI는 SAST가 policy enforcement와 known pattern detection에는 여전히 유용하다고 본다.
• 회사는 agent가 스스로 발견하고 검증한 결과로 평가받아야 한다고 주장한다.

출처: OpenAI