AI 코드 리뷰 도입 가이드: Codex Security 설정부터 CI 연동까지

DevDay 이후 Codex 보안 기능은 어디까지 지원하나요?

Codex Security는 저장소, PR, 개발자의 작업 사본이라는 세 지점에서 취약한 코드를 찾습니다. 건물 전체 점검, 리모델링 계획 검토, 작업자가 현장을 떠나기 전 확인에 비유할 수 있습니다. 같은 시스템을 살펴보되, 각 단계에서 보는 범위가 다릅니다.

PR, 즉 풀 리퀘스트는 검토를 기다리는 코드 변경 제안입니다. CLI는 터미널에서 실행하는 명령줄 툴이고, CI는 코드가 바뀔 때 자동으로 검사를 실행하는 과정입니다.

Cloud는 컴퓨터가 꺼져 있어도 발견 사항을 조사하고, 중복을 제거하며, 수정안을 준비합니다. OpenAI는 여전히 이 제품을 연구 프리뷰로 분류합니다. 9월 29일 DevDay 발표는 예약 스캔과 이용 가능 범위에 관한 정보를 추가한 것이며, Cloud가 정식 출시 제품으로 전환됐다는 뜻은 아닙니다. DevDay 발표 요약, 현재 제품 상태.

GitLab을 쓰는 팀은 CLI부터 시작하는 편이 좋습니다. 현재 Security Cloud는 GitHub에 연결하는 방식으로 설정합니다. 일반 Codex가 GitLab 머지 리퀘스트를 지원한다고 해서 Security Cloud도 GitLab을 지원하는 것은 아닙니다. 별도의 GitLab CI/CD 가이드는 이 환경에서 보안 검사를 실행할 수 있는 지원 방식을 안내합니다.

어떤 요금제로 이용할 수 있고, 다섯 명이면 얼마나 드나요?

발표 날짜가 명시된 DevDay 공지와 현재 도움말 센터에 따르면 Pro, Business, Enterprise, Edu에서 Codex Security Cloud를 이용할 수 있습니다. Security Review도 같은 요금제를 지원하며, Plus는 명시적으로 제외합니다. 워크스페이스 권한과 저장소 접근 권한은 별도로 활성화해야 합니다. Cloud 이용 가능 범위, Security Review 이용 조건.

소규모 회사라면 Standard Business 다섯 좌석을 기준으로 구독 비용을 비교할 수 있습니다.

토큰 기반 요금은 모델이 읽고 생성하는 양에 따라 결정됩니다. 좌석 가격은 국가와 통화에 따라 달라질 수 있습니다. 위 구독료 계산은 현재 Business FAQ를 따릅니다. Cloud의 현재 과금 안내에 따르면 기존 고객은 유료 사용이 시작되기 전에 통지를 받고, 직접 동의해야 합니다. 사용료가 확보되지 않으면 스캔은 중단됩니다. 다섯 명의 스캔 비용까지 모두 포함한 견적은 제시하지 않습니다. Cloud 과금 안내, 구독료와 API 요금의 차이.

이미 Business를 이용 중이라면 좌석을 추가하는 비용은 없을 수도 있습니다. 그래도 스캔과 보안 검토 사용량은 예산에 반영해야 합니다. 월 총비용은 좌석 구독료에 해당하는 Cloud 사용료, API로 실행하는 CI 스캔 비용, 러너 실행 비용, 선택 사항인 보안 대시보드 구독료를 더한 금액입니다.

첫 달 무료 혜택이 다시 제공된다고 가정해 예산을 잡아서는 안 됩니다. 무료 사용 혜택은 3월 6일 출시 당시 제공됐고, 그다음 한 달에 적용됐습니다. 현재 제품 및 과금 페이지에서는 9월 30일에 이 혜택이 다시 제공된다는 근거를 확인할 수 없습니다. 최초 출시 조건, 현재 과금 조건.

