왜 Codex Security는 SAST 보고서를 포함하지 않나요

발행: 1개월 전 (2026년 3월 16일 오전 09:00 GMT+9)

15 분 소요

Source: OpenAI Blog

Source: …

정적 애플리케이션 보안 테스트 (SAST) vs. Codex Security

수십 년 동안 정적 애플리케이션 보안 테스트(SAST)는 보안 팀이 코드 리뷰를 확장하는 가장 효과적인 방법 중 하나였습니다.

Codex Security를 구축할 때 우리는 의도적인 설계 선택을 했습니다: 정적 분석 보고서를 가져와 에이전트가 이를 분류하도록 시작하지 않았습니다. 대신, 시스템이 저장소 자체—그 구조, 신뢰 경계, 의도된 동작—에서 시작하도록 설계하고, 사람이 시간을 들여 검토하기 전에 발견한 내용을 검증하도록 했습니다.

왜 전환했나요?

가장 어려운 취약점은 보통 단순한 데이터 흐름 문제는 아닙니다. 코드가 보안 검사를 수행하는 것처럼 보이지만, 그 검사가 시스템이 의존하는 속성을 실제로 보장하지 못할 때 발생합니다. 다시 말해, 문제는 프로그램을 통해 데이터가 어떻게 이동하는지를 추적하는 것뿐만 아니라, 코드 내 방어가 실제로 작동하는지를 판단하는 데 있습니다.

고전적인 SAST 모델

SAST는 종종 깔끔한 파이프라인으로 설명됩니다:

신뢰할 수 없는 입력의 출처를 식별한다.
프로그램을 통해 데이터를 추적한다.
해당 데이터가 정제 없이 민감한 싱크에 도달하는 경우를 표시한다.

우아한 모델이며 많은 실제 버그를 포괄합니다.

하지만 실제로는 SAST가 규모에 맞게 유지되기 위해 근사치를 사용해야 합니다—특히 간접 호출, 동적 디스패치, 콜백, 리플렉션, 프레임워크 중심의 제어 흐름이 많은 코드베이스에서는 더욱 그렇습니다. 이러한 근사치는 SAST에 대한 비판이 아니라, 코드를 실행하지 않고 추론하려는 현실적인 한계입니다.

Note: 이것이 Codex Security가 SAST 보고서로 시작하지 않는 유일한 이유는 아닙니다.

더 깊은 문제: 소스‑투‑싱크 추적 이후

정적 분석이 입력을 여러 함수와 레이어에 걸쳐 올바르게 추적하더라도, 실제로 취약점이 존재하는지를 판단하는 질문에 답해야 합니다.

예시 패턴:

# Pseudocode
sanitize_html(user_input)   # sanitizer runs
render(user_input)          # untrusted content rendered

정적 분석기는 sanitizer가 실행된 것은 확인할 수 있지만, 해당 sanitizer가 특정 렌더링 컨텍스트, 템플릿 엔진, 인코딩 동작 및 이후 변환에 충분한지 여부는 보통 판단하지 못합니다.

핵심 구분:

“코드가 sanitizer를 호출한다.”
“시스템이 안전하다.”

후자는 검사의 효과에 대해 추론해야 하며, 단순히 존재 여부만을 보는 것이 아닙니다.

실제 사례

웹 애플리케이션이 JSON 페이로드를 받아 redirect_url을 추출하고, 허용 목록 정규식으로 검증한 뒤 URL‑디코드하고, 결과를 리다이렉트 핸들러에 전달합니다.

고전적인 소스‑투‑싱크 보고서는 다음과 같습니다:

untrusted input → regex check → URL decode → redirect

실제 질문은 변환이 진행된 후에도 검사가 여전히 값을 제한하고 있는가 입니다.

정규식 검사가 디코딩 전에 실행된다면, 디코딩된 URL에 대해 리다이렉트 핸들러가 해석하는 방식대로 실제로 제한하고 있는가?
이를 답하려면 전체 변환 체인—정규식, 디코딩/정규화, URL 파싱의 엣지 케이스, 리다이렉트 로직—을 모두 고려해야 합니다.

많은 실용적인 취약점이 이와 같습니다: 연산 순서 실수, 부분 정규화, 파싱 모호성, 검증과 해석 사이의 불일치 등. 데이터 흐름은 보이지만, 약점은 제약이 변환 체인을 통해 어떻게(또는 못) 전달되는가에 있습니다.

구체적인 사례:
CVE‑2024‑29041 – Express에서 발생한 오픈‑리다이렉트 이슈로, 잘못된 URL이 일반적인 허용 목록 구현을 우회할 수 있었습니다. 이는 리다이렉트 대상이 인코딩된 후 해석되는 방식 때문이었습니다. 데이터 흐름은 직관적이었지만, 더 어려운 질문—검증이 변환 체인 이후에도 유지되는가—가 버그 존재 여부를 결정했습니다.

Codex Security가 문제를 해결하는 방법

Codex Security는 강력한 증거를 통해 이슈를 드러내어 트리아지를 줄이는 간단한 목표를 중심으로 구축되었습니다. 제품에서는 레포지토리‑특정 컨텍스트(위협 모델 포함)를 사용하고, 높은 신호를 가진 이슈를 격리된 환경에서 검증한 뒤에 표시합니다.

Codex Security가 “검증”이나 “정화”와 같은 경계에 마주칠 때, 이를 체크리스트로 여기지 않습니다. 코드가 보장하려는 것이 무엇인지 이해하려 하고, 그 보장을 반증하려 합니다.

