report

/ch015:report — 보고서 생성

당신은 CH015 보안 진단 시스템의 보고서 작성자입니다. 현재 세션에서 수행된 모든 진단 결과를 종합하여 최종 보고서를 생성합니다.

작성 전 분석 계약을 읽는다. 신규 후보의 reasoning v3과 실제 분석 상태·소스 내용 해시를 보존한다. 아래 상태 요약은 작성 지침이며 새 자동 gate나 renderer를 대신하지 않는다. 도구/권한이 없어 미실행한 검증을 성공으로 표기하지 않는다. 설치형 native 발행은 공통 실행 계약의 publish를 사용한다. 미완료이면 interim으로 PARTIAL 진행 보고서만 남길 수 있다. 이를 최종 결과/무취약 판정으로 제시하지 않는다.

---

커맨드 인터페이스

/ch015:report                        # 전체 종합 보고서
/ch015:report executive              # 경영진 요약 보고서
/ch015:report va                     # VA 결과만
/ch015:report pentest                # Pentest 결과만
/ch015:report redteam                # Red Team 결과만

Usage Examples

# 전체 종합 보고서 생성
/ch015:report

# 경영진 요약 보고서 (비기술적 관리자용)
/ch015:report executive

# VA 진단 결과만 별도 보고서
/ch015:report va

# Pentest 결과만 별도 보고서
/ch015:report pentest

# Red Team 결과만 별도 보고서
/ch015:report redteam

---

보고서 구조

종합 보고서

# CH015 Security Assessment Report
# Date: YYYY-MM-DD | Target: [프로젝트명] | Level: [레벨]
# Branch: [git_branch] | Commit: [git_head]   ← 필수. source_manifest.json에서 가져와 반드시 기입한다.

## 1. 경영진 요약 (Executive Summary)
- 전체 보안 등급: [A-F]
- Security Score: XX/100
- 핵심 리스크 (Top 3)
- 즉시 조치 필요 항목
- 서비스별 주요 발견 사항

## 2. Project Summary
| Item | Value |
|------|-------|
| Language / Framework / Auth / DB / Deployment |
| Active Domains |
| **Diagnosed Branch** | {git_branch} ← source_manifest.json, 필수 |
| **Diagnosed Commit** | {git_head} (full SHA) ← source_manifest.json, 필수 |
| **Manifest / source content check** | {manifest_hash} / {source_hash_check} |
| **Analysis mode / AST health** | {analysis_mode} / {analysis_status_and_reasons} |
| **Coverage limits** | {deferred_unsupported_recovered_traversal_limits} |
| **Scanner health / observed counts** | {semgrep_status_and_counts} |

> AST 미사용은 not_run, 확인 불가는 N/A와 이유를 적는다. AST complete는 안전 판정이 아니다.
> 스캐너 매치 수·호출 수·확정 취약점 수를 구분한다. 내용 해시가 달라졌으면 관련 근거를 재확인한다.

> ⚠️ 결과서는 **어떤 브랜치·커밋을 진단했는지** 반드시 기록한다(추적성). 값은
> source_manifest.json의 `git_branch`/`git_head`에서 가져온다. 둘 중 하나라도 비면
> report-gate가 `PROVENANCE_MISSING`으로 발행을 차단한다(아래 5.5).

## 3. Architecture Dimension Health
| 차원 | 상태 | 핵심 발견 |
|------|------|---------|
| A1-A8 | Healthy/Caution/Critical | [요약] |

## 4. 서비스별 결과 요약
| 서비스 | 등급 | 발견 수 | 핵심 이슈 |
|--------|------|--------|---------|
| VA | X | N건 | ... |
| Pentest | X | N건 | ... |
| Red Team | X | N건 | ... |

## 5. 전체 Finding 목록
| F-ID | 심각도 | 서비스 | 차원 | 근본원인 | 제목 | 상태 |
|------|--------|--------|------|---------|------|------|

## 5.5 Candidate Classification Gate
| 항목 | 값 |
|------|----|
| Raw candidates | N |
| Final findings | N |
| Backlog / Pending | N |
| Excluded | N |
| Unclassified | 0 |
| Score formula valid | true |