가격 비교 기준으로 보면 Semgrep의 유료 Code 제품은 기여자당 월 $30이며, 다섯 명이면 $150입니다. Free Edition도 저장소 최대 10개, 기여자 최대 10명을 지원합니다. 따라서 다섯 명으로 구성된 팀은 기존 스캐너를 이용하려면 반드시 구매해야 한다고 전제하지 않고 두 제품을 평가할 수 있습니다. 검사 범위가 서로 다르므로, 가격만으로 보안 툴 구성을 결정해서는 안 됩니다. Semgrep 요금.

저장소 하나를 연결하고 수정안 검토까지 진행하기

팀이 잘 아는 애플리케이션과 그 애플리케이션의 접근 규칙을 설명할 수 있는 검토자로 시작합니다. 위협 모델은 애플리케이션이 무엇을 보호하는지, 누가 접근할 수 있는지, 어디서 다른 시스템을 신뢰하는지 간단히 정리한 문서입니다. 점검자에게 어느 문이 잠겨 있어야 하는지 알려주는 건물 도면과 같습니다.

1. 데스크톱 또는 웹의 ChatGPT에서 **플러그인(Plugins)**을 엽니다. Codex Security Cloud를 설치하고 활성화한 뒤 Security Cloud를 엽니다.
2. **새 스캔(New scan)**을 선택합니다. 연결 요청이 나오면 GitHub를 연결하고, 검사할 저장소의 접근 권한을 부여합니다.
3. 저장소와 호환되는 **Cloud 환경(Cloud environment)**을 선택합니다. 필요하면 프로젝트에 필요한 의존성과 테스트 설정을 갖춘 환경을 만듭니다.
4. **스캔 대상(What to scan)**에서 **저장소(Repository)**를 선택하고 **스캔 시작(Start scan)**을 누릅니다. **스캔 목록(Scans)**에서 진행 상황을 확인합니다.
5. **발견 사항(Findings)**을 엽니다. 영향을 받는 코드, 검증 근거, 수정 지침을 읽습니다. 검증 시도가 실패했다면 아직 근거를 확인하지 못한 상태이지, 취약점이 없다고 판정된 것이 아닙니다.
6. **Codex로 수정(Fix with Codex)**이 제공되면 패치를 생성하고 검토한 뒤 **초안 PR 생성(Create draft pull request)**을 사용합니다. 병합 전에는 평소의 테스트를 실행하고 코드 담당자를 검토에 참여시킵니다.

이 절차는 현재의 Cloud 설정 화면을 기준으로 합니다. 환경을 갖추면 의심되는 결함을 재현하기가 더 수월해지지만, 모든 문제를 검증할 수 있다는 보장은 없습니다. 검증 방식.

지속적인 검사를 설정하려면 **커밋 변경 사항(Commit changes)**으로 별도의 스캔을 만듭니다. **저장소 목록(Repositories)**에서 **모니터링 설정(Monitoring settings)**을 열고 환경과 이력 범위를 지정한 뒤, 모니터링을 활성화하거나 일시 중지합니다. 아키텍처가 바뀌면 **프로젝트 맥락(Project context)**에서 위협 모델을 수정합니다. DevDay에서 소개한 것처럼 Cloud는 예약된 저장소 스캔도 지원합니다. 다만 현재 설정 가이드에는 예약 주기나 할당량이 명시돼 있지 않으므로, 매일 스캔할 수 있는 할당량이 있다고 가정할 수는 없습니다. 모니터링 설정, 예약 스캔.

실제 스캔 사례: Gogs 취약점의 우선순위 판단하기

Gogs 사례는 발견 사항을 작업 티켓으로 옮기기 전에 배포 환경을 확인해야 하는 이유를 보여줍니다. OpenAI는 공개한 Codex Security 발견 사례에 이 저장소와 아래 취약점을 포함합니다. 이 사례는 제공사가 공개한 스캔 결과이며, 이 글을 위해 새로 실행한 스캔이 아닙니다. 아래의 분류와 대응 판단은 유지관리자의 보안 권고를 바탕으로 한 제안입니다. OpenAI가 공개한 발견 사항.