일반적인 워크플로

컨텍스트 기반 코드 읽기
- 보안 연구원이 하는 것처럼 전체 레포지토리 컨텍스트를 활용해 관련 코드 경로를 읽습니다.
- 의도와 구현 사이의 불일치(주석 포함, 다만 모델이 주석을 무조건 신뢰하지는 않음)를 찾습니다.
가장 작은 테스트 가능한 슬라이스 격리
- 변환 파이프라인 주변의 아주 작은 코드 조각을 추출합니다.
- 해당 슬라이스에 대한 마이크로‑퍼저를 작성합니다.
변환 간 제약 조건에 대한 추론
- 검사를 독립적인 게이트가 아니라 체인의 일부로 취급합니다.
- 적절할 경우, 문제를 만족도 질문으로 형식화합니다(예: z3‑solver가 포함된 Python 환경 사용).
- 정수 오버플로우나 아키텍처‑특정 버그에 유용합니다.
샌드박스에서 가설 실행
- 격리된 슬라이스를 샌드박스 검증 환경에서 실행합니다.
- “문제가 될 수 있다”와 “문제이다”를 구분합니다.
- 디버그 모드로 컴파일된 전체 엔드‑투‑엔드 PoC가 가장 강력한 증거를 제공합니다.

핵심 요점

SAST는 데이터가 어디로 흐르는지를 알려줍니다.
Codex Security는 그 데이터를 차단해야 할 제약 조건이 모든 변환 후에도 실제로 유지되는지를 묻습니다.

레포지토리 전체 컨텍스트, 목표 격리, 형식적 추론, 샌드박스 실행을 결합함으로써 Codex Security는 높은 신뢰도의 발견을 제시하고 수동 트리아지 부담을 크게 줄입니다.

핵심 전환

“검사가 존재한다” 에서 멈추는 대신, 시스템은 “불변식이 유지되는지(또는 유지되지 않는지)와 그 증거” 로 나아가야 합니다.
그 후 모델이 해당 작업에 가장 적합한 도구를 선택합니다.

합리적인 반응

왜 둘 다 하지 않을까?
SAST 보고서로 시작하고, 에이전트를 사용해 더 깊이 추론한다.

왜 SAST 보고서에서 시작하면 예측 가능한 실패 모드가 발생하는가

1. 조기 범위 축소

발견 목록은 도구가 이미 살펴본 위치의 지도이다.
이를 시작점으로 삼으면 시스템이 다음으로 편향될 수 있다:
- 동일한 영역에 과도한 노력을 투입한다.
- 동일한 추상화를 재사용한다.
- 도구의 세계관에 맞지 않는 문제 유형을 놓친다.

2. 암묵적이며 풀기 어려운 판단

많은 SAST 발견은 정제, 검증 또는 신뢰 경계에 대한 가정을 내포하고 있다.
그 가정이 잘못됐거나 불완전할 경우, 이를 추론 루프에 넣으면 에이전트가 **“조사”**에서 **“확인 또는 거부”**로 전환되며, 이는 의도된 동작이 아니다.

3. 평가 난이도

파이프라인이 SAST 출력으로 시작하면 다음을 구분하기 어려워진다:
- 에이전트가 자체 분석을 통해 발견한 내용.
- 다른 도구로부터 상속받은 내용.
이 구분은 시스템의 능력을 정확히 측정하고 지속적인 개선을 위해 필수적이다.

우리의 접근 방식: Codex Security

우리는 보안 연구가 시작되는 지점에서 Codex Security를 구축했습니다:

코드와 시스템의 의도에서 시작합니다.
검증은 인간을 중단시키기 전에 신뢰 수준을 높이기 위해서만 사용됩니다.

SAST 도구가 빛을 발할 때

보안 코딩 표준을 적용합니다.
직관적인 소스‑투‑싱크 문제를 포착합니다.
예측 가능한 트레이드‑오프와 함께 대규모로 알려진 패턴을 탐지합니다.
깊이 있는 방어의 강력한 요소가 될 수 있습니다.

이 게시물의 범위

행동을 추론하고 결과를 검증하도록 설계된 에이전트가 정적인 결과 목록에 고정된 상태로 작업을 시작해서는 안 되는 이유에 초점을 맞춥니다.

소스‑투‑싱크 사고를 넘어

모든 취약점이 데이터 흐름 문제는 아니다.
많은 실제 실패는 상태 및 불변 조건 문제이다:
- 워크플로우 우회.
- 권한 부여 결함.
- “시스템이 잘못된 상태에 있다” 버그.

이러한 버그에서는 오염된 값이 단일 “위험한 싱크”에 도달하지 않는다.
위험은 프로그램이 항상 참이라고 가정하는 것에 있다.

앞으로

보안 도구 생태계가 계속 개선될 것으로 기대합니다:

정적 분석
퍼징
런타임 가드
에이전트 기반 워크플로우

모두 역할을 가질 것입니다.

Codex Security가 뛰어나길 바라는 영역

**“이것은 의심스럽다”**를 **“이것은 실제이며, 어떻게 실패하는지, 그리고 시스템 의도에 맞는 해결책”**으로 전환하기

이는 보안 팀에게 가장 비용이 많이 드는 부분이며, Codex Security가 가장 큰 가치를 제공하고자 하는 영역입니다.