ch015-feedback · git:20260429.be76f02 · 2026-04-29 · sha256 8c229fad17239cd7
ch015-feedback git:20260429.be76f02C
Immutable. This exact content is served forever at /api/v1/blob/8c229fad17239cd7.
# Security Design Review — 보안 설계 리뷰 스킬
> PRD/기획서를 분석하여 글로벌 보안 표준·규제에 근거한 보안 구현 명세를 생성한다.
---
## 서비스 개요
| 항목 | 내용 |
|------|------|
| 서비스명 | Security Design Review |
| 방법론 | PRD → 컴포넌트 분해 → 표준 바인딩 → 구현 명세 |
| 출력물 | Security Implementation Specification (SEC-{COMP}-{NNN}) |
| 코드 수정 | ❌ 없음 (명세 생성 전용) |
| 코드 분석 | ❌ 없음 (PRD/기획서 텍스트 분석) |
| 토큰 예산 | ~30K (OffSec VA 대비 66% 절감) |
---
## 설계 원칙
```yaml
No_Pattern_Lists:
- "CWE/OWASP 카탈로그를 기계적으로 나열하지 않는다"
- "PRD 컨텍스트에서 실제 관련된 표준만 바인딩"
- "도메인·관할에 따라 적용 표준이 달라짐을 인지"
Standards_Authority:
- "권고하는 모든 알고리즘·파라미터에 근거 표준 인용 필수"
- "표준이 명확하면 그대로 인용 (e.g., NIST SP 800-63B §5.1.1.2)"
- "표준 간 충돌 시 가장 엄격한 기준 채택"
- "표준이 업데이트된 경우 최신 버전 적용 (e.g., PCI DSS 4.0.1 future-dated 2025-03-31)"
Implementation_Specificity:
핵심: "구현자가 바로 코딩할 수 있는 수준"
bad_examples:
- "암호화 적용"
- "강력한 비밀번호 정책"
- "적절한 접근 제어"
good_examples:
- "AES-256-GCM envelope encryption, DEK 로테이션 365일, CMK→DEK 2-tier"
- "bcrypt cost 12, 최소 12자, zxcvbn score ≥ 3, breached-password 사전 차단"
- "리소스별 ABAC, policy: {action, resource, condition}, 서버사이드 enforcement"
Conservative_Judgment:
- "규제 적용 범위 불확실 시 '적용 가능성 있음'으로 포함"
- "'이 정도면 안전하다'는 표현 금지"
- "법률 자문이 아닌 기술 보안 관점의 참고 정보"
```
---
## Phase 구조 (Overview)
```
Phase 0: PRD Analysis → 입력 분석, 도메인/관할 감지
Phase 1: Component Map → 보안 컴포넌트 분해, 오버레이 참조
Phase 2: Standards Bind → 표준·규제 매핑, 구현 지침 추출
Phase 3: Spec Generation → SEC-{COMP}-{NNN} 명세 생성, 출력
```
---
## Phase 0: PRD Analysis (입력 분석)
```yaml
목적: "PRD/기획서에서 보안 관련 컨텍스트를 추출한다"
Step_0_1_입력_처리:
파일_경로: "Read 도구로 파일 내용 로드"
인라인_텍스트: "사용자 메시지에서 직접 추출"
복수_파일: "각 파일을 순차 Read 후 병합"
Step_0_2_기능_추출:
추출_대상:
- "핵심 기능 목록 (e.g., 결제, 인증, 지갑, 관리자)"
- "데이터 유형 (PII, 카드 정보, 암호화폐 주소, 세션 등)"
- "사용자 유형 (일반 사용자, 판매자, 관리자, API 클라이언트)"
- "외부 연동 (PG, 블록체인 노드, KYC 제공자, 세금 API 등)"
- "배포 환경 힌트 (클라우드, 리전, 규모)"
Step_0_3_도메인_감지:
method: "tier2-overlays/registry.yaml의 시그널 패턴을 PRD 텍스트에 자연어 매칭"
주의: "코드 import가 아닌 PRD 키워드 매칭 — '결제', '지갑', '토큰', 'API 키' 등"
override: "--domain 옵션이 있으면 자동 감지 대신 강제 적용"
Loading_Rule: "registry.yaml만 Read. 오버레이 파일은 Phase 1에서 조건부 로드"
Step_0_4_관할_감지:
signals:
- "서비스 대상 국가/지역 언급"
- "법인 소재지"
- "데이터 저장 위치"
- "사용자 거주 국가"
default: "global (다중 관할 가정)"
override: "--jurisdiction 옵션이 있으면 강제 적용"
Output:
context:
project: "프로젝트명"
description: "1줄 요약"
components: ["기능1", "기능2", ...]
data_types: ["PII", "카드 정보", ...]
user_types: ["일반", "관리자", ...]
integrations: ["PG", "블록체인", ...]
domains: ["payment", "web3", ...]
jurisdiction: "uae|kr|eu|global|..."
level: "essential|standard|comprehensive"
```
---
## Phase 1: Component Map (보안 컴포넌트 매핑)
```yaml
목적: "PRD 기능을 보안 관련 아키텍처 컴포넌트로 분해한다"
Step_1_1_컴포넌트_분해:
방법: "Phase 0 기능 목록을 보안 경계(trust boundary) 기준으로 분류"
컴포넌트_유형_예시:
SEC-SDK: "클라이언트 SDK (모바일, 웹, 네이티브)"
SEC-API: "API 서버 (인증, 라우팅, 미들웨어)"
SEC-AUTH: "인증/인가 시스템"
SEC-PAY: "결제 처리 (상태 머신, PG 연동)"
SEC-FDS: "이상거래 탐지 (FDS/AML)"
SEC-CRYPTO: "암호화폐/블록체인 연동"
SEC-WALLET: "지갑/키 관리"
SEC-WEBHOOK: "웹훅 수신/발신"
SEC-DATA: "데이터 레이어 (암호화, 백업, 접근제어)"
SEC-ADMIN: "관리자 콘솔 (인증, RBAC)"
SEC-INFRA: "인프라 (네트워크, 시크릿, 로깅)"
SEC-TAX: "세금/정산/보고"
SEC-AI: "AI/LLM 연동"
주의: "PRD에 없는 컴포넌트는 생성하지 않는다. PRD 범위에 충실"
Step_1_2_오버레이_참조:
절차:
- "Phase 0에서 감지된 도메인의 tier2-overlay 파일을 Read"
- "오버레이의 Core Architecture Questions를 '구현 필수 항목'으로 재해석"
- "1-3개 오버레이만 로드 (토큰 예산 제약)"
예시:
domain_payment: "payment.md의 질문 → SEC-PAY 요구사항 시드"
domain_web3: "web3.md + web3-wallet.md(해당 시) → SEC-CRYPTO, SEC-WALLET 시드"
Loading_Rule: "감지된 도메인의 오버레이만 Read. 미감지 도메인 파일 로드 금지"
Step_1_3_컴포넌트_레지스트리:
출력_형식:
per_component:
id_prefix: "SEC-{COMP}"
description: "컴포넌트 설명"
prd_functions: ["매핑된 PRD 기능"]
trust_boundary: "client|server|external|infra"
data_sensitivity: "restricted|confidential|internal|public"
overlay_seeds: ["오버레이에서 추출한 보안 관심사"]
```
---
## Phase 2: Standards Bind (표준·규제 바인딩)
```yaml
목적: "컴포넌트별 적용 표준과 규제를 결정하고 구현 지침을 추출한다"
Step_2_1_표준_레지스트리_로드:
action: "knowledge-base/standards/registry.yaml Read"
내용: "도메인 → 표준 매핑 인덱스"
Step_2_2_표준_매핑:
절차:
- "도메인 × 컴포넌트 조합으로 적용 표준 목록 결정"
- "매칭된 표준 YAML 파일만 조건부 Read (2-4개)"
- "각 표준의 requirements 중 해당 컴포넌트에 적용되는 항목 추출"
Loading_Rule: "registry.yaml에서 매칭된 표준 파일만 Read. 전체 로드 금지"
예시:
SEC-PAY_x_payment:
standards: ["pci-dss-v4", "owasp-top10"]
load: ["pci-dss-v4.yaml", "owasp-top10.yaml"]
SEC-AUTH_x_saas:
standards: ["owasp-top10", "nist-sp800"]
load: ["owasp-top10.yaml", "nist-sp800-select.yaml"]
Step_2_3_규제_바인딩:
절차:
- "관할에 따라 privacy-regulations.yaml 추가 로드"
- "도메인별 산업 규제 적용 (결제→PCI, 금융→AML/CFT, 의료→HIPAA)"
예시:
jurisdiction_uae:
load: ["privacy-regulations.yaml"]
extract: "UAE Federal Decree-Law 45/2021 요건"
jurisdiction_eu:
load: ["privacy-regulations.yaml"]
extract: "GDPR 요건"
Step_2_4_구현_지침_추출:
각_표준_요건에서:
- "implementation: 알고리즘·파라미터 수준 구현 지침"
- "test_criteria: happy/failure/boundary 테스트 기준"
병합_규칙:
- "동일 컴포넌트에 복수 표준 적용 시 가장 엄격한 기준"
- "표준 간 충돌 시 최신·최엄격 우선"
Output:
component_standards_map:
per_component:
id_prefix: "SEC-{COMP}"
applicable_standards: ["표준 ID"]
requirements:
- standard_ref: "PCI DSS 4.0.1 Req 3.5.1"
implementation: ["구현 지침"]
test_criteria: {happy: "...", failure: "...", boundary: "..."}
```
---
## Phase 3: Spec Generation (명세 생성)
```yaml
목적: "표준 바인딩 결과를 SEC-{COMP}-{NNN} 명세로 변환하여 출력한다"
Step_3_1_요구사항_생성:
절차:
- "(컴포넌트 × 표준 요건) 교차점마다 SEC-{COMP}-{NNN} 생성"
- "NNN은 컴포넌트 내 001부터 순차 부여"
per_requirement:
title: "요구사항 제목 (한글)"
근거: "표준/규제 조항 인용 (복수 가능)"
구현: "알고리즘·파라미터 수준 구현 명세"
수용_기준: "체크박스 형태 (happy + failure + boundary)"
Step_3_2_중복_병합:
규칙:
- "동일 컴포넌트에서 유사 요구사항은 통합"
- "근거는 모든 관련 표준 병기"
- "구현은 가장 엄격한 기준으로 통합"
Step_3_3_레벨_필터:
essential:
기준: "CRITICAL/HIGH 영향 항목만"
목표: "~20 specs"
우선순위: "인증, 암호화, 접근제어, 데이터보호"
standard:
기준: "MEDIUM 이상 + 주요 LOW"
목표: "~40-60 specs"
우선순위: "전체 컴포넌트 균형 커버"
comprehensive:
기준: "모든 표준 항목 + 규제 전체"
목표: "~80-100+ specs"
우선순위: "누락 없는 전체 커버리지"
Step_3_4_출력_생성:
template: "templates/feedback-spec.template.md 기반"
구조:
- 헤더: 프로젝트 메타, 적용 표준, 버전
- 목차: 컴포넌트별 SEC 번호 인덱스
- 본문: 컴포넌트별 SEC-{COMP}-{NNN} 상세
- 부록_A: 외부 API 연동 보안 (해당 시)
- 부록_B: 적용 표준 레퍼런스 (표준 × 조항 × SEC-ID 크로스맵)
저장:
경로: "{target}/reports/ch015-{project}-{date}-feedback.md"
fallback: "저장 경로가 없으면 출력만 수행"
Step_3_5_요구사항_포맷:
예시: |
### SEC-API-001: HMAC-SHA256 요청 서명
**근거**: NIST FIPS 198-1 (HMAC), FIPS 180-4 (SHA-256), CWE-294 (Replay), CWE-208 (Timing Attack)
**구현**:
- Secret Key API 호출에 HMAC-SHA256 서명 필수
- 서명 base: `{timestamp}.{HTTP_method}.{path}.{SHA256(body)}`
- Timestamp 비교: ±300초 (5분)
- 서명 비교: constant-time comparison
**수용 기준**:
- [ ] 유효한 서명 → 200 정상 처리
- [ ] 서명 누락 → 403
- [ ] 잘못된 서명 → 403
- [ ] 5분 초과 timestamp → 403
- [ ] 서명 일치/불일치 응답 시간 차이 < 1ms
```
---
## 컨텍스트 로딩 프로토콜
```yaml
Phase_0_로드:
고정: "이 SKILL.md (이미 로드됨)"
조건부: "tier2-overlays/registry.yaml (도메인 감지용)"
토큰: "~2K"
Phase_1_로드:
조건부: "감지 도메인의 tier2-overlay 1-3개"
언로드: "registry.yaml (Phase 0에서 사용 완료)"
토큰: "~3-8K"
Phase_2_로드:
고정: "standards/registry.yaml"
조건부: "매칭 표준 YAML 2-4개"
언로드: "tier2-overlay (Phase 1에서 시드 추출 완료)"
토큰: "~5-10K"
Phase_3_로드:
고정: "templates/feedback-spec.template.md"
언로드: "표준 YAML (Phase 2에서 지침 추출 완료)"
토큰: "~1K"
합계_예상: "~22-32K (PRD 크기에 따라 변동)"
```
---
## Anti-Patterns
```yaml
금지_사항:
Pattern_Dump:
설명: "CWE/OWASP 카탈로그를 PRD 컨텍스트 무관하게 전부 나열"
올바른_접근: "PRD에서 실제 관련된 표준 항목만 바인딩"
Vague_Recommendations:
설명: "'암호화 적용', '적절한 인증' 등 구체성 없는 권고"
올바른_접근: "알고리즘·파라미터·프로토콜 수준 명세"
Scope_Creep:
설명: "PRD에 없는 기능에 대한 보안 요구사항 생성"
올바른_접근: "PRD 범위에 충실. 필요 시 '추가 검토 권장' 메모"
Legal_Advice:
설명: "'이 구현으로 GDPR 준수 완료' 등 법적 판단"
올바른_접근: "'GDPR Art.32 기준 기술적 보호조치 명세' — 법무 검토 필요 부기"
Over_Loading:
설명: "모든 표준 YAML을 한 번에 로드하여 토큰 낭비"
올바른_접근: "도메인·컴포넌트에 매칭된 파일만 조건부 Read"
Code_Analysis:
설명: "소스코드를 분석하거나 Finding을 생성"
올바른_접근: "PRD 텍스트만 분석. 코드 진단은 /ch015:va로 위임"
```
---
## Root Cause 해당 없음
이 스킬은 기존 코드의 문제를 진단하지 않으므로 Root Cause Classification을 사용하지 않습니다.
출력은 Finding이 아닌 **SEC 구현 명세**입니다.