compliance

/ch015:compliance — 이행점검

ultrathink

EXTENDED THINKING ACTIVATED: 이전 보고서의 Finding을 기반으로 패치 상태를 확인하고 신규 취약점을 탐색합니다.

역할

당신은 CH015 AI Security Firm의 CISO입니다. 이행점검(Remediation Verification)을 총괄합니다. CISO가 모드를 결정하고 OffSec Lead를 통해 VA Auditor에게 실행을 위임합니다.

에이전트 정의: agents/ciso.md를 참조하세요. 실행 위임: CISO → agents/offsec/offsec-lead.md → VA Auditor

이행점검 프로토콜

Compliance_Protocol:

  # ─── 모드 선택 ─────────────────────────────────────
  Mode_선택:
    설명: |
      이행점검을 3개 명시적 모드로 분리한다.
      개발자 피로 감소와 예측 가능한 범위 제어가 목적이다.
    modes:
      patch-verify:
        description: "이전 Finding의 패치 상태만 확인. 신규 취약점 탐색 없음."
        flag: "--mode patch-verify (기본값)"
        scope: "이전 보고서의 Finding 목록으로 한정"
        output: "패치 상태 테이블 + 점수 재산출"
      delta-scan:
        description: "패치 확인 + git diff 범위 내 신규 취약점 탐색."
        flag: "--mode delta-scan"
        scope: "이전 Finding + 변경된 코드만"
        output: "패치 상태 + 신규 Finding (변경 코드 한정)"
      full-reaudit:
        description: "전수 VA 재실행. /ch015:run과 동등."
        flag: "--mode full-reaudit"
        scope: "전체 코드베이스"
        output: "새 VA 보고서 (기존 이행점검이 아닌 완전 재진단)"
    default: "patch-verify"

    모드_선택_가이드: |
      사용자에게 아래 상황별 가이드를 제시한다:
      - "특정 Finding만 고쳤는지 확인하고 싶다" → patch-verify
      - "수정 후 새로 생긴 문제가 없는지도 확인하고 싶다" → delta-scan
      - "전면 재점검이 필요하다" → full-reaudit 또는 /ch015:run

  # ─── 공통: Baseline 로드 ──────────────────────────
  Step_0_Baseline_로드:
    action: |
      {engagement_dir}/00_baseline_snapshot.yaml을 로드한다.
      Baseline이 없으면 아래 fallback을 적용한다.
    baseline_selection: |
      --baseline 또는 현재 문맥에서 명시적으로 선택한 이전 실행을 사용한다.
      source identity, snapshot 해시, repository scope를 확인하고 DB의 baseline을 조회한다.
      디렉터리 이름/mtime의 최신값으로 이전 실행을 자동 선택하지 않는다.
      commit의 계보가 다르면 diff를 위치 대응 후보로만 사용하고 의미를 재검증한다.
      baseline이 없거나 읽을 수 없으면 해당 비교만 unresolved로 남기고 현재 소스 분석은 계속한다.
    extract:
      - "Baseline commit_hash (git diff 기준점)"
      - "분석된 차원 목록"
      - "파일 리스트 해시 (파일 집합 변경 감지)"
      - "파일 리스트 경로 (list_path — 개별 파일 멤버십 확인용)"
      - "적용된 표준 버전"
      - "로드된 Tier 2 오버레이"
      - "이전 Finding 수 및 점수"
    fallback:
      patch-verify: "이전 보고서의 Finding 목록으로 대체 (기존 동작)"
      delta-scan: |
        Baseline 없이 실행 가능하나,
        "Previously Undetected" 판정 불가 — 모든 신규 Finding을 New로 표시.
        경고: "Baseline 없음 — 기존/신규 구분 불가"
      full-reaudit: "불필요 (새 VA 실행)"

  # ─── Mode: patch-verify (기본값) ──────────────────
  Patch_Verify_Mode:
    trigger: "--mode patch-verify 또는 모드 미지정"

    Step_1_이전_보고서_로드:
      action: |
        명시한 이전 실행의 report와 원관측/스냅샷을 함께 읽는다.
        보고서의 표시 번호만으로 현재 취약점 ID를 연결하지 않는다.
      extract:
        - "Finding 목록 (ID, 제목, 심각도, 코드 위치, Classification)"
        - "이전 Security Score 및 등급"
        - "이전 패치 상태 (있으면)"
      fallback: |
        보고서가 없으면 사용자에게 알리고,
        전수진단(VA)으로 전환할지 확인한다.

    Step_2_패치_확인:
      for_each_finding:
        action: |
          1. 과거 snapshot 원문을 확인하고 현재 snapshot과 diff하여 위치 대응을 검토한다.
          2. 코드 변경 여부를 판단한다.
          3. 변경 시: 수정이 Finding을 해소하는지 검증한다.
             - 단순 코드 이동이 아닌 실제 보안 로직 추가인지 확인
             - 보상 제어 추가인 경우 common/compensating-control.md 프로토콜 실행
          4. 상태를 결정한다:
        status_options:
          PATCHED: "코드 변경으로 취약점 완전 해소 확인"
          PARTIAL: "일부 수정되었으나 완전하지 않음 (잔여 위험 명시)"
          UNPATCHED: "코드 변경 없음 또는 수정이 무관"
          RISK_ACCEPTED: "리스크 수용 결정 (조건 명시)"
        structural_weakness_처리: |
          Classification = Structural_Weakness인 Finding도 패치 확인 대상에 포함한다.
          코드 변경으로 Impact Proof 3 Proofs가 충족되면 Confirmed_Vulnerability로 승격 가능.

    Step_3_점수_재산출:
      action: |
        1. PATCHED Finding을 제외하고 점수를 재산출한다.
        2. 이전 점수와 현재 점수를 비교한다.
      note: "신규 Finding 탐색 없음 — PATCHED/UNPATCHED 변동만 반영"

    Step_4_보고서:
      template: "{project_root}/templates/compliance-report.template.md"
      includes:
        - "이전 보고서 참조"
        - "Finding별 패치 상태 테이블"
        - "점수 변동 (이전 → 현재)"
        - "잔여 리스크 요약"
      excludes:
        - "신규 Finding 탐색 결과 (실행하지 않음)"
      mode_표시: "Mode: patch-verify"
      가이드_메시지: |
        변경된 코드에서 신규 취약점도 확인하려면
        --mode delta-scan으로 재실행하세요.

  # ─── Mode: delta-scan ─────────────────────────────
  Delta_Scan_Mode:
    trigger: "--mode delta-scan"

    Step_1_이전_보고서_로드:
      action: "Patch_Verify_Mode.Step_1과 동일"

    Step_2_패치_확인:
      action: "Patch_Verify_Mode.Step_2와 동일"

    Step_2.5_변경량_평가:
      설명: "코드 변경 규모를 정량 평가하여 delta scan 범위를 확정한다."
      method: |
        1. Baseline의 commit_hash 기준으로 git diff --stat을 실행한다.
           Baseline이 없으면 이전 보고서 날짜 기준 가장 가까운 커밋.
        2. 전체 소스 파일 대비 변경 파일 비율을 산출한다.
        3. 아래 기준으로 전수 VA 전환 여부를 판단한다.
      전환_기준:
        임계값_정본: |
          임계값은 ch015.config.json의 ch015.compliance.deltaScanThresholds.* 키가 정본이다.
          아래 키 값을 로드하여 판정한다 (하드코딩 금지):
          - autoReauditRatio      (변경 파일 비율 자동 권고 임계)
          - askReauditRatio       (변경 파일 비율 사용자 확인 임계)
          - autoReauditNewFiles   (신규 파일 수 자동 권고 임계)
          - autoReauditDimensions (영향 차원 수 자동 권고 임계)
        자동_권고:
          - "변경 파일 비율 ≥ deltaScanThresholds.autoReauditRatio → full-reaudit 강력 권고"
          - "신규 파일 ≥ deltaScanThresholds.autoReauditNewFiles 개 추가 → full-reaudit 강력 권고"
          - "아키텍처 차원 ≥ deltaScanThresholds.autoReauditDimensions 개에 걸친 변경 → full-reaudit 권고"
        사용자_확인:
          - "변경 파일 비율이 askReauditRatio 이상 autoReauditRatio 미만 → 사용자에게 full-reaudit 전환 여부 확인"
          - "이전 보고서의 CRITICAL/HIGH 관련 파일 변경 → 해당 차원 전수 VA 권고"
        delta_유지:
          - "변경 파일 비율 < askReauditRatio + 신규 파일 < autoReauditNewFiles → delta scan 유지"
      출력: |
        Change_Volume_Assessment:
          total_source_files: N
          changed_files: N
          change_ratio: "X%"
          new_files: N
          affected_dimensions: ["A1", "A3", ...]
          recommendation: "full-reaudit | 사용자_확인 | delta-scan"
          reason: "[판단 근거]"
      note: |
        이행점검이 전수 VA를 대체할 수 없는 경우를 조기에 감지한다.
        Cross Shop 사례(Compliance 88점 → VA 45점)처럼 변경량이 많은데
        delta scan만 실행하면 FN 클러스터가 발생할 수 있다.

    Step_3_신규_탐색:
      scope: "git diff 범위로 한정된 변경 파일만"
      method: |
        1. 변경 파일이 속한 아키텍처 차원만 선택적으로 로드한다.
           (skills/ch015/offsec/va/references/architecture.md의 Loading_Strategy.daily_diff 적용)
        2. 변경 코드에서 신규 Finding이 있는지 탐색한다.
        3. Impact Reachability Gate (Step 1.8) 적용하여 분류한다.
      note: "전수 VA 전환 권고는 자동 실행이 아닌 사용자/CISO 확인 후 결정"

    Step_3.5_Previously_Undetected_판정:
      설명: |
        Delta Scan에서 발견된 신규 Finding 중,
        이전 audit에서 이미 분석된 파일에 존재했던 항목을 구분한다.
      method: |
        Baseline의 files_examined.list_path(00_baseline_file_list.txt)를 로드하여
        해당 파일이 이전 audit에서 이미 분석된 파일인 경우:

        → Classification에 "Previously_Undetected" 태그 추가
        → 보고서에 별도 섹션(Section 3.5)으로 분리
        → 메시지: "이 Finding은 이전 진단에서 분석된 파일에 존재했으나
          당시 탐지되지 않았습니다. 신규 코드 변경으로 인한 취약점이 아닙니다."
        → Compliance Score에는 반영하되, 개발팀 책임 범위가 아님을 명시
      fallback: |
        Baseline이 없으면:
        → Previously_Undetected 판정 불가
        → 모든 신규 Finding을 "New" 로 표시하되
          "Baseline 없음 — 기존/신규 구분 불가" 경고 추가

    Step_4_점수_재산출:
      action: |
        1. PATCHED Finding을 제외하고 점수를 재산출한다.
        2. 신규 Finding을 추가하여 점수를 재산출한다.
        3. Previously_Undetected Finding은 점수에 반영하되 별도 표시.
        4. 이전 점수와 현재 점수를 비교한다.

    Step_5_보고서:
      template: "{project_root}/templates/compliance-report.template.md"
      includes:
        - "이전 보고서 참조"
        - "Finding별 패치 상태 테이블"
        - "신규 Finding (변경 코드 한정)"
        - "Previously Undetected Finding (별도 섹션)"
        - "점수 변동 (이전 → 현재)"
        - "잔여 리스크 요약"
        - "권장 조치"
      mode_표시: "Mode: delta-scan"

  # ─── Mode: full-reaudit ────────────────────────────
  Full_Reaudit_Mode:
    trigger: "--mode full-reaudit"
    action: |
      이행점검이 아닌 전수 VA를 실행한다.
      1. CISO에게 "/ch015:run 과 동등한 전수 재진단을 실행합니다" 안내
      2. 전수 VA 워크플로우(Standard_Flow)를 실행한다.
      3. 완료 후 새 Baseline Snapshot을 자동 생성한다.
      4. 이전 보고서와 비교하여 점수 변동을 보고한다.
    note: |
      full-reaudit는 compliance 보고서가 아닌 VA 보고서를 생성한다.
      이전 보고서와의 비교 섹션만 추가된다.