보고서를 받아 보기 전에는 그 보고서가 쓸 만한지 알기 어렵습니다. 그래서 저희 보고서의 목차와 각 장의 작성 기준, 그리고 발견 사항 한 건이 실제로 어떻게 기술되는지를 공개합니다.
1. 목차
| 장 | 내용 | 읽는 사람 |
|---|---|---|
| 0. 요약 | 과업 개요, 총평, 등급별 발견 건수, 즉시 조치 필요 항목 | 경영진 |
| 1. 과업 개요 | 범위(포함·제외), 수행 기간, 수행 방식, 제약 조건 | 공통 |
| 2. 판정 기준 | 위험도 등급 정의, 산정 방식, “확인 필요” 처리 원칙 | 공통 |
| 3. 발견 사항 | 항목별 상세 — 아래 3장 형식 참조 | 실무 |
| 4. 조치 우선순위 | 위험도 × 조치 난이도 매트릭스, 권장 순서 | 실무 · 관리자 |
| 5. 잔여위험 | 이번 과업에서 닫지 못한 항목과 사유 | 경영진 · 감사 |
| 부록 A | 점검 항목 전체 목록과 판정 결과(양호 포함) | 감사 · 심사 대응 |
| 부록 B | 수행 이력 · 사용 도구 · 데이터 파기 확인 | 감사 |
부록 A를 넣는 이유: 취약 항목만 담긴 보고서는 인증 심사나 내부 감사에서 “점검은 했는데 무엇을 점검했는지”를 증명하지 못합니다. 양호 판정 항목도 근거와 함께 남깁니다.
2. 발견 사항 1건의 서술 형식
발견 사항은 아래 8개 항목을 고정 순서로 씁니다. 항목이 비면 그 이유를 적습니다.
- 식별번호 · 제목 — 조치 티켓에 그대로 옮길 수 있는 한 줄
- 위험도 · 산정 근거 — 등급과 함께 왜 그 등급인지
- 대상 — URL·호스트·파일 경로 등 특정 가능한 위치
- 현상 — 확인된 사실만. 추정은 별도 표기
- 재현 절차 — 같은 결과를 얻기 위한 최소 단계와 근거(요청/응답, 설정값, 명령)
- 영향 — 이 항목이 악용되면 무엇이 가능한가
- 조치 방향 — 무엇을 어떻게. 설정 예시나 코드 수준 권고 포함
- 조치 확인 방법 — 담당자가 스스로 닫혔는지 확인하는 방법
예시 (익명화 · 형식 설명용)
WEB-014 · 타 사용자 주문 정보 조회 가능 (인가 우회)
위험도 High — 인증된 일반 사용자 권한으로 타인의 개인정보에 접근 가능하며, 재현이 안정적임. 대량 조회 가능 여부는 아래 “영향” 참조.
대상 GET /api/v2/orders/{orderId} — 운영 도메인
현상 주문 식별자를 다른 값으로 변경해 요청하면 소유자 검증 없이 응답함. 응답 본문에 수령인 성명·연락처·주소가 포함됨.
재현 절차 ① 계정 A로 로그인해 주문 상세 조회 → ② 요청의 orderId를 계정 B의 주문 식별자로 변경 → ③ 200 응답과 함께 계정 B의 정보가 반환됨. (요청·응답 원문 첨부)
영향 식별자가 순차 증가 형식이어서 반복 요청으로 다수 주문 정보 수집이 가능함. 개인정보 유출로 직결됨.
조치 방향 서버 측에서 요청 주체와 리소스 소유자의 일치를 검증. 식별자를 추측 불가능한 값으로 변경하는 것은 보완책이며 단독 조치로는 불충분함.
조치 확인 방법 동일 절차로 타 계정 식별자 요청 시 403 응답 확인. 접근 실패 로그가 남는지 함께 확인.
3. 이 형식이 만드는 차이
조치 확인 방법이 있으면 담당자가 재점검을 기다리지 않고 스스로 검증할 수 있습니다. 산정 근거가 있으면 등급을 두고 회의가 한 번 줄어듭니다. 추정과 사실의 분리가 있으면 오탐으로 인한 불필요한 작업이 사라집니다.
보고서 형식은 취향의 문제처럼 보이지만, 실제로는 조치가 끝까지 가느냐를 결정합니다.
4. 요청하실 수 있는 것
- 사내 티켓 시스템에 맞춘 발견 사항 CSV/JSON 형식
- 인증 심사 대응용 항목 매핑표(발견 사항 ↔ 인증기준 항목)
- 경영진 보고용 요약 슬라이드
- 영문 보고서(해외 본사·감사 대응용)
착수 전에 말씀해 주시면 산출물 목록에 포함해 계약서에 명시합니다.