---
type: knowledge
domain: security
status: active
last-reviewed: 2026-07-27
---

# 보안 점검 대응 실전

> 한 줄 정의
> 발주사 보안 점검은 오픈의 관문이다 — 목표는 "지적 0건"이 아니라 **모든 지적이 조치 증적 또는 서면 승인으로 종결되는 것**이다. 취약점 자체의 원리는 [[보안 원리]], 심사 설계 대응은 [[05_보안 설계]] — 여기는 점검이 시작된 뒤의 실무다.

## 점검 유형 — 시점·대상·산출물이 다르다

| 유형 | 시점 | 대상 | 수행사가 받는 것 |
|------|------|------|----------------|
| 시큐어코딩 진단 | 개발 중~오픈 전 | 소스 코드 (정적 분석 중심) | 지적 목록 (룰 위반 라인 단위) |
| 웹 취약점 진단 | 오픈 전 | 실행 중인 애플리케이션 | 취약점 목록 + 재현 절차 |
| 모의해킹 | 오픈 전·정기 | 시스템 전체 (시나리오 공격) | 침투 시나리오 보고서 |
| 인프라 진단 | 오픈 전·정기 | 서버·미들웨어 설정 (베이스라인 대조) | 설정 위반 목록 |
| 개인정보 점검 | 오픈 전·정기 | PII 수집·보관·파기 실태 | 지적 + 개선 요구 |

- 어떤 점검을 누가(발주사 보안팀·외부 진단 업체) 언제 하는지, 제출 양식은 무엇인지를 **착수 시점에 입수**한다 — 점검 유형마다 준비물이 다르다.

## 일정 리스크 — 점검은 오픈 직전에 몰린다

- 점검·조치·재점검은 오픈 게이트다 — **지적 0건을 가정한 일정은 일정이 아니다.** 조치 기간(통상 1~2주)과 재점검 일정을 계획에 선반영한다.
- 조치와 검수(UAT)가 같은 기간에 겹치는 것이 통례다 — 점검 대응 담당을 지정하지 않으면 개발 리소스가 양쪽에서 찢긴다.
- 정적 분석 도구를 내부에서 미리 돌려 지적 후보를 소진해 두면 본 점검의 지적 수가 줄어든다 — 점검을 첫 실행으로 만들지 않는다.

## 지적사항 대응 루프 — 항목별로 닫는다

1. **재현**: 지적 항목을 우리 환경에서 재현한다 — 재현 없이 수정하면 조치 확인이 불가능하다.
2. **수정**: 원인 지점을 수정한다 — 같은 패턴의 미지적 지점도 이때 함께 훑는다(점검은 표본이지 전수 아님).
3. **조치 증적**: 항목별로 남긴다 — **수정 전/후 스크린샷 + 코드 diff**가 기본. "조치 완료"라는 문장은 증적이 아니다.
4. **재점검 확인**: 점검 주체의 재확인으로 종결된다 — 자체 판단 종결은 다음 점검에서 재지적으로 돌아온다.

- 항목별 상태(조치 완료/이의제기/위험 수용)를 단일 대장으로 관리한다 — 항목 누락이 곧 오픈 지연이다.

## 오탐 이의제기 — 감이 아니라 근거로

- 도구 기반 진단은 오탐이 섞인다. "우리는 문제없다"는 이의제기가 아니다 — **프레임워크·라이브러리가 이미 방어함을 코드로 증명**한다(예: ORM 파라미터화로 인젝션 불성립, 템플릿 엔진 자동 이스케이프로 XSS 불성립).
- 이의제기 문서에는 지적 항목·해당 코드·방어 지점·검증 방법을 명시한다 — 근거 문서 없는 이의제기는 미조치로 기록된다.
- 이의제기가 기각되면 조치로 전환한다 — 논쟁을 오픈 일정과 교환하지 않는다.

## 조치 불가 항목 = 위험 수용, 반드시 서면으로

- 기술 제약·일정 제약으로 조치 불가한 항목은 **발주사의 위험 수용(서면 승인)**으로만 종결된다 — **서면 승인 없는 미조치는 사고 시 수행사 책임**이다.
- 위험 수용에는 항목·사유·보완 통제·재검토 시점을 남긴다 — 구두 합의는 담당자가 바뀌면 없던 일이 된다. 예외 승인 대장이 분쟁 방어선이다 ([[05_보안 설계]]).

## 범위 판정 — 하자인가 CR인가

| 지적 성격 | 판정 | 처리 |
|----------|------|------|
| 계약·제안서에 시큐어코딩 가이드 준수 명시 + 그 위반 | 하자 | 무상 조치 |
| 계약에 없던 신규 보안 요구 (솔루션 도입·인프라 증설·신규 기능) | 범위 밖 | CR 회부 → [[SI 수주와 범위 관리]] |
| 발주사 관할 영역 지적 (망·공용 인프라·타 시스템) | 발주사 조치 | 책임 구분 기록 후 이관 |

- "보안이니까"라는 이유로 범위 밖 요구를 무상 수용하지 않는다 — 단, 판정 근거(계약 조항·가이드 버전)를 남기고 협의로 처리한다.

## 재발 방지 — 지적을 규칙으로 환원한다

- 반복 지적 패턴은 개인의 실수가 아니라 규칙의 부재다 — **지적 패턴을 코딩 규칙과 정적분석 룰로 환원**해 다음 프로젝트의 점검 전 자체 게이트로 만든다.
- 시크릿 하드코딩 지적은 재발 1순위다 — 커밋 전 스캔과 주입 체계로 구조적으로 막는다 → [[환경 구성과 시크릿 관리]].
- PII 관련 지적(과수집·로그 노출·파기 미비)은 항목 조치로 끝내지 말고 인벤토리·수명주기 규율로 되돌린다 → [[개인정보와 컴플라이언스]].

## 안티패턴

- **점검 결과를 받고 나서 일정 협상 시작** — 조치 기간은 점검 전에 일정에 있어야 한다. 사후 협상은 오픈 연기 통보다.
- **지적 항목만 핀포인트 수정** — 같은 패턴이 열 군데면 아홉 군데가 다음 점검에 나온다. 지적은 표본이다.
- **증적 없는 "조치 완료" 회신** — 재점검에서 미조치 판정 시 신뢰까지 잃는다. diff와 화면이 말하게 한다.
- **오탐을 조용히 무시** — 대장에 이의제기로 기록되지 않은 항목은 미조치와 구분되지 않는다. 무성 실패 금지는 점검 대응에도 적용된다.

## 관련 문서

- [[00_보안 허브]] — 10_보안 진입점
- [[보안 원리]] — 취약점·시크릿·최소 권한의 원리 정본
- [[권한 설계와 접근 통제 실전]] — 접근 통제 지적의 구현 측 짝
- [[개인정보와 컴플라이언스]] — PII 지적의 규율 정본
- [[환경 구성과 시크릿 관리]] — 시크릿 지적의 운영 정본
- [[05_보안 설계]] — 보안성 검토 답변서·예외 승인 대장
- [[SI 수주와 범위 관리]] — 범위 판정·CR 회부의 계약 정본