사고 대응

# 1. 탐지 및 분류

다음 보안 신호를 모니터링합니다.

• GitHub Security Advisories(GHSA) 및 비공개 취약점 보고.
• 보고 내용이 민감하지 않은 경우 공개 GitHub 이슈/토론.
• 자동화된 신호(예: Dependabot, CodeQL, npm 보안 권고 및 비밀 스캐닝).

초기 분류:

1. 영향을 받는 구성 요소, 버전, 신뢰 경계 영향을 확인합니다.
2. 저장소 SECURITY.md의 범위 및 범위 제외 규칙을 사용하여 보안 이슈인지 강화/조치 불필요 항목인지 분류합니다.
3. 인시던트 담당자가 그에 맞게 대응합니다.

# 2. 평가

심각도 가이드:

• 심각: 패키지/릴리스/저장소 손상, 활성 악용, 또는 영향이 큰 제어 권한이나 데이터 노출을 동반하는 인증되지 않은 신뢰 경계 우회.
• 높음: 제한된 사전 조건이 필요한 검증된 신뢰 경계 우회(예: 인증되었지만 권한이 없는 고영향 작업), 또는 OpenClaw 소유 민감 자격 증명 노출.
• 중간: 실질적 영향이 있지만 악용 가능성이 제한적이거나 상당한 사전 조건이 필요한 중요한 보안 취약점.
• 낮음: 심층 방어 관점의 발견 사항, 범위가 좁은 서비스 거부, 또는 입증된 신뢰 경계 우회가 없는 강화/동등성 격차.

# 3. 대응

1. 보고자에게 접수 사실을 확인합니다(민감한 경우 비공개로).
2. 지원되는 릴리스와 최신 main에서 재현한 다음, 회귀 테스트를 포함해 패치를 구현하고 검증합니다.
3. 심각/높음 인시던트의 경우 가능한 한 빠르게 패치 릴리스를 준비합니다.
4. 중간/낮음 인시던트의 경우 일반 릴리스 흐름에서 패치하고 완화 지침을 문서화합니다.

# 4. 커뮤니케이션

다음 경로로 소통합니다.

• 영향을 받는 저장소의 GitHub Security Advisories.
• 수정된 버전에 대한 릴리스 노트/변경 로그 항목.
• 상태 및 해결에 대한 보고자 직접 후속 연락.

공개 정책:

• 심각/높음 인시던트는 적절한 경우 CVE 발급과 함께 조율된 공개를 진행해야 합니다.
• 위험이 낮은 강화 발견 사항은 영향 및 사용자 노출에 따라 CVE 없이 릴리스 노트 또는 보안 권고에 문서화할 수 있습니다.

# 5. 복구 및 후속 조치

수정 사항을 배포한 후:

1. CI 및 릴리스 아티팩트에서 해결 조치를 검증합니다.
2. 짧은 인시던트 사후 검토(타임라인, 근본 원인, 탐지 격차, 예방 계획)를 수행합니다.
3. 후속 강화/테스트/문서 작업을 추가하고 완료될 때까지 추적합니다.