Codex Security 변경사항 보안 검토: 병합 전 Changes 스캔과 근거 확인하는 법
TL;DR
병합 직전 보안 점검에서는 어느 변경분을 스캔했는지부터 확정해야 합니다. Codex Security 플러그인의
Security > Scans > + Scan > Changes
에서 미커밋 변경, 최신 커밋, 기준·대상 리비전 중 실제 병합할 범위를 고릅니다. 완료 후 발견 사항만이 아니라 검토 범위와 제외·추가 확인 영역까지 대조합니다.
완료물은
기준 리비전 | 대상 리비전 | 검토 범위 | 발견 사항과 근거 | 미확인 영역 | 담당자 판단
을 기록한 내부 보안 검토본입니다. 스캔 완료나 발견 0건은 병합 승인 또는 저장소 전체 안전성의 증명이 아닙니다. 코드 변경과 병합은 별도 사람 승인 뒤에 진행합니다.
핵심 3줄 요약
핵심 1
Changes to review
에서 미커밋 파일·최신 커밋·리비전 범위 중 실제 병합 대상과 일치하는 하나를 선택합니다.
핵심 2
결과의 대상 리비전·검토 범위·누락 영역과 개별 코드 위치·입력 경로·검증 근거를 맞춰 봅니다.
핵심 3
새 커밋이 생기면 이전 스캔 결과를 최종 변경분의 판단으로 재사용하지 않습니다. 수정과 병합은 사람이 별도 승인합니다.
이 글에서 다룰 내용
Codex Security Changes 스캔의 정의와 접근 조건, 세 가지 Git 범위의 차이, 데스크톱 앱에서 시작하는 순서, 대화에서 쓸 복사 프롬프트, 발견 사항·coverage 대조, 공유와 병합 전 승인 경계를 순서대로 설명합니다.
Codex Security Changes 스캔이란
Git 변경사항 보안 검토에서 먼저 답할 질문은 “취약점이 있는가”보다 “어느 변경을 검토했는가”입니다. 작업 중인 파일, 마지막 커밋, 브랜치 전체 변경분은 서로 다른 대상입니다. 범위를 잘못 선택하면 스캔이 정상적으로 끝나더라도 정작 병합할 코드가 빠질 수 있습니다.
Codex Security의 Changes 스캔은 하나의 Git 변경 집합에서 보안 회귀를 찾습니다. 변경된 소스 성격의 파일과 직접 관련된 코드를 검토하지만 저장소 전체를 감사하지는 않습니다. 전체 저장소 점검이 필요하면 별도 Codebase 스캔을 선택해야 합니다. 변경 스캔에서는 Deep scan을 사용할 수 없습니다.
PR 설명에는 문구 수정만 적혔는데 실제 차이에 세션 처리 코드가 있을 수 있습니다. 설명만 믿고 범위를 줄이지 마세요. 검토 사본의 Git 차이와 스캔 설정을 나란히 확인하세요.
언제 쓰면 좋은가
인증·인가·입력 처리·파일 접근·외부 네트워크 요청처럼 보안상 중요한 경로를 바꾼 PR이나 커밋의 병합 전 내부 검토에 적합합니다. 공식 문서는 미커밋 변경, 단일 최신 커밋, 기준·대상 리비전 사이를 별도 선택지로 설명합니다.
이 글의 목적은 스캔 결과를 내부 리뷰어에게 넘길 수 있는 근거 기록으로 만드는 것입니다. 제안 패치 적용, 공개 취약점 보고, 이슈 트래커 발행, CI 필수 체크 전환, 실제 병합은 첫 완료 범위에서 제외합니다.
시작 전 조건과 변경 범위
소유하거나 평가 허가를 받은 비민감 테스트 저장소를 준비합니다. ChatGPT 데스크톱 앱에서 Codex를 열고 Codex Security 플러그인을 설치·활성화해야 Security 작업 화면을 열 수 있습니다. Codex CLI에서는
/plugins
에서 설치한 뒤 대화의 diff-scan 요청을 사용할 수 있습니다. 별도 Codex Security Cloud 플러그인은 연결된 GitHub 저장소를 스캔하는 다른 경로이므로 여기의 로컬 Changes 화면과 섞지 않습니다.
공식 빠른 시작 문서는 플러그인 설치와 활성화 여부를 확인하도록 안내합니다. 실제 사용 가능 여부는 로그인한 계정, 워크스페이스의 플러그인 허용 상태와 현재 화면에서 다시 확인하세요. 특정 요금제·지역의 제공 여부를 이 글에서 추정하지 않습니다.
현재 체크아웃된 저장소, 브랜치, 최신 커밋을 스캔 전에 기록합니다. 여러 커밋을 묶은 PR이라면 최신 커밋 한 건 대신 로컬에 존재하는 기준·대상 리비전을 준비합니다. 이 기록은 스캔이 무엇을 다뤘는지 되돌아볼 내부 기준이며 제품이 병합 적합성을 자동 승인한다는 뜻은 아닙니다.
병합 전 Changes 스캔 6단계
1. 저장소와 변경 기준을 고정합니다
허가받은 테스트 저장소의 브랜치와 병합 대상 차이를 사람이 먼저 확인합니다. 검토 기록에 기준·대상 리비전과 변경 파일을 적습니다. 코드·로그·테스트 데이터에 비밀키나 개인정보가 포함되지 않았는지도 살핍니다.
미커밋 상태, 최신 커밋, 브랜치 전체 중 검토 대상을 정합니다. 스캔한 Git 범위가 병합 대상과 다르면 결과가 있어도 검토를 마친 게 아닙니다.
2. Security에서 Changes를 엽니다
ChatGPT 데스크톱 앱에서 Codex를 연 다음 Security > Scans > + Scan에서 저장소를 선택하고
Changes
를 고릅니다.
Changes to review
에서 Uncommitted changes, 최신 커밋, 또는 기준·대상 리비전 범위 중 하나를 선택합니다.
현재 체크아웃된 저장소·브랜치·최신 커밋이 예상한 항목인지 봅니다. 제품 도움말상 이 단계에서 Codex가 다른 브랜치를 자동으로 체크아웃하거나 선택한 작업 트리를 바꾸지는 않습니다.
3. 요약과 리비전을 대조해 스캔을 시작합니다
설정 요약이 실제 변경 집합을 가리키는지 확인한 뒤 Start scan을 누릅니다. 요청 리비전이 로컬에 없으면 공식 문서는 미리 가져오거나 로컬에서 사용할 수 있는 기준·대상 리비전을 쓰라고 안내합니다.
이 글은 원격 저장소 접근이나
git fetch
실행을 자동으로 맡기지 않습니다. 저장소 접근과 필요한 리비전의 반입은 조직 절차에 따라 별도 승인합니다.
4. 완료 결과의 범위와 coverage를 읽습니다
완료된 스캔에서 저장소·리비전·대상 범위를 먼저 대조합니다. 실제 검토 영역, 보류되거나 후속 확인이 필요한 영역을 확인한 뒤
Findings
를 읽습니다. 진행 중인 중간 후보나 완료 표시 하나만으로 합격을 판정하지 않습니다.
보안 작업 화면은 저장된 스캔과 발견 사항을 보여줍니다. 구조화 산출물
scan-manifest.json
과
coverage.json
을 확인할 수 있다면 각각 대상·리비전 정보와 검토·보류 범위를 대조합니다. 파일이 보이지 않으면 UI의 범위와 후속 확인 영역을 기록하세요. 없는 산출물을 만든 것처럼 쓰지 않습니다.
5. 발견 사항을 코드와 근거에 대조합니다
지목된 파일·줄·현재 리비전, 공격자가 제어하는 입력, 검증 방법, 남은 불확실성, 실제 영향 경로를 하나씩 확인합니다. 위험도 표시는 우선순위를 정하는 자료일 뿐, 취약점의 존재나 수정안의 적절성을 단독 증명하지 않습니다.
요청 경로를 조합하는 코드가 바뀌었다고 경로 탐색 취약점이 확정되지는 않습니다. 입력이 문제 지점까지 도달하는지, 앞단에서 차단되는지 확인하세요. 근거가 부족하거나 테스트 환경에서 재현되지 않으면 확인 필요로 남깁니다.
6. 내부 검토본과 사람 승인 지점을 남깁니다
기준·대상 리비전 | 변경 파일 | 검토·누락 영역 | 발견 사항 ID와 코드 위치 | 검증 근거 | 상태 | 승인자
를 내부 기록에 적습니다. 이 표는 저자가 제안하는 검토 양식이며 Codex Security의 자동 승인 기능이 아닙니다.
수용한 발견 사항은 별도 변경 요청에서 한 건씩 수정·검증합니다. 수정으로 새 커밋이 생기면 최종 변경분에 대한 새 검토 범위를 다시 지정해야 합니다. 이 글의 완료는 내부 검토본까지이며 패치 반영·외부 공개·최종 병합은 사람 승인 뒤에 결정합니다.
복사해 쓰는 검토 프롬프트
Codex Security 플러그인이 설치된 대화에서 검토 목적을 전달할 때 쓰는 예시입니다. 대괄호를 승인받은 저장소의 비민감 정보로 바꾸세요. 공식 문서의
security-diff-scan
호출 표현을 따르되, 아래 검토표 형식과 승인 지점은 저자가 제안하는 내부 업무 규칙입니다.
목표: Use $codex-security:security-diff-scan to review changes from [로컬 기준 리비전] to [로컬 대상 리비전] for security regressions. 병합 전 내부 검토만 수행하세요.
허용 입력: 허가된 비민감 Git 저장소 한 곳, 로컬에 존재하는 두 리비전, 실제 변경 파일과 승인된 보안 검토 기준만 사용하세요.
제외 입력: 외부 저장소, 자격증명, 고객 데이터, 비공개 취약점 기록, 승인되지 않은 원격 다운로드와 외부 전송은 제외하세요.
출력 형식: 기준·대상 리비전 | 검토된 변경 범위 | 보류 범위 | 발견 사항 ID·코드 위치 | 입력 경로 | 검증 근거 | 불확실성 | 검토 상태의 내부 표로 정리하세요.
완료 기준: 스캔 대상을 실제 병합 변경분에 대조할 수 있어야 합니다. 각 발견 사항에 코드 근거와 후속 확인 항목이 적혀 있으면 끝냅니다.
추정 금지: 근거 없는 취약점 확정, 전체 저장소 검사 완료, 발견 0건이면 안전 보장, 테스트 통과·병합 승인 완료를 꾸며내지 마세요.
승인 지점: 코드 수정, 원격 접근, 외부 공유, 이슈 등록과 병합은 수행하지 말고 담당자의 별도 승인을 기다리세요.
실무 인사이트
마지막 커밋 스캔과 브랜치 전체 스캔은 다릅니다. 여러 커밋의 PR에서 한 커밋만 골라 생기는 검토 누락은 발견 사항이 0건인 것보다 먼저 해결해야 합니다. 스캔 대상·검토 영역·코드 근거를 따로 표시하면 어느 판단이 새 코드에 해당하는지도 분명해집니다.
완료된 스캔과 새로운 커밋의 리비전이 다르면 결과를 최신 코드의 증거로 사용할 수 없습니다. 사람은 범위를 다시 지정하고 보류된 영역을 검토해야 합니다. 저장소 전체의 기준선이 필요하면 Changes가 아니라 Codebase 스캔을 별도로 계획하세요.
주의할 점
Changes 스캔은 변경된 소스 성격의 파일과 직접 관련 코드를 보지만 저장소 전체를 빠짐없이 검토하지 않습니다. Deep scan을 Changes에 결합할 수도 없습니다. 대상 Git 리비전과 누락 영역을 기록하지 않은 발견 0건은 안전성 보장이 아닙니다.
스캔 산출물에 취약점 세부, 코드 위치와 재현 자료가 담길 수 있습니다. 내부 권한이 확인된 사람에게만 결과를 보여주고 외부 공유·공개 취약점 제보·이슈 생성은 따로 승인합니다. 플러그인 설치, 실제 코드 스캔, 원격 저장소 조작 및 병합을 이 글을 작성하면서 실행하지는 않았습니다.
자주 묻는 질문
Q1. Changes 스캔이 저장소 전체를 검사하나요?
아닙니다. 공식 문서는 하나의 Git 변경 집합과 직접 관련된 코드를 검토한다고 설명합니다. 전체 저장소 기준선은 별도 Codebase 스캔으로 다뤄야 합니다.
Q2. 여러 커밋의 PR은 최신 커밋만 선택해도 되나요?
병합 대상 전체가 여러 커밋이라면 기준·대상 리비전 범위를 고릅니다. 최신 커밋 한 건의 요약과 실제 병합 변경 집합이 같은지 먼저 확인하세요. 필요한 리비전은 로컬에서 사용할 수 있어야 합니다.
Q3. 발견 사항이 0건이면 병합해도 안전한가요?
그렇지 않습니다. 검사 범위와 보류·제외 영역을 확인해야 합니다. 발견 사항이 없다 해도 범위 밖 코드나 실제 운영 환경의 동작이 검증된 것은 아닙니다.
Q4. 스캔 뒤 새 커밋이 생기면 어떻게 하나요?
기존 결과의 리비전과 최종 병합 대상이 다른지 비교합니다. 다르면 최종 변경분을 다시 검토하고 코드·테스트 근거를 사람이 확인한 뒤 병합을 결정하세요. 이 글의 스캔만으로 패치나 병합이 자동 승인되지는 않습니다.
출처
마무리
Codex Security의 변경 스캔은 병합을 대신 결정하는 기능이 아닙니다. 실제 Git 범위 선택 → 결과의 coverage 확인 → 발견 사항의 코드 근거 대조를 내부 검토본에 남기세요. 수정과 병합은 담당자의 별도 승인으로 넘깁니다.
감자나라 AI 강의보기 5,000 
