보안 심사은(는) 무엇을 하나요?
OpenClaw 보안 권고, 초안 또는 GHSA 보고서를 검토할 때 사용합니다.
목표: 실제 문제를 과도하게 마감하거나 불필요한 회귀를 출시하지 않으면서, 유지 관리자가 높은 신뢰도로 심사할 수 있도록 합니다.
마감 기준
다음 중 하나에 해당하는 경우에만 마감합니다:
- 기존 권고나 수정된 이슈의 중복
- 출시된 동작에 반하는 무효 사례
SECURITY.md에서 범위를 벗어난 경우- 영향을 받는 릴리스/태그 이전에 수정됨
main이 수정되었다는 이유만으로 마감하지 마십시오. 최신 출시 태그나 npm 릴리스가 영향을 받는 경우, 올바른 상태로 릴리스되거나 게시될 때까지 열어둡니다.
필수 읽기
응답하기 전에:
SECURITY.md를 읽습니다.gh api /repos/openclaw/openclaw/security-advisories/<GHSA>로 GHSA 본문을 읽습니다.- 정확히 관련된 코드 경로를 검사합니다.
- 출시 상태를 확인합니다:
git tag --sort=-creatordate | headnpm view openclaw version --userconfig "$(mktemp)"git tag --contains <fix-commit>- 필요시:
git show <tag>:path/to/file
- 정식 중복을 검색합니다:
- 기존 게시된 GHSA
- 오래된 수정된 버그
SECURITY.md에 이미 포함된 동일 신뢰 모델 클래스
검토 방법
각 권고에 대해 다음을 결정합니다:
마감열어둠열어두되 범위 축소
댓글이나 마감이 포함된 경우 기본적으로 한 번에 하나의 권고를 처리합니다:
- 정확히 하나의 GHSA를 검토합니다.
- 먼저 GHSA URL을 출력합니다.
- 결정과 증거를 요약하여 논의합니다.
- 유지 관리자가 바로 사용할 수 있는 댓글 하나를 작성합니다.
- 해당 댓글 하나만 클립보드에 복사합니다.
- 다음 GHSA로 넘어가기 전에 잠시 멈추고 Peter가 게시/논의할 때까지 기다립니다.
Peter가 명시적으로 배치를 요청하지 않는 한 여러 마감 댓글을 배치로 처리하지 마십시오.
다음 순서로 확인합니다:
- 신뢰 모델
- 전제 조건이 이미 신뢰된 호스트/로컬/플러그인/운영자 상태 내에 있는가?
SECURITY.md에서 이 클래스를 명시적으로 범위 밖 또는 강화 전용으로 명시하는가?
- 출시된 동작
- 버그가 최신 출시 태그 또는 npm 릴리스에 존재하는가?
- 릴리스 이전에 수정되었는가?
- 익스플로잇 경로
- 보고서가 실제 경계 우회를 보여주는가? 단순한 프롬프트 인젝션, 로컬 동일 사용자 제어, 또는 헬퍼 수준 의미론이 아닌가?
- 데이터가
SECURITY.md에 명시된 신뢰된 워크스페이스 메모리 파일 사이에서만 이동하는 경우, '인젝션 마커'만으로 보안 버그로 취급하지 마십시오. - 그런 경우, 예상 메모리 워크플로우를 유지한다면 샌드화를 선택적 강화로만 구성하십시오.
- 기능적 트레이드오프
- 강화 변경이 의도된 사용자 기능을 감소시킨다면, 제안하기 전에 이를 지적하십시오.
- 경계가 요구하지 않는 한, 기본 거부 회귀보다 사용자 워크플로우를 유지하는 수정을 선호하십시오.
- 강화 후속 조치
- GHSA를 마감해야 하는 경우에도, 문서화된 신뢰 경계를 변경하지 않으면서 발판을 줄일 수 있는 좁은 강화 변경이 가능한지 질문하십시오.
- 강화와 취약점 상태를 분리하십시오. "GHSA 마감에 필요하지 않지만 고려할 가치가 있음"으로 표현하십시오.
- 구체적이고 위험이 낮으며 의도된 유지 관리자/운영자 워크플로우를 유지하는 경우에만 강화를 제기하십시오.
- 강화를 위해 제품/보안 모델 변경이 필요하다면 명시적으로 말하고, 마감에 필요한 수정으로 암시하지 마십시오.
응답 형식
유지 관리자가 사용할 마감 답변을 준비할 때:
- 먼저 GHSA URL을 출력합니다.
- 그런 다음 유지 관리자가 게시할 수 있는 상세 응답을 작성합니다.
- 포함할 내용:
- 정확한 마감 사유
- 정확한 코드 참조
- 정확한 출시 태그/릴리스 사실
- 수정 출처 또는 해당되는 경우 정식 중복 GHSA
- 가치 있고 기능을 유지하는 경우에만 선택적 강화 노트
어조는 단호하고 구체적이며 방어적이지 않게 유지하십시오.
공개 워딩 위생
- 원시 커밋 해시, PR 제목/번호, 수정 메커니즘 요약을 공개 권고 텍스트에 포함하지 마십시오. 패치된 릴리스/버전 필드만 사용하십시오.
- 정확한 커밋 SHA, PR, 구현 노트는 내부 노트 및 검증 파일에 보관하십시오.
- 강화/게시 안 함 결과의 경우, 익스플로잇 세부 정보, "수정자" 텍스트 또는 "수정 커밋" 섹션을 추가하지 마십시오. 보고자에게 감사하고, 신용을 유지하며,
SECURITY.md경계를 명시하고, GHSA가 게시 없이 마감될 것임을 명확히 말하십시오. - 게시된 CVE/GHSA 텍스트의 경우, 수정된 릴리스와 함께
### 패치된 버전을 선호하십시오. Peter가 명시적으로 요청하지 않는 한 패치 작동 방식을 설명하지 마십시오. - Peter가 명시적으로 요청하지 않는 한 GHSA ID를 변경 로그 및 릴리스 노트 워딩에 포함하지 마십시오.
논의 모드
Peter가 수동으로 GHSA 댓글을 게시할 때 이 흐름을 사용하십시오:
- URL을 보여줍니다.
- 간결한 평결을 제공합니다 (
마감,열어둠, 또는열어두되 범위 축소). - 가장 강력한 증거 항목을 나열합니다.
- 마감 사유와 별도로 선택적 강화 후속 조치를 명시합니다.
- 제안된 댓글 본문을
pbcopy로 복사합니다. - 해당 권고 하나에 대한 응답을 마칩니다. Peter가 계속하라고 말할 때까지 다음 권고로 넘어가지 마십시오.
GitHub API가 비공개 권고에 대해 댓글을 게시할 수 없는 경우, 한 번 말하고 클립보드/UI 붙여넣기를 계속 사용합니다.
클립보드 단계
현재 권고에 대한 최종 게시 본문을 작성한 후 다음을 복사합니다:
pbcopy <<'EOF'
<최종 응답>
EOF
사용자에게 클립보드에 해당 권고에 대한 제안된 응답이 포함되어 있음을 알립니다.
유용한 명령어
gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
gh api /repos/openclaw/openclaw/security-advisories --paginate
git tag --sort=-creatordate | head -n 20
npm view openclaw version --userconfig "$(mktemp)"
git tag --contains <commit>
git show <tag>:<path>
gh search issues --repo openclaw/openclaw --match title,body,comments -- "<terms>"
gh search prs --repo openclaw/openclaw --match title,body,comments -- "<terms>"
사이버 분류기 중단
사이버 분류기에 의해 중단된 허용된 방어 작업의 경우, 해당 제한된 작업에 대해서만 승인되고 사용 가능한 Daybreak Blue 경로를 사용한 후 이전 모델을 복원하십시오. 승인된 ID, 범위, 권한, 샌드박스 및 검토 게이트를 유지하십시오. 접근 거부, 허용되지 않은 요청 또는 거부된 도구 동작을 우회하기 위해 모델을 전환하지 마십시오. 해당 경로도 거부하는 경우 중단하고 보고하십시오. 승인된 모델 액세스에 대해서는 OpenAI의 지침을 따르십시오.
결정 참고사항
- "main에서 수정되었지만 출시되지 않음"은 일반적으로 마감 사유가 아닙니다.
- "공격자가 제어하는 신뢰된 로컬 상태가 먼저 필요함"은 일반적으로 범위 밖입니다.
- "동일 호스트 동일 사용자 프로세스가 이미 로컬 상태를 읽고 쓸 수 있음"은 일반적으로 범위 밖입니다.
- "신뢰된 워크스페이스 메모리가 신뢰된 워크스페이스 메모리를 승격/재인덱싱함"은 문서화된 경계를 넘지 않는 한 일반적으로 범위 밖입니다.
- "헬퍼 함수가 문서화된 설정 의미론과 다르게 동작함"은 일반적으로 무효입니다.
- 심각도만 잘못되었지만 버그가 실제인 경우, 열어두고 응답에서 영향을 좁히십시오.