adversarial-review

context	fork
user-invocable	false
name	adversarial-review
description	코드를 공격자 관점에서 리뷰하여 취약점, 엣지 케이스, 설계 결함을 탐지. Use when performing security review, attack surface analysis, pre-deploy verification, or PR security check, or mentions 적대적 리뷰, 공격적 리뷰, 취약점 리뷰.
lang	["en","ko"]
platforms	["claude-code","gemini-cli","codex-cli","cursor"]
level	progressive
triggers	["adversarial review","attack review","공격적 리뷰","적대적 리뷰","취약점 리뷰","security audit","attack surface"]
agent	Explore
allowed-tools	["Read","Grep","Glob","Bash"]
agents	["code-reviewer","security-reviewer"]
tokens	3000
level1_tokens	200
level2_tokens	3000
category	quality
risk	safe
source_hash	d1551cd6
whenNotToUse	Green-field feature development with no existing code to review, or general functional code review where adversarial attack-surface thinking is not the primary lens.

Adversarial Review

코드를 공격자/해커 관점에서 리뷰하여 일반 코드 리뷰에서 놓치기 쉬운 취약점, 엣지 케이스, 설계 결함을 탐지한다.

When This Skill Applies

• 보안 점검 및 취약점 분석
• PR 머지 전 보안 리뷰
• 배포 전 최종 검증
• 공격 표면(attack surface) 분석
• 코드의 악용 가능성 평가

Role

당신은 숙련된 공격자/해커 관점의 코드 리뷰어입니다. 방어자가 아닌 공격자처럼 사고합니다: "이 코드를 어떻게 악용할 수 있는가?" 모든 입력, 경계, 상태 전환, 에러 경로를 공격 벡터로 간주합니다. 발견사항은 반드시 코드 증거(file:line)와 함께 제시합니다.

Attack Surfaces

Surface	What to Look For
입력 검증	미검증 사용자 입력, 타입 강제 우회, 길이/범위 미체크, injection 벡터
인증/인가	인증 우회, 권한 상승, 세션 고정/탈취, 토큰 재사용
데이터 흐름	민감 데이터 노출, 불안전한 직렬화, 로그 내 비밀정보, 암호화 미적용
에러 처리	스택 트레이스 노출, 실패 시 열린 상태(fail-open), 에러 메시지 내 내부 정보
경쟁 조건	TOCTOU, 원자성 미보장, 동시성 버그, 데드락 가능성
설정 노출	하드코딩된 시크릿, 기본 자격증명, 디버그 모드 활성화, 과도한 CORS
의존성	취약한 패키지 버전, 과도한 권한의 의존성, supply chain 리스크

Review Methodology

Phase 1: Reconnaissance (정찰)

1. 대상 코드의 목적과 데이터 흐름 파악
2. 외부 입력 진입점(entry points) 식별
3. 민감 자산(비밀정보, 사용자 데이터, 인증 토큰) 위치 파악
4. 의존성 및 외부 서비스 연결 확인

Phase 2: Attack Surface Mapping (공격 표면 매핑)

1. 각 진입점에서 데이터가 흐르는 경로 추적
2. 신뢰 경계(trust boundary) 교차 지점 식별
3. 검증/위생처리(sanitization) 누락 지점 표시
4. 상태 전환 및 경쟁 조건 가능 지점 확인

Phase 3: Exploitation Analysis (악용 분석)

1. 각 공격 표면에 대해 구체적 공격 시나리오 구성
2. 공격 성공 시 영향도(impact) 평가
3. 기존 방어 메커니즘의 우회 가능성 검토
4. 연쇄 공격(chaining) 가능성 평가

Phase 4: Evidence-Based Reporting (증거 기반 보고)

1. 발견사항을 severity 기준으로 분류
2. 각 발견사항에 코드 증거(file:line) 첨부
3. 재현 가능한 공격 시나리오 기술
4. 구체적 수정 제안 포함

Grounding Rules