CVE 번호는 공개된 취약점을 식별합니다. 이중 인증, 즉 2FA는 비밀번호 외에 로그인 확인 단계를 하나 더 둡니다.

첫 번째 권고는 수정 버전을 0.13.4와 0.14.0+dev로, 두 번째 권고는 0.14.0으로 명시합니다. 이는 과거 권고에서 확인된 최초 수정 버전이지, 지금 오래된 릴리스를 선택하라는 권고가 아닙니다. 업그레이드하기 전에 프로젝트에서 현재 지원하는 릴리스를 확인해야 합니다. Gogs 복구 코드 보안 권고, Gogs 업로드 보안 권고.

분류 기록은 간결하게 유지합니다. 배포된 리비전, 접근 가능한 진입점, 근거, 담당자, 조치, 수정 여부를 확인할 테스트를 남깁니다. 발견 사항은 유효한 문제로 받아들이거나, 구체적인 이유를 명시해 제외하거나, 추가 조사를 위해 미해결 상태로 둘 수 있습니다. 변경된 동작을 검증한 뒤에만 수정 완료로 표시합니다.

자체 스캔에도 같은 원칙을 적용합니다. CLI가 저장하는 보고서에는 발견 사항과 검사 범위가 기록됩니다. 다음 스캔에서 이전 발견 사항이 보이지 않는다고 해서 수정됐다는 증거가 되지는 않습니다. 오탐 피드백을 제출해도 해당 취약점 유형이 영구적으로 제외되는 것은 아닙니다. 발견 이력과 피드백.

AI 코드 리뷰: PR 자동 보안 검토 설정하기

초기 저장소 평가를 마쳤다면 PR 검토를 다음 단계로 추가합니다. **Codex 설정(Codex settings)**에서 저장소를 선택합니다. 보안 취약점 검토(Review security vulnerabilities) 아래의 **자동 보안 검토(Auto security review)**를 켜고 **모든 PR(All PRs)**을 선택합니다. 원하는 사람부터 도입하려면 개인별 설정을 사용합니다.

PR이 열릴 때 처음 검토하려면 PR 생성 시(On PR open), 코드가 바뀔 때마다 반복 검토하려면 **푸시할 때마다(On every push)**를 선택합니다. 일반 Code Review와 함께 실행하려면 **코드 검토가 실행될 때마다(Whenever code review runs)**를 선택합니다. 기존 Security Cloud 스캔은 필수가 아닙니다. 스캔의 위협 모델을 재사용하거나 저장소 내 위협 모델 파일 경로를 지정할 수 있습니다. Security Review 설정.

자동 검토는 기본적으로 High와 Critical 발견 사항을 보고합니다. 수동으로 요청한 검토는 기본값에 Medium도 포함합니다. 두 기준은 각각 변경할 수 있습니다. 수동 검토를 요청하려면 PR에 @codex security review 댓글을 남기고, 연결된 작업의 **보안 보고서(Security Report)**에서 전체 근거를 확인합니다. GitHub에 게시된 발견 사항의 공개 범위는 해당 PR의 공개 범위를 따릅니다.

이 기능은 보안에 집중하는 검토입니다. 일반 Code Review도 보안 문제를 지적할 수 있으므로 일부 결과는 겹칠 수 있습니다. 더 넓은 범위를 다루는 Codex 리뷰 가이드를 참고하면 각 검토를 어느 단계에 배치할지 판단하는 데 도움이 됩니다.

로컬 작업과 커밋 전 검사를 위한 CLI 설치하기

CLI는 저장소를 조사하는 같은 유형의 기능을 스크립트에서 실행할 수 있게 제공합니다. 소스 라이선스는 Apache 2.0이며, 공개 npm 패키지는 @openai/codex-security입니다. 소스가 공개돼 있다고 해서 제한 없이 스캔할 수 있는 권한까지 포함되는 것은 아닙니다. 공식 소스와 라이선스, CLI 이용 전제 조건.