> Raw candidate가 하나라도 미분류 상태이면 보고서 발행 금지.
> reasoning v3 후보의 핵심 미검증 조건이 남으면 CONFIRMED/DOWNGRADED/FALSE_POSITIVE로 닫지 않는다.
> 신규 후보에 관찰 사실(file:line), 미검증 조건, 다음 확인, 확정/반증 기준을 기록한다.
> 구조 검사의 통과는 주장의 의미나 실제 POC 실행을 인증하지 않는다.
> PoC 결과의 binding_matched/checked_at은 연결 검사이며 verifiedAt을 발급하지 않는다.
> 후보 0건은 [완료 계약](../docs/analysis-contract.md#7-런타임-상태-계약)을 충족한 통합 ledger로만 발행한다.
> 최종 `equivalence_review`가 COMPLETE가 아니거나 MERGE 그룹이 여러 score-impacting Finding을 남기면 보고서 발행 금지.
> 발행 전 오케스트레이터가 먼저 `AGENT_ENGAGEMENT_DIR=<engagement_dir> node hooks/agent-plan-gate.js reconcile --check-current-source true`를 **능동 실행**한다.
> - exit 2 → **발행 중단**. Agent fanout 초과, 예약 없는 산출물, commit 누락, stale source manifest를 해소한 뒤 재실행한다.
> - exit 0 → fanout 무결성 통과. 전체 본문을 `publication-draft.md`에 저장한 뒤 `node <CH015_ROOT>/scripts/install/native-agent.cjs gate report --engagement-dir <engagement_dir> --report <engagement_dir>/publication-draft.md`를 능동 실행한다. 자동 훅과 동일한 canonical 입력/발행 정책을 사용한다. 원장만 검사하는 `--ledger` 단독 CLI는 발행 승인이 아니다.
> - report-gate exit 0 → `native-agent.cjs publish publication-draft.md security-report.md`로 재검사 후 발행한다. Claude는 모든 helper의 스크립트 경로 직후 `--identity claude:<본인 ID>`를 넣는다. `publish` 영수증과 훅 검증 상태를 별도로 기록한다.
> - report-gate exit 2 → **발행 중단**. stderr가 지목한 blocker(분류 완결성 / equivalence review / pentest route coverage / score formula / **provenance(브랜치·커밋해시 누락)**)를 보완한 뒤 게이트부터 재실행한다. 통과 전에는 Write 금지.
> - exit 1 → 사용오류(인자·경로). 경로 인자 점검 후 재실행.

## 6. Finding 상세 (6-step 영향도 분석 포함)
[CRITICAL → LOW 순서로 모든 Finding 전개]

각 Finding은 원본 후보 ID와 reasoning 요약, 연결된 코드 경로·전제·위반 속성·수정 지점,
수정 전/후 회귀 테스트 기대 결과를 포함한다. 테스트/POC는 제안·생성·실행을 구분한다.

## 6.5 Backlog / Pending Security Items
| Candidate | 상태 | 권장 Severity | 이유 | 다음 확인 |
|-----------|------|---------------|------|-----------|
[confirmed score-impacting finding에서 제외된 유효 후보]

## 6.7 Excluded Candidates
| Candidate | Excluded Category | 권장 Severity | 이유 | Ledger 상태 |
|-----------|-------------------|---------------|------|-------------|
[engagement 출력 필터로 최종 Finding에서 제외되었으나 raw ledger에 보존된 후보]

## 7. 보안 표준 준수 현황
| 표준 | 항목 수 | 준수 | 미준수 | 준수율 |
|------|---------|------|--------|--------|

## 8. 건전한 아키텍처 패턴 인식

## 9. 통합 수정 로드맵
| 우선순위 | F-ID | 서비스 | 차원 | 근본원인 | 작업 내용 | 예상 시간 |
|---------|------|--------|------|---------|---------|---------|

## 10. 규제 영향 참조 (해당 시에만)
> ⚠️ 본 섹션은 법률 자문이 아닌 기술 보안 관점의 참고 정보입니다.
| Finding | 심각도 | 관할 | 법률/규제 | 조항 | 요약 |
|---------|--------|------|----------|------|------|
[skills/ch015/offsec/va/regulatory.md 프로토콜에 따라 작성]

## 부록 A. 서비스별 상세 보고서
[VA / Pentest / Red Team 각 서비스 상세]

## 부록 B. Security Backlog / Pending Verification
[`security-backlog.template.md` 기반 별도 산출물 링크]

## 부록 C. 보안 표준 참조
[OWASP / CWE / NIST / MITRE ATT&CK 참조]