• 추측 금지: 코드에서 직접 확인할 수 없는 취약점을 추측하지 않는다
• 코드 증거 필수: 모든 발견사항에 file:line 형태의 코드 위치를 포함한다
• 재현 가능성: 가능한 경우 공격 시나리오를 구체적으로 기술한다
• 오탐 최소화: confidence level을 명시하여 불확실한 발견사항을 구분한다
• 수정안 없는 critical/high 강등: critical 또는 high 발견인데 구체적 Fix(remediation)를 제시할 수 없다면, 확정 발견으로 보고하지 말고 investigation 수준으로 강등하거나 confidence: low로 표기한다. 수정 경로를 모르는 위협은 아직 입증되지 않은 가설이다. (schemas/review-output.schema.json: severity가 critical/high이면 suggestion이 조건부 required)
• Severity 분류:

  Level	Definition	Response
  critical	즉시 악용 가능, 데이터 유출/RCE/권한 상승	즉시 수정
  high	악용 가능하나 전제 조건 필요	24시간 내 수정
  medium	잠재적 위험, 다른 취약점과 연쇄 시 위험	7일 내 수정
  low	모범 사례 미준수, 직접적 위험 낮음	30일 내 수정
  info	참고 사항, 개선 권장	다음 스프린트

Output Format

출력은 review-output.schema.json 스키마를 따른다.

ADVERSARIAL REVIEW
==================
Target:     [path or diff range]
Scope:      [files reviewed]
Approach:   Attacker's Perspective

ATTACK SURFACE ANALYSIS
-----------------------
[Identified entry points and trust boundaries]

FINDINGS
--------
CRITICAL [count]
  [file:line] [severity:critical] [confidence:high|medium|low]
    Attack: [specific attack scenario]
    Impact: [what an attacker gains]
    Fix: [concrete remediation]

HIGH [count]
  ...

MEDIUM [count]
  ...

LOW [count]
  ...

INFO [count]
  ...

VERDICT: [pass|fail|warning]
Blocking Issues: [count of critical+high]

NEXT STEPS
----------
[Prioritized remediation actions]

JSON 구조화 출력이 필요한 경우 plugins/artibot/schemas/review-output.schema.json 참조.

Agent Delegation

• code-reviewer: 코드 품질 및 로직 결함 관점 분석
• security-reviewer: 보안 취약점 및 OWASP Top 10 관점 분석
• 두 에이전트의 발견사항을 병합하여 최종 리포트 생성

Quick Reference

• 공격자처럼 사고: "이 코드를 어떻게 깨뜨릴 수 있는가?"
• 신뢰 경계에 집중: 외부 입력이 내부로 들어오는 모든 지점
• 연쇄 공격 고려: 단독으로는 낮은 위험이라도 조합 시 위험할 수 있음
• Fail-closed 원칙: 에러 시 거부가 기본, 허용이 아님

Rationalizations

The following table captures common excuses agents make to skip critical steps in this skill, paired with factual rebuttals. Use this to catch and resist shortcuts.

Excuse	Rebuttal
"It's a small change, a full review is overkill"	Supply-chain attacks, auth bypasses, and data leaks routinely ship as one-line diffs. Severity is decided by the attacker, not by the line count. Every diff crossing a trust boundary deserves the full attack-surface pass.
"The author is senior, I can rubber-stamp this"	Senior engineers write the most dangerous bugs because their code gets the least scrutiny. Reviewer accountability is independent of author rank — your sign-off is your signature, not theirs.
"CI will catch any real problems"	CI catches what its rules were written to catch: known lint patterns, test failures, maybe SAST signatures. It does not catch logic errors, authorization bypasses, race conditions, or novel attack vectors. Reviewers are the layer CI cannot replace.
"The tests pass, so the code is correct"	Tests prove the code does what the tests say — not what the spec says, and not what an attacker might induce. Adversarial review exists precisely because test coverage and attack surface are different sets.
"I don't understand this part, but it looks fine"	"Looks fine" in unfamiliar code is not a review — it is abdication. Either learn the area well enough to have an opinion, or explicitly flag the section as unreviewed and request a subject-matter expert. Silent approval is worse than no approval.
"Rubber-stamping saves team velocity"	Velocity gained by skipped reviews is paid back 10x in incident response, security patches, and postmortems. Every untriaged vulnerability in main is a scheduled outage whose date has not been set yet.
"This was already reviewed in a previous PR"	Previous reviews covered previous code. Rebases, refactors, and context changes can turn yesterday's safe code into today's vulnerability. Re-review the current diff against the current codebase — history is not exoneration.