Codex Security 오픈소스 공개: 설치보다 먼저 확인할 접근권한과 CI 기준

2026. 7. 29 (수) · 약 12분

보안 스캐너가 오픈소스로 공개됐다는 소식을 보면 곧바로 저장소에 설치해 보고 싶어진다. 하지만 Codex Security는 소스 코드와 CLI·TypeScript SDK가 공개된 것, 실제 스캔 서비스를 사용할 수 있는 것이 같은 의미가 아니다. 패키지는 내려받을 수 있어도 현재 스캔 기능은 제한된 베타 접근권한이 필요하다. 결과 파일에는 소스 코드 일부와 취약점 재현 정보가 들어갈 수 있고, 한 번의 스캔에서 발견 항목이 사라졌다고 문제가 해결됐다고 단정할 수도 없다. 설치 명령보다 접근조건, 결과 보관 위치, 불완전한 검사 판정, CI 실패 기준을 먼저 정해야 하는 이유다.

오늘의 핵심뉴스

심층 분석 · OpenAI Codex Security · 2026. 7. 29

OpenAI, Codex Security CLI·SDK 오픈소스 공개

OpenAI는 보유하거나 평가 권한이 있는 코드에서 보안 문제를 찾고 검증하는 Codex Security의 CLI와 TypeScript SDK를 Apache 2.0 라이선스로 공개했다. npm 패키지 0.1.1과 로컬 스캔·결과 내보내기·검증·패치·CI 연동 기능을 확인할 수 있지만, 실제 스캔은 현재 제한된 베타 접근권한이 필요하고 1.0 전 공개 API는 마이너 버전에서도 바뀔 수 있다.

무엇이 공개됐나: CLI·SDK·실행 환경을 직접 볼 수 있다

공개 저장소에는 Codex Security CLI와 TypeScript SDK, Dockerfile과 강화된 일괄 스캔용 Compose 예시, 보안 프로필이 포함돼 있다. 라이선스는 Apache 2.0이며 npm의 @openai/codex-security 패키지는 7월 28일 0.1.1이 배포됐다. CLI에서는 한 저장소 스캔뿐 아니라 기존 스캔 목록·비교, 발견 항목 검증, 패치 생성, SARIF·CSV·JSON 내보내기, pre-commit 훅과 일괄 스캔 기능을 제공한다.

여기서 오픈소스의 의미는 설치 과정과 클라이언트 동작, 자동화 인터페이스를 검토하고 팀 흐름에 맞게 연결할 수 있다는 것이다. 보안 분석 모델과 스캔 서비스 전체가 로컬 프로그램으로 바뀌었다는 뜻은 아니다. 공식 문서는 현재 CLI와 SDK를 제한된 베타로 안내하며, 승인된 접근권한이 있어야 스캔을 실행할 수 있다고 설명한다.

공개된 것과 별도로 확인해야 하는 조건

구분	현재 확인 가능한 범위	주의할 점
소스와 라이선스	GitHub 저장소와 Apache 2.0 라이선스	서버 측 스캔 서비스 공개와는 다름
설치 패키지	npm CLI·TypeScript SDK 0.1.1	1.0 전에는 마이너 버전에서도 API 변경 가능
실제 스캔	계정 로그인 또는 API 키 인증	인증과 별도로 승인된 베타 접근권한 필요
자동화	CI·SARIF·검증·패치·일괄 스캔	저장소 권한과 결과 보관 정책을 먼저 결정

GitHub 소스와 npm 패키지는 공개돼 누구나 확인할 수 있지만, 실제 스캔 실행은 별도의 베타 접근권한과 계정 로그인 또는 API 키 인증을 모두 확인해야 한다.

설치 전에 확인할 것: 접근권한과 실행 환경

공식 요구사항은 macOS·Linux·Windows와 Node.js 22 이상이다. 스캔과 결과 내보내기에는 Python 3.10 이상도 필요하며 Python 3.10 환경에서는 tomli가 추가로 필요할 수 있다. 인증은 OpenAI 계정 로그인이나 API 키를 사용할 수 있다. 환경 변수의 OPENAI_API_KEY 또는 CODEX_API_KEY가 저장된 로그인보다 우선하므로, 로컬에서 예상하지 않은 조직 키로 실행되지 않는지도 확인해야 한다.