Cloud에 포함된 Daybreak Blue 모델 이용 권한은 Cloud 안에서만 적용됩니다. 다른 Security 제품이나 API에서 그 모델을 이용할 권한까지 주지는 않습니다. CI로 스캔을 옮기기 전에 사용할 로그인 방식과 모델 접근 권한을 확인해야 합니다. 제품별 이용 권한 범위.

날짜도 구분해서 봐야 합니다. GitHub 저장소는 2026년 7월 13일에 생성됐습니다. 현재 공개 이력은 7월 15일 초기화 커밋으로 시작하며, npm 배포 이력은 7월 28일부터입니다. 7월 13일이라는 날짜만으로 해당 라이선스의 npm CLI가 그날 배포됐다고 단정할 수는 없습니다. 재현 가능한 설정을 만들려면 패키지 버전을 고정합니다. 저장소 메타데이터, 초기 커밋, npm 배포 이력.

Node.js는 22 계열의 22.13.0 이상, Node 24 또는 Node 26을 사용하고, Python은 3.10 이상을 준비합니다. 저장소에서 로그인한 뒤, 결과는 체크아웃 디렉터리 밖에 저장합니다.

npx @openai/codex-security@0.1.31 login
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results --dry-run
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results

report.md, findings.json, coverage.json을 검토합니다. 검사 범위는 전체 완료, 일부 완료, 확인 불가로 표시될 수 있습니다. 발견 사항이 없더라도 검사가 보류된 영역과 아직 답을 찾지 못한 질문을 읽어야 합니다. 위 명령은 CLI 빠른 시작 가이드를 따릅니다.

커밋 전 검사는 npx @openai/codex-security@0.1.31 install-hook으로 설치합니다. 스테이징한 변경과 스테이징하지 않은 변경을 모두 검사하며, 기본적으로 High 발견 사항과 스캔 오류가 있으면 커밋을 차단합니다. 기존 pre-commit 스크립트는 보존합니다. 두 종류의 변경을 모두 보기 때문에 결과를 해석할 때는 작업 사본에 관련 없는 실험 코드를 섞어 두지 않는 편이 좋습니다. 훅 동작 방식.

위 패키지 버전과 명령은 이 글을 준비하는 과정에서 확인했습니다. 인증 후 로컬 스캔을 실행했다거나, 스캔 소요 시간 또는 비용을 측정했다는 주장은 하지 않습니다.

CI에서 CLI를 실행하고 SARIF 보고서 보관하기

SARIF는 보안 발견 사항을 담는 표준 파일 형식입니다. 다른 툴에서도 각 문제를 해당 소스 위치와 함께 표시할 수 있습니다. 파일을 내보내는 일과 호스팅형 대시보드를 구매하는 일은 별도로 결정합니다.

필요한 스캔 이용 권한을 갖춘 계정 또는 API 조직의 키를 CODEX_SECURITY_API_KEY라는 이름의 CI 시크릿으로 만듭니다. 이 키가 있으면 러너가 대화형 ChatGPT 로그인 없이 인증할 수 있습니다. 아래 GitHub Actions 예제는 같은 저장소에서 올라온 신뢰할 수 있는 PR을 스캔합니다. 정확한 베이스와 헤드를 비교하고, SARIF를 내보내며, 결과를 보관합니다. 공식 CI 템플릿을 응용해 이 글에서 확인한 패키지 버전을 고정하고, High 심각도를 차단 기준으로 설정했습니다. 처음에는 결과만 알리는 방식으로 도입하려면 --fail-on-severity high를 제거합니다. 그래도 스캔 오류와 불완전한 검사 범위는 확인해야 합니다.

.github/workflows/codex-security.yml로 저장합니다.

name: Codex Security
on:
  pull_request:
