Codex Security 결과 내보내기: 보안 스캔을 증거 파일로 남기는 방법 | DAKER 커뮤니티

Codex Security 결과 내보내기: 보안 스캔을 증거 파일로 남기는 방법

DAKER 코덱스 Codex Security 결과 내보내기 대표 만화 카드

Codex Security 스캔 결과를 화면 확인에서 증거 파일 보존으로 넘기는 흐름.

DAKER 코덱스 Codex 보안 스캔 JSON CSV SARIF 내보내기 워크플로

findings workspace 검토부터 JSON, CSV, SARIF 내보내기와 승인 후 이슈 추적까지의 5단계.

Codex Security 결과 내보내기는 보안 스캔 결과를 report.md, 구조화 파일, JSON/CSV/SARIF 같은 재검토 가능한 산출물로 보존하는 작업입니다. 2026년 6월 기준 OpenAI 문서는 완료된 스캔이 findings workspace와 구조화 파일을 만들고, 필요하면 JSON, CSV, SARIF로 내보낼 수 있다고 설명합니다. 지금 중요한 이유는 간단합니다. AI가 찾아낸 취약점은 화면에서 읽고 끝내면 안 되고, 팀 리뷰와 이슈 추적 전에 증거 묶음으로 남겨야 합니다.

Codex Security 결과를 왜 파일로 남겨야 하나요?

한 줄 요약: 보안 스캔 결과는 “Codex가 말했다”가 아니라 “어떤 커밋, 어떤 경로, 어떤 증거, 어떤 한계가 남았는가”로 검토해야 합니다.

문제 상황은 흔합니다. Codex Security 스캔을 돌린 뒤 findings workspace에서 심각도와 설명을 보고 바로 수정 프롬프트를 던집니다. 그런데 나중에 리뷰어가 묻습니다. “이 finding은 어떤 scan bundle에서 나왔나요?”, “coverage는 어디까지였나요?”, “SARIF로 CI 도구에 넣을 수 있나요?”

이 질문에 답하려면 화면 캡처보다 파일이 필요합니다. OpenAI 공식 문서 기준으로 완료된 스캔은 report.md, scan-manifest.json, findings.json, coverage.json 같은 산출물을 만들고, findings workspace에서 JSON, CSV, SARIF 내보내기를 할 수 있습니다. 따라서 실무 루틴은 “찾기 -> 고치기”가 아니라 “찾기 -> 보존하기 -> 선별하기 -> 승인 후 추적하기 -> 고치기”가 되어야 합니다.

관련해서 최신 문서 확인 루틴은 DAKER의 코덱스 툴 사용법 21: 웹 검색은 근거 수집 표면이다와 같이 보세요. 명령 승인 기준을 파일로 고정하는 관점은 코덱스 툴 사용법 24: Rules로 명령 승인 기준을 파일로 고정하기와 연결됩니다.

findings workspace에서는 무엇을 먼저 봐야 하나요?

핵심 개념은 findings workspace입니다. findings workspace란, 완료된 Codex Security 스캔의 finding, coverage, severity, evidence, follow-up 상태를 한곳에서 검토하는 작업 공간을 의미합니다.

먼저 봐야 할 항목은 네 가지입니다.

확인 항목	봐야 하는 이유	남길 증거
scan target	스캔한 저장소, 폴더, 브랜치가 맞는지 확인	`scan-manifest.json`
coverage	스캔이 어디까지 봤는지 확인	`coverage.json`
finding evidence	취약점 설명이 실제 코드 경로와 연결되는지 확인	`findings.json`, workspace finding
portable report	팀 공유용 문맥을 남김	`report.md`

이 표의 목적은 Codex를 의심하자는 뜻이 아닙니다. AI 보안 스캔 결과를 사람이 재검토 가능한 단위로 만드는 것입니다. 특히 보안 리뷰는 시간이 지난 뒤 다시 열어보는 일이 많기 때문에, 결과 파일과 원본 scan bundle을 함께 남기는 편이 안전합니다.

Codex Security 결과 내보내기는 어떤 순서로 하나요?

단계별 사용법은 아래처럼 잡으면 됩니다.

Codex Security 스캔을 완료합니다.
findings workspace에서 severity, coverage, evidence를 먼저 훑습니다.
report.md, scan-manifest.json, findings.json, coverage.json 위치를 확인합니다.
downstream 도구가 필요하면 Export에서 JSON, CSV, SARIF 중 하나를 고릅니다.
Linear, GitHub, Jira 같은 이슈 추적은 중복 확인과 승인 payload 검토 뒤에 진행합니다.
수정은 한 번에 모든 finding을 처리하지 말고, 검토자가 받아들인 finding 하나씩 범위를 좁혀 진행합니다.