접근권한이 없다면 패키지 설치와 로그인에 성공해도 스캔 단계에서 막힐 수 있다. 이 경우 권한을 넓혀 가며 우회하기보다 공식 베타 접근 여부를 먼저 확인해야 한다. 조직 저장소를 시험할 때는 소유하거나 평가 허가를 받은 코드만 대상으로 삼고, API 키는 개인 셸 기록이나 저장소 설정 파일에 남기지 않는다.

node --version
python3 --version
npm install @openai/codex-security
npx codex-security login

# 실제 비용과 범위를 확인하는 준비 단계
npx codex-security scan ./my-repo \
  --output-dir "$HOME/codex-security-results/my-repo" \
  --dry-run

대상과 예상 범위를 dry-run으로 확인한 뒤 산출물을 저장소 밖의 비공개 폴더에 보관한다. findings·report·coverage를 함께 검토하고 수정 뒤에는 원래 발견 항목을 validate로 다시 확인한다.

728x90

 

결과 파일은 왜 저장소 밖에 둬야 하나

기본 산출물에는 사람이 읽는 report.md, 실행 조건을 기록한 scan-manifest.json, 구조화된 findings.json과 coverage.json, 발견 항목별 증거가 담긴 artifacts 폴더가 포함된다. 이 파일에는 소스 코드 일부, 취약점 세부 정보, 재현 단계가 들어갈 수 있다. 공식 문서가 출력 디렉터리를 스캔 대상 저장소나 worktree 밖에 두고 비공개로 관리하라고 권하는 이유다. 공개 CI 아티팩트나 장기 보관 로그에 그대로 올리면 보안 검사가 새로운 정보 유출 경로가 될 수 있다.

주요 산출물과 검토 목적

산출물	확인 내용	보관 원칙
report.md	사람이 읽는 요약과 발견 항목	저장소 밖 비공개 폴더
findings.json	자동화에 쓸 구조화된 발견 정보	접근권한과 보존기간 제한
coverage.json	검사 범위가 complete·partial·unknown인지	발견 수와 함께 보존
artifacts/	증거·소스 발췌·재현 정보	가장 민감한 자료로 취급
SARIF	코드 스캐닝 시스템 연동	업로드 대상과 공개 범위 확인

발견 항목이 사라져도 수정 완료는 아니다

AI 기반 스캔은 같은 저장소를 반복해도 결과가 달라질 수 있다. 두 번째 스캔에서 발견 항목이 보이지 않는다는 사실만으로 수정됐다고 판단하면 안 된다. 먼저 coverage.json에서 검사가 complete인지 확인하고, partial이나 unknown이면 미검사 영역을 남긴 결과로 읽어야 한다. 수정 전 발견 항목을 기준으로 validate를 실행하고, 필요하면 이전·현재 스캔을 match와 compare로 연결해 같은 문제인지 판별한다.

# 수정 전후 스캔을 비교하고 원래 발견 항목을 재검증
npx codex-security scans list
npx codex-security scans match <before-scan> <after-scan>
npx codex-security scans compare <before-scan> <after-scan>
npx codex-security validate <finding-path>

CI는 보고서만 남기는 단계에서 시작해 오탐·시간·비용을 관찰하고, 결과가 안정된 저장소에만 심각도 차단을 적용한다. 비밀값을 받을 수 없는 fork와 Dependabot 실행은 별도 분기로 처리한다.

CI는 보고서 모드에서 시작해 차단 기준을 올린다

처음부터 모든 PR을 보안 결과 하나로 실패시키면 오탐과 긴 실행시간 때문에 우회 규칙이 먼저 늘 수 있다. 공식 CI 가이드도 초기에는 보고서 전용으로 시작해 결과와 커버리지, 비용을 관찰한 뒤 --fail-on-severity를 추가하는 단계를 제시한다. API 키는 GitHub Secrets에 CODEX_SECURITY_API_KEY로 저장하고 작업 안에서 CODEX_API_KEY로 전달한다. fork PR과 Dependabot에는 일반 비밀값이 제공되지 않으므로 조건문으로 건너뛰거나 신뢰된 별도 검토 흐름을 둔다.