jobs:
  security:
    if: github.event.pull_request.head.repo.full_name == github.repository && github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020
        with:
          node-version: '26'
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
        with:
          python-version: '3.14'
      - name: Install trusted CLI outside the checkout
        run: npm install --prefix "$RUNNER_TEMP/security-cli" --ignore-scripts --no-audit --no-fund @openai/codex-security@0.1.31
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
          persist-credentials: false
      - name: Scan and export
        env:
          OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
          CODEX_SECURITY_STATE_DIR: ${{ runner.temp }}/security-state
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          set -euo pipefail
          cli="$RUNNER_TEMP/security-cli/node_modules/.bin/codex-security"
          out="$RUNNER_TEMP/security-results"
          base="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
          scan_exit=0
          "$cli" scan . --diff "$base" --head "$HEAD_SHA" \
            --auth api-key --output-dir "$out" \
            --fail-on-severity high --json \
            > "$RUNNER_TEMP/security-result.json" || scan_exit=$?
          if test -f "$out/scan-manifest.json"; then
            "$cli" export "$out" --export-format sarif \
              --source-root "$GITHUB_WORKSPACE" \
              --output "$out/results.sarif"
          fi
          exit "$scan_exit"
      - name: Keep reports, including SARIF when available
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
        with:
          name: codex-security-results
          path: |
            ${{ runner.temp }}/security-results
            ${{ runner.temp }}/security-result.json
          retention-days: 7

이 워크플로는 스캔 종료 코드를 유지하면서, 봉인 처리된 결과 중 내보낼 수 있는 결과를 내보냅니다. 종료 코드 0은 선택한 범위의 검사가 완료됐고 심각도 정책을 통과했다는 뜻입니다. 종료 코드 1은 기준에 해당하는 발견 사항이 있다는 뜻입니다. 종료 코드 2는 오류가 발생했거나 검사 범위가 불완전하다는 뜻이며, 일부만 검사했거나 범위를 확인할 수 없는 경우도 포함합니다. 결과만 알리는 스캔이 성공으로 표시되더라도, 선택한 범위에 대한 보고서일 뿐 보안 인증서는 아닙니다. 아티팩트 내보내기와 종료 코드.

SARIF를 GitHub 코드 스캐닝 알림으로 표시하려면 공식 템플릿의 upload-sarif 단계와 필요한 권한을 추가합니다. 공개 저장소는 지원되며, 비공개 및 내부 저장소에는 GitHub Code Security가 활성화돼 있어야 합니다. 위 예제처럼 SARIF를 아티팩트로 보관하면 비공개 저장소용 대시보드가 무료라고 전제하지 않고도 내용을 확인할 수 있습니다. GitHub의 SARIF 이용 조건.

GitLab에서는 OpenAI의 프로덕션 CI/CD 템플릿을 사용합니다. 이 템플릿은 머지 리퀘스트 변경분 검사, 보호된 기본 브랜치 스캔, 선택적으로 활성화하는 예약 스캔을 다룹니다. GitLab의 기본 SARIF 수집 기능을 이용하려면 GitLab Ultimate 19.2 이상이 필요합니다. 해당 대시보드 이용 권한이 없다면 일반 보고서 아티팩트를 별도 방식으로 활용할 수 있습니다.

CI 작업은 러너의 권한으로 실행되며 러너 환경을 상속할 수 있습니다. 작업에 관련 없는 자격 증명을 넣지 말고, 신뢰할 수 있는 소스 변경에 사용합니다. 예산을 정한 뒤에는 --max-cost 값을 추가합니다. 이는 추정 비용 제한이므로 이미 진행 중인 요청 때문에 한도를 초과할 수 있습니다. CI 전제 조건, 비용 제어.

기대 효과 순으로 살펴보는 다섯 가지 활용 사례

