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