• checkout에는 persist-credentials: false를 사용하고 스캔 도구는 저장소 바깥의 신뢰된 위치에 설치한다.
• PR 전체 저장소보다 merge-base 기준 diff부터 시작해 실행시간과 검토 범위를 관리한다.
• 결과 폴더는 runner 임시 디렉터리에 두고 아티팩트 보존기간과 열람 권한을 짧게 설정한다.
• 초기에는 보고서와 SARIF만 남기고 사람이 오탐·누락·커버리지를 검토한다.
• 반복 실행이 안정된 저장소에만 --fail-on-severity 기준을 추가한다.
• exit 1의 정책 위반과 exit 2의 입력·실행 오류 또는 불완전 검사를 서로 다른 실패로 알린다.

Codex Security가 기존 보안 검사를 대신할까

의존성 취약점 목록, 비밀값 탐지, 정적 규칙처럼 빠르고 결정적으로 확인할 수 있는 검사를 없앨 이유는 없다. Codex Security는 저장소의 구조와 실행 흐름을 더 넓게 읽고 발견 항목을 검증·설명하는 층으로 두는 편이 현실적이다. 패키지 감사와 SAST가 알려진 패턴을 빠르게 걸러내고, AI 기반 스캔이 복합적인 맥락을 추가로 살피며, 사람 검토가 실제 악용 가능성과 수정 우선순위를 결정하는 구조다.

보안 스캔의 발견 수보다 먼저 볼 것은 어디까지 검사했고, 무엇을 검사하지 못했으며, 결과를 누가 검증했는가이다.

도입 판단은 기능 목록보다 운영 조건에서 시작해야 한다. 베타 접근권한이 있는가, 저장소 밖에 비공개 결과 폴더를 둘 수 있는가, partial·unknown 커버리지를 실패와 구분할 수 있는가, 결과의 민감도를 감당할 수 있는가, 오탐을 검토할 담당자가 있는가를 먼저 묻는다. 다섯 질문에 답한 뒤 보고서 전용 스캔을 한 번 실행하면, 새 도구를 쓸 수 있는지보다 우리 팀이 그 결과를 책임 있게 운영할 수 있는지가 보인다.

참고한 자료

• openai/codex-security공식
• Codex Security CLI quickstart공식 문서
• Run Codex Security in CI공식 문서
• Codex Security TypeScript SDK공식 문서
• OpenAI가 Codex Security를 오픈소스로 공개함독립 자료

함께 읽기

이어서 보면 좋은 글

• AI 모델 평가가 운영망을 넘었다면: 샌드박스에 추가해야 할 4가지 경계AI 보안 도구의 실행 환경과 운영 자산 사이에 필요한 권한·네트워크·비밀값 경계를 이어서 점검할 수 있다.
• Dependabot 3일 쿨다운: 일반 업데이트와 보안 업데이트 차이, 설정법까지새 보안 도구를 추가해도 의존성 업데이트와 결정적인 CI 검사를 함께 유지해야 하는 이유를 연결해 볼 수 있다.

Codex Security의 공개가 주는 가치는 새 보안 도구 하나를 즉시 필수 검사로 추가했다는 데 있지 않다. CLI와 SDK가 열리면서 스캔 준비, 결과 구조, 검증과 패치, CI 정책을 팀의 작업 흐름에 맞게 연결할 수 있게 됐다는 데 있다. 다만 베타 접근권한, 변경될 수 있는 API, 민감한 산출물, 불완전한 커버리지와 반복 실행 차이를 함께 관리해야 한다. 처음에는 보고서만 남기고 사람이 결과를 검토한 뒤, 오탐과 실행시간이 안정된 저장소부터 심각도 기준을 적용하는 순서가 안전하다.

직접 확인해보려면도입하려는 저장소 하나에서 출력 폴더를 저장소 밖으로 정하고 dry-run과 preflight만 먼저 실행해 접근권한·대상 범위·결과 보관 경로를 확인한다.