Security Precheck

보안 사전점검 (외부 감사 대비)

외부 보안팀이 쓸 기준과 같은 기준으로 먼저 훑어서 고쳐두는 워크플로.

1. 스캔 (병렬)

동시 실행:

Agent(subagent_type: "security-audit") — P0 코드 규칙 12항목(하드코딩 시크릿·인증누락·PII로깅 등)
  + 에이전트 설정 8항목(.claude/훅·MCP·permissions·프롬프트 인젝션) grep 기반 스캔

# SonarQube 보안 핫스팟 (TO_REVIEW만) — sonar-project.properties 없으면 이 단계는
# 스킵하고 스킵 사실만 보고. 호스트/토큰 하드코딩 금지:
# 환경변수 $SONAR_HOST_URL / $SONAR_TOKEN 사용.
if [ -f sonar-project.properties ]; then
  key=$(grep 'sonar.projectKey' sonar-project.properties | cut -d= -f2-)
  curl -s -u "${SONAR_TOKEN}:" \
    "${SONAR_HOST_URL}/api/hotspots/search?projectKey=$key&status=TO_REVIEW&ps=500" \
    | python3 -c "import sys,json; d=json.load(sys.stdin); print('TO_REVIEW:', len(d['hotspots'])); [print(h['ruleKey'], h['component'], h.get('line','')) for h in d['hotspots']]"
fi

security-audit 프롬프트에는 이 프로젝트의 구체 맥락(인증 방식, 세션 처리, CORS 설정, 데이터 접근 계층, PII 필드)을 짚어주면 결과 품질이 좋아짐 — 기억으로 서술하지 말고 스킬 실행 시점에 레포의 인증/세션/CORS/데이터접근 진입점을 grep 으로 확인해서 실제 발견한 것을 반영.

2. 등급 분류 + 보고

• P0(치명적): 즉시 에스컬레이션 대상. 하드코딩 시크릿, 인증 우회, SQL 인젝션, .env git 유출 등.
• P1(권장 개선): 이 스킬의 주 타겟. rate-limit 부재, 쿠키 속성 누락, 상수시간 비교 누락, 과도한 permission allow, PII 로깅 등.
• 통과: 확인했지만 문제없는 항목도 명시(무엇을 확인했는지 신뢰도 근거로).

표 형식으로 보고: P0 N건 / P1 N건 / 통과 N건.

3. 이슈 등록 (P1 이상만, 트리비얼 제외)

같은 파일/같은 주제끼리 묶어서 이슈 하나로 — 발견사항당 이슈 남발 금지. 예: 같은 인증 컨트롤러에서 발견된 rate-limit·쿠키속성·상수시간비교 3건은 이슈 1개로.

# forge CLI 는 rules/forge.md 기준
gh issue create -t "<제목>" -b "<사전점검 배경 + 구체적 발견사항 + 관련 파일>"       # GitHub
glab issue create -t "<제목>" -d "<사전점검 배경 + 구체적 발견사항 + 관련 파일>" -y  # GitLab

로컬 설정(.claude/settings.local.json allow 트림, MCP 권한 재검토 등)은 이슈 없이 바로 처리 — 코드가 아니라 로컬 스코프 설정이라 P1 워크플로 대상이 아님.

4. 병렬 처리 (모델 티어 분산)

이슈를 성격별로 나눠 동시에 Agent 호출. 같은 파일을 건드리는 이슈는 한 에이전트에 몰아서 — 별도 에이전트로 쪼개면 같은 파일 동시수정 충돌.

각 Agent 호출에 isolation: "worktree" 필수(병렬 파일 수정 충돌 방지), 브랜치 생성 후 push/merge는 하지 말고 커밋까지만 하도록 프롬프트에 명시 — 머지는 부모 세션이 순차로 게이트한다(동시에 여러 worktree가 main을 건드리면 레이스 발생).

5. 순차 머지 + 클로즈

에이전트 완료 알림 올 때마다:

1. 보안/인증 관련 변경이면 diff를 직접 읽고 검토(상수시간 비교 방식, 세션 키 선택, rate-limit 스코프 등 — 틀리면 사전점검의 의미가 없어짐)
2. git pull && git merge <branch> --no-edit
3. 머지된 상태로 프로젝트 빌드/테스트 게이트 재실행(.claude/hooks/pre-commit.sh 의 스택 게이트가 기준)
4. git push
5. git worktree remove <path> --force && git branch -d <branch>
6. forge 컨벤션(rules/forge.md)대로 이슈 노트 + 클로즈

6. 메모리 기록

.claude/memory/project_security-precheck.md에 날짜·발견건수·처리 이슈번호· 받아들이기로 한 리스크(예: rate-limit 키가 프록시 뒤에서 부정확할 수 있음, 특정 MCP allow 유지 결정 등)를 남긴다. 다음 점검 때 이미 검토하고 유지하기로 한 항목을 또 묻지 않기 위함.

Learned warnings

• Rate-limit/lockout 키로 원시 클라이언트 주소(request.getRemoteAddr() 등)만 쓰면 리버스프록시 뒤에서 전체 요청이 프록시 IP로 잡혀 전역 잠금이 될 수 있음 — 배포 토폴로지에 따라 X-Forwarded-For 파싱 필요 여부를 검증 단계에서 확인.
• worktree에는 설치된 의존성(node_modules, venv 등)이 없어 프론트/빌드 게이트가 환경적으로 실패하는 경우가 있음 — 백엔드 전용 변경이면 심링크로 우회 가능(커밋 대상 아님), 프론트 변경이 포함된 이슈라면 해당 worktree에서 패키지 설치 (lockfile 고정)를 먼저 실행하도록 에이전트 프롬프트에 명시.
• MCP 권한(mcp__*)은 툴 단위 grant라 "읽기 전용만 허용" 같은 세분화가 불가능 — 실사용 필요성이 있으면 무리하게 제거하지 말고 근거를 메모리에 남기고 유지.