1. 로그인이나 테넌트 접근 방식을 바꾸는 SaaS 팀. 기준 스캔을 실행하고, 위협 모델을 보완하며, 해당 PR에 Security Review를 활성화합니다. 고객이 문제를 겪기 전에 계정 간 접근 경계의 오류를 발견할 가능성을 높일 수 있습니다. 인증 담당자를 검토에 계속 참여시킵니다.
2. 오래된 애플리케이션을 인수한 창업자. 기능을 추가하기 전에 저장소를 한 번 스캔하고, 유효하다고 판단한 발견 사항을 담당자에게 배정합니다. 무엇이 있는지 모르는 백로그를 전면 재작성 요청으로 넘기는 대신, 근거가 있는 작업의 짧은 목록으로 정리할 수 있습니다.
3. 관리형 보안 스캐너가 없는 GitLab 팀. 머지 리퀘스트 변경분에 CLI 검사를 실행하고 SARIF와 검사 범위를 아티팩트로 보관합니다. 이미 운영하는 CI 안에서 반복 가능한 검토 기록을 남길 수 있습니다.
4. 여러 고객의 저장소를 유지보수하는 에이전시. CLI의 중단 후 재개 가능한 일괄 스캔을 활용하고, 고객별로 아키텍처 맥락과 발견 이력을 구분합니다. 반복 설정을 줄이고 유지보수 인수인계를 더 정확하게 만들 수 있습니다. 일괄 스캔.
5. 기존 보안 백로그에 불필요한 알림이 많은 팀. Codex Security의 백로그 분류 워크플로로 스캐너 결과를 현재 코드 및 보안 통제와 대조합니다. 어떤 티켓에 개발 시간을 써야 하는지 판단할 근거를 얻을 수 있습니다. 기존 스캐너는 계속 실행합니다. 백로그 분류.

이 기능을 바탕으로 만들 수 있는 두 가지 서비스

가장 유망한 기회는 소규모 팀의 보안 도입과 지속적인 운영을 맡는 서비스입니다. 창업자가 비용을 지불하는 대상은 스캔 버튼을 감싼 또 하나의 제품보다, 초기 설정과 위협 모델 작성, CI 연동, 정기적인 사람의 검토입니다.

이번 조사에서 DataForSEO의 미국 Google 추정치는 “software vulnerability scanning”의 월 검색량을 720회, “code security scanner”의 월 검색량을 90회로 제시했습니다. 검색 횟수는 돈을 낼 고객 수가 아니며, 더 넓은 의미의 첫 번째 검색어에는 저장소 스캔 외의 작업도 포함됩니다. 기여자 다섯 명 기준 월 $150인 Semgrep Code 가격은 범위를 좁힌 서비스의 구체적인 비교 기준이 됩니다. Semgrep 가격 비교 기준.

판매 가능한 최소 구성으로는 고객이 소유한 저장소 하나, 문서화한 위협 모델, CI 워크플로, 검토를 마친 발견 사항 목록을 묶을 수 있습니다. 고객의 접근 권한으로 작업하고 사용료를 명확하게 보여줍니다. 어려운 부분은 운영입니다. 잘못된 판단을 유도하는 발견 사항을 걸러 내고 민감한 수정안을 검토할 만큼 애플리케이션을 이해해야 합니다. 보안을 보장한다고 판매하면 근거가 뒷받침하는 범위를 넘어섭니다.

두 번째 기회는 에이전시를 위한 릴리스 검증 자료 패키지입니다. 고객에게 작업을 인계할 때마다 날짜를 명시한 스캔 범위, 유효하다고 판단한 발견 사항, 남은 검사 공백, 검증을 마친 수정 내역을 제공할 수 있습니다. 범위가 넓은 검색어인 “vulnerability scanning tools”의 미국 월 검색량 추정치는 1,900회입니다. 다만 이는 여러 보안 분야의 툴에 대한 관심을 측정한 값입니다. 고객 탐색을 시작할 가설은 뒷받침하지만, 바로 이 제품에 대한 수요를 입증하지는 않습니다.

MVP는 저장된 스캔 아티팩트와 승인된 분류 결과를 모아 간결한 고객 보고서를 만드는 형태가 될 수 있습니다. 어려운 부분은 이식성과 신뢰입니다. SARIF 파일은 다른 환경으로 옮길 수 있어도, 사업의 가치는 불완전한 검사 범위까지 솔직하게 해석하는 데서 나옵니다. 생성된 보고서만으로는 쉽게 모방할 수 있습니다. 모든 검색량은 2026년 9월 30일에 조회한 DataForSEO의 월간 키워드 추정치이며, 어느 수치도 시장 성장이나 구매 의도를 입증하지 않습니다.