포맷 선택은 이렇게 하면 됩니다.

포맷	추천 상황	주의할 점
JSON	자동화 스크립트나 내부 도구에서 구조화 데이터를 읽을 때	원본 scan bundle과 함께 보관
CSV	보안팀, PM, 리드가 스프레드시트로 triage할 때	최신 triage 상태와 export 시점을 기록
SARIF	코드 스캐닝, 보안 대시보드, 호환 도구로 넘길 때	도구가 SARIF 필드를 어떻게 해석하는지 확인
`report.md`	리뷰 회의, 변경 기록, 감사 메모에 붙일 때	finding별 근거와 한계가 빠지지 않았는지 확인

짧은 예시는 어떻게 지시하면 되나요?

아래처럼 말하면 Codex가 바로 수정으로 뛰어들기 전에 결과 보존과 승인 경계를 먼저 확인하게 만들 수 있습니다.

Codex Security 스캔이 끝난 뒤 바로 수정하지 말고,
findings workspace에서 severity, coverage, evidence를 요약해줘.
report.md와 scan-manifest.json, findings.json, coverage.json 위치를 확인하고,
팀 리뷰용으로 CSV 또는 SARIF 내보내기가 필요한지 판단해줘.
이슈 생성은 중복 확인과 payload 검토 전에는 하지 마.

좋은 프롬프트의 핵심은 “고쳐줘”보다 “어떤 증거를 남기고, 어디까지 자동화할지”를 먼저 정하는 것입니다.

실수 방지 체크리스트는 무엇인가요?

스캔 결과를 화면에서 읽고 원본 파일 위치를 기록하지 않은 채 닫지 않았나요?
report.md만 저장하고 scan-manifest.json, findings.json, coverage.json을 분리해 잃어버리지 않았나요?
SARIF를 내보낸 뒤 어떤 도구에 넣었는지, export 시점이 언제인지 기록했나요?
Linear, GitHub, Jira 이슈를 만들기 전에 중복 이슈와 destination을 확인했나요?
한 작업에서 모든 finding을 한꺼번에 수정하려고 하지 않았나요?
보안 finding을 “AI가 확정한 취약점”으로 표현하지 않고, 사람이 검토해야 할 evidence-backed finding으로 다뤘나요?

공식 출처는 어디에서 확인했나요?

이 글은 2026년 6월 26일 기준 OpenAI Developers의 Codex Security plugin changelog, Codex Security quickstart, Export and track security findings, Run a Codex Security scan 문서를 확인해 작성했습니다. DAKER 공개 본문에는 디렉터리 정책상 외부 URL을 노출하지 않고, 브라우저로 확인한 DAKER 내부 글만 링크했습니다.

방법론의 한계도 분명히 있습니다. 이 글은 공식 문서의 기능 설명과 운영 흐름을 바탕으로 한 실무 루틴입니다. 특정 조직의 보안 기준, GitHub Advanced Security 설정, Jira/Linear 권한 모델, SARIF 소비 도구의 필드 해석은 환경마다 다를 수 있습니다.

자주 묻는 질문

Codex Security 결과 내보내기는 꼭 해야 하나요?

팀 리뷰, 감사 기록, 외부 보안 도구 연동이 필요하면 하는 편이 좋습니다. 개인 실험이라도 나중에 재검토할 가능성이 있으면 report.md와 구조화 파일 위치는 남기세요.

JSON, CSV, SARIF 중 무엇을 먼저 고르면 되나요?

사람이 보는 triage에는 CSV가 쉽고, 자동화에는 JSON이 낫습니다. 코드 스캐닝 도구나 보안 대시보드로 넘길 때는 SARIF가 적합합니다.

findings workspace만 보면 충분하지 않나요?

짧은 검토에는 충분할 수 있습니다. 하지만 팀 공유, 이력 보존, 외부 도구 연동에는 portable report와 구조화 파일이 필요합니다.

Codex가 finding을 찾으면 바로 고쳐도 되나요?

바로 고치기보다 evidence, reachability, impact, counterevidence를 먼저 검토하세요. 공식 문서도 사람이 finding을 받아들인 뒤 bounded patch로 수정하는 흐름을 권장합니다.

이슈 추적 도구까지 자동으로 만들면 안전한가요?

아닙니다. Linear, GitHub, Jira 추적은 destination, 중복, payload를 확인하고 승인한 뒤 진행해야 합니다. 보안 이슈는 공개 범위와 권한 실수가 더 큰 문제가 될 수 있습니다.

오늘 Codex Security 스캔을 돌렸다면, 수정 프롬프트를 넣기 전에 먼저 report.md와 export 포맷부터 확인해 보세요.