| name | security-review |
| description | 구현 완료 후 보안 관점 심층 리뷰 — 즉시 반영 항목을 수정하고 결과를 보고한다. clean pass까지 반복이 필요하면 ralph를 통해 실행한다 |
| user-invocable | true |
Security Review
구현 완료 후 변경 사항을 보안 관점에서 심층 분석하고, 타당한 보안 개선을 코드에 반영한다.
반복 실행이 필요하면 /ralph /security-review로 ralph에 위임한다.
1. 변경 사항 수집
- 인자가 전달되면 (
/security-review <base-branch>) 해당 브랜치를 기준점으로 사용한다.
- 인자가 없으면 아래 절차로 기준점을 결정한다.
git fetch로 remote 상태를 최신화한다. 실패하면 경고를 출력하고 기존 local ref로 진행한다.- remote tracking branch를 기준점으로 결정한다.
git rev-parse --abbrev-ref @{upstream}로 tracking branch를 확인한다.- tracking branch가 없으면
git remote show origin | grep 'HEAD branch'로 remote 기본 브랜치를 조회하고, origin/<branch> 형태로 사용한다.
- 위 방법이 모두 실패하면 사용자에게 base branch를 직접 지정하도록 요청한다.
git log <base>..HEAD --oneline으로 unpushed commit 목록을 확인한다.- unpushed commit이 없으면 "리뷰 대상 없음"을 보고하고 즉시 종료한다.
git diff <base>..HEAD로 push되지 않은 커밋의 전체 변경 범위를 파악한다.- uncommitted 변경이 있으면 사용자에게 알리고, 리뷰 범위에 포함할지 확인한다. 포함하면
git diff + git diff --staged도 함께 수집한다. 포함하지 않으면 커밋된 변경만 리뷰한다. 리뷰 중 수정 사항을 커밋할 때는 리뷰 수정분만 staging하여 uncommitted 작업이 섞이지 않게 한다.
- 변경된 파일의 전체 내용을 읽는다. diff만으로는 주변 컨텍스트를 놓칠 수 있다. 단, 바이너리 파일, lockfile, 자동 생성물은 제외한다.
.claude/rules/security.md를 읽어 프로젝트의 보안 규칙을 확인한다.
2. 보안 심층 분석 (thinking mode)
extended thinking을 활용하여 다음을 분석한다:
입력 검증 (Input Validation)
- 시스템 경계(사용자 입력, 외부 API 응답, 파일 읽기, URL 파라미터, 헤더)에서 들어오는 데이터가 검증되는지 확인한다.
- SQL Injection, XSS, Command Injection, Path Traversal 등 OWASP Top 10 취약점에 노출되는 입력 처리가 없는지 확인한다.
- 역직렬화(deserialization) 시 신뢰할 수 없는 입력을 처리하는 경우가 없는지 확인한다.
인증 및 권한 (Authentication & Authorization)
- 인증 로직의 우회 가능성을 확인한다.
- 권한 검사가 누락된 엔드포인트나 기능이 없는지 확인한다.
- 세션/토큰 처리가 안전한지 확인한다 (만료, 무효화, 저장 방식).
- 권한 상승(privilege escalation) 경로가 없는지 확인한다.
비밀 정보 관리 (Secrets Management)
- API 키, 비밀번호, 토큰 등이 소스 코드에 하드코딩되어 있지 않은지 확인한다.
- 민감 정보가 로그, 에러 메시지, 응답 본문에 노출되지 않는지 확인한다.
.env, credentials 파일이 .gitignore에 포함되어 있는지 확인한다.- 민감 데이터가 커밋 히스토리에 포함되지 않았는지 확인한다.
데이터 보호 (Data Protection)
- 민감 데이터(PII, 금융 정보)가 적절히 암호화/마스킹되는지 확인한다.
- 로그에 민감 정보가 출력되지 않는지 확인한다.
- 데이터 전송 시 안전한 채널(TLS 등)을 사용하는지 확인한다.
의존성 보안 (Dependency Security)
- 새로 추가된 의존성에 알려진 취약점(CVE)이 없는지 확인한다.
- 의존성의 유지보수 상태와 보안 이력을 확인한다.
- 불필요하게 넓은 권한을 요구하는 의존성이 없는지 확인한다.
최소 권한 원칙 (Least Privilege)
- 파일, 네트워크, API 접근 권한이 필요한 최소 범위로 제한되어 있는지 확인한다.
- 불필요한 권한 상승(root, admin)을 요구하는 구현이 없는지 확인한다.
- CORS, CSP 등 브라우저 보안 정책이 적절히 설정되어 있는지 확인한다.
에러 처리 및 정보 노출
- 에러 응답에서 내부 구현 세부사항(스택 트레이스, DB 스키마, 내부 경로)이 노출되지 않는지 확인한다.
- 에러 처리가 보안 검사를 우회하는 경로를 만들지 않는지 확인한다.
3. 평가 기준
각 발견 항목을 다음 기준으로 분류한다:
- 즉시 반영: 보안 취약점, 민감 정보 노출, 인증/권한 우회, 입력 검증 누락 등 명확한 보안 문제. 코드에 직접 수정을 적용한다.
- 사용자 판단 필요: 보안-편의성 트레이드오프, 위협 모델에 따라 달라지는 항목, 대규모 리팩토링이 필요한 보안 개선. 수정하지 않고 보고만 한다.
- 무시: 현재 위협 모델에서 위험도가 낮은 항목, 범위 밖 개선 제안. 개별 내용은 보고하지 않되, 건수와 대표 사유는 보고 형식에 포함한다.
4. 수정 적용
- 즉시 반영 항목은 코드를 직접 수정한다.
- 수정 후 프로젝트의 빌드 검증과 테스트를 실행하여 수정이 다른 것을 깨뜨리지 않았는지 확인한다.
- 테스트가 실패하면 원인을 먼저 분류한다:
- 수정이 원인인 경우: 수정을 되돌리고 사용자 판단 필요로 재분류한다.
- 기존 flaky 테스트나 환경 문제인 경우: 수정을 유지하고 실패 원인을 보고한다.
- 수정이 완료되면 수정 사항을 commit한다.
5. 중단 기준
다음 중 하나라도 해당하면 push 진행을 중단하고 사용자에게 보고한다:
- 보안 취약점이 발견되고 즉시 반영으로 해결되지 않은 경우 (인증 우회, 권한 상승, 데이터 유출)
- 민감 정보가 소스 코드나 커밋 히스토리에 포함된 경우
- 알려진 CVE가 있는 의존성이 추가된 경우
- 수정 적용 후 빌드 또는 테스트가 실패하고, 단순 수정으로 해결되지 않는 경우
- 동일한 지적이 수렴하지 않고 계속 발생하는 경우 (순환 판단)
6. 보고 형식
리뷰 결과를 사용자에게 다음 형식으로 보고한다:
즉시 반영한 항목
(각 항목: 파일, 취약점 유형, 변경 내용, 발견 근거. 없으면 없음)
사용자 판단이 필요한 항목
(각 항목: 파일, 취약점 유형, 지적 내용, 판단을 미룬 이유. 없으면 없음)
무시한 항목
(건수와 대표 사유. 없으면 없음)
보안 리뷰 요약
(전체 변경의 보안 상태에 대한 1-2문장 평가)