함께 유지해야 할 보안 검사와 사람의 역할

애플리케이션이 가져오는 패키지와 버전을 확인하는 의존성 스캔, 노출된 자격 증명을 탐지하는 시크릿 스캔은 유지합니다. 저장소를 추론하는 과정에서 관련 문제를 조사할 수는 있지만, 전체 패키지 목록 관리나 자격 증명 모니터링을 대신하지는 않습니다.

넓은 범위의 반복 가능한 검사나 보증 요건이 중요하다면, 정해진 규칙을 일관되게 적용하는 SAST도 유지합니다. OpenAI는 Codex Security가 SAST를 보완한다고 명시합니다. 유료 제품을 사지 않고도 에이전트를 시험해 볼 수 있지만, 그렇다고 기존 검사 범위가 불필요해지는 것은 아닙니다. Cloud FAQ.

인가 코드는 사람이 계속 검토해야 합니다. 인증은 사용자가 누구인지 확인하고, 인가는 어느 고객의 데이터나 작업에 접근할 수 있는지 판단합니다. 이런 규칙에는 스캐너가 잘못 이해할 수 있는 업무 의도와 배포 환경의 전제가 반영됩니다. 담당자가 테넌트 간 경계, 관리자 권한, 계정 복구 흐름, 회귀 테스트를 검토하도록 합니다. 이는 사람이 위협을 평가해야 한다는 제공사의 설명에 부합하는 엔지니어링 권고입니다.

스캔 환경의 접근 범위도 제한합니다. Cloud는 격리된 컨테이너를 사용하지만, 로컬 및 CI 스캔은 실행 환경의 로컬 권한을 사용합니다. 에이전트가 어디에 접근할 수 있는지 통제하는 별도 작업은 샌드박스 보안 가이드에서 다룹니다.

Codex와 Claude Code 보안 검토, 무엇을 선택할까요?

당장 필요한 것이 대기 중인 변경 사항의 보안 검사이고 팀이 이미 Claude Code를 사용한다면, 그대로 활용합니다. 로컬에서 /security-review를 실행하거나, PR 댓글과 오탐 필터링을 위해 Anthropic의 security-review GitHub Action을 설정합니다. 이 기능은 유료 Pro/Max 및 API Console 계정을 포함한 Claude Code 사용자에게 제공됩니다. Claude 보안 검토 설정.

관리형 저장소 기준 스캔, 커밋 모니터링, 예약 스캔, 미리 준비된 수정안이 필요한 워크플로라면 Codex Security Cloud를 선택합니다. 저장된 발견 이력, 검사 범위 아티팩트, SARIF 내보내기가 로컬 또는 CI 프로세스에 잘 맞는다면 CLI를 선택합니다. 이 비교로 정확도나 비용의 우위를 판단할 근거는 없습니다.

어느 구성을 쓰든 필터 정책을 확인합니다. Anthropic의 security-review Action 문서에는 서비스 거부와 자원 고갈 등이 제외 대상으로 명시돼 있습니다. 따라서 Gogs 업로드 사례처럼 디스크 고갈이 우려되는 경우에는 해당 정책을 의식적으로 검토해야 합니다. 이 Action은 Claude의 호스팅형 Code Review 제품과는 별개의 기능입니다. Anthropic의 security-review 저장소.

월요일에는 저장소 하나에 담당자 한 명을 지정합니다. 기준 스캔을 실행하고 위협 모델을 바로잡은 뒤, 처음 나온 발견 사항을 분류합니다. 심각도에 따른 차단 기준을 정하기 전에 결과만 알리는 CI 검사를 추가합니다. 다른 저장소로 확대하기에 앞서 사용료와 아직 해결되지 않은 검사 공백을 기록합니다.

팀의 기존 개발 프로세스에 이 구성을 연결하는 작업이 필요하다면, 프로덕션 AI 시스템 구축을 맡아 진행합니다.