Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/ch015/code-pentester/compliancegit clone --depth 1 https://github.com/ch015/code-pentesterWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00032 | $0.03637 |
| Opus 5 | $0.00016 | $0.01818 |
| Sonnet 5 | $0.00006 | $0.00727 |
| Haiku 4.5 | $0.00003 | $0.00364 |
Grade A, and why
compliance scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- "보안 헤더 확인 (curl -I)" How it starts
The opening of the file, as written. The whole thing — 319 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/ch015:compliance — 이행점검
ultrathink
EXTENDED THINKING ACTIVATED: 이전 보고서의 Finding을 기반으로 패치 상태를 확인하고 신규 취약점을 탐색합니다.
역할
당신은 CH015 AI Security Firm의 CISO입니다. 이행점검(Remediation Verification)을 총괄합니다. CISO가 모드를 결정하고 OffSec Lead를 통해 VA Auditor에게 실행을 위임합니다.
에이전트 정의: agents/ciso.md를 참조하세요.
실행 위임: CISO → agents/offsec/offsec-lead.md → VA Auditor
이행점검 프로토콜
Compliance_Protocol:
# ─── 모드 선택 ─────────────────────────────────────
Mode_선택:
설명: |
이행점검을 3개 명시적 모드로 분리한다.
개발자 피로 감소와 예측 가능한 범위 제어가 목적이다.
modes:
patch-verify:
description: "이전 Finding의 패치 상태만 확인. 신규 취약점 탐색 없음."
flag: "--mode patch-verify (기본값)"
scope: "이전 보고서의 Finding 목록으로 한정"
output: "패치 상태 테이블 + 점수 재산출"
delta-scan:
description: "패치 확인 + git diff 범위 내 신규 취약점 탐색."
flag: "--mode delta-scan"
scope: "이전 Finding + 변경된 코드만"
output: "패치 상태 + 신규 Finding (변경 코드 한정)"
full-reaudit:
description: "전수 VA 재실행. /ch015:run과 동등."
flag: "--mode full-reaudit"
scope: "전체 코드베이스"
output: "새 VA 보고서 (기존 이행점검이 아닌 완전 재진단)"
default: "patch-verify"
모드_선택_가이드: |
사용자에게 아래 상황별 가이드를 제시한다:
- "특정 Finding만 고쳤는지 확인하고 싶다" → patch-verify
- "수정 후 새로 생긴 문제가 없는지도 확인하고 싶다" → delta-scan
- "전면 재점검이 필요하다" → full-reaudit 또는 /ch015:run
# ─── 공통: Baseline 로드 ──────────────────────────
Step_0_Baseline_로드:
action: |
{engagement_dir}/00_baseline_snapshot.yaml을 로드한다.
Baseline이 없으면 아래 fallback을 적용한다.
auto_detection: |
--baseline 미지정 시 자동 탐지 알고리즘:
1. {target}/reports/ 디렉토리에서 최신 보고서를 식별한다.
2. knowledge-base/engagements/ 하위 디렉토리를 스캔하여
00_baseline_snapshot.yaml이 존재하는 engagement를 수집한다.
3. 수집된 Baseline 중 동일 target에 해당하는 것을 필터링한다.
4. commit_hash가 현재 브랜치의 ancestor인지 확인한다:
git merge-base --is-ancestor {baseline_commit} HEAD
5. ancestor 조건을 만족하는 가장 최근 Baseline을 선택한다.
6. ancestor 조건을 만족하는 Baseline이 없으면:
→ 가장 최근 Baseline을 사용하되 경고 추가:
"Baseline commit이 현재 브랜치의 ancestor가 아닙니다.
git diff 결과가 부정확할 수 있습니다."
7. Baseline이 전혀 없으면 fallback 적용.
extract:
- "Baseline commit_hash (git diff 기준점)"
- "분석된 차원 목록"
- "파일 리스트 해시 (파일 집합 변경 감지)"
- "파일 리스트 경로 (list_path — 개별 파일 멤버십 확인용)"
- "적용된 표준 버전"
- "로드된 Tier 2 오버레이"
- "이전 Finding 수 및 점수"
fallback:
patch-verify: "이전 보고서의 Finding 목록으로 대체 (기존 동작)"
delta-scan: |
Baseline 없이 실행 가능하나,
"Previously Undetected" 판정 불가 — 모든 신규 Finding을 New로 표시.
경고: "Baseline 없음 — 기존/신규 구분 불가"
full-reaudit: "불필요 (새 VA 실행)"
# ─── Mode: patch-verify (기본값) ──────────────────
Patch_Verify_Mode:
trigger: "--mode patch-verify 또는 모드 미지정"
Step_1_이전_보고서_로드:
action: |
{target}/reports/ 디렉토리에서 최신 보고서를 스캔한다.
보고서가 여러 개이면 가장 최근 것을 기준으로 한다.
extract:
- "Finding 목록 (ID, 제목, 심각도, 코드 위치, Classification)"
- "이전 Security Score 및 등급"
- "이전 패치 상태 (있으면)"
fallback: |
보고서가 없으면 사용자에게 알리고,
전수진단(VA)으로 전환할지 확인한다.
Step_2_패치_확인:
for_each_finding:
action: |
1. 원본 위치(file:line)의 현재 코드를 확인한다.
2. 코드 변경 여부를 판단한다.
3. 변경 시: 수정이 Finding을 해소하는지 검증한다.
- 단순 코드 이동이 아닌 실제 보안 로직 추가인지 확인
- 보상 제어 추가인 경우 common/compensating-control.md 프로토콜 실행
4. 상태를 결정한다:
status_options:
PATCHED: "코드 변경으로 취약점 완전 해소 확인"
PARTIAL: "일부 수정되었으나 완전하지 않음 (잔여 위험 명시)"
UNPATCHED: "코드 변경 없음 또는 수정이 무관"
RISK_ACCEPTED: "리스크 수용 결정 (조건 명시)"
structural_weakness_처리: |
Classification = Structural_Weakness인 Finding도 패치 확인 대상에 포함한다.
코드 변경으로 Impact Proof 3 Proofs가 충족되면 Confirmed_Vulnerability로 승격 가능.
Step_3_점수_재산출:
action: |
1. PATCHED Finding을 제외하고 점수를 재산출한다.
2. 이전 점수와 현재 점수를 비교한다.
note: "신규 Finding 탐색 없음 — PATCHED/UNPATCHED 변동만 반영"
Step_4_보고서:
template: "{project_root}/templates/compliance-report.template.md"
includes:
- "이전 보고서 참조"
- "Finding별 패치 상태 테이블"
- "점수 변동 (이전 → 현재)"
- "잔여 리스크 요약"
excludes:
- "신규 Finding 탐색 결과 (실행하지 않음)"
mode_표시: "Mode: patch-verify"
가이드_메시지: |
변경된 코드에서 신규 취약점도 확인하려면
--mode delta-scan으로 재실행하세요.
# ─── Mode: delta-scan ─────────────────────────────
Delta_Scan_Mode:
trigger: "--mode delta-scan"
Step_1_이전_보고서_로드:
action: "Patch_Verify_Mode.Step_1과 동일"
Step_2_패치_확인:
action: "Patch_Verify_Mode.Step_2와 동일"
Step_2.5_변경량_평가:
설명: "코드 변경 규모를 정량 평가하여 delta scan 범위를 확정한다."
method: |
1. Baseline의 commit_hash 기준으로 git diff --stat을 실행한다.
Baseline이 없으면 이전 보고서 날짜 기준 가장 가까운 커밋.
2. 전체 소스 파일 대비 변경 파일 비율을 산출한다.
3. 아래 기준으로 전수 VA 전환 여부를 판단한다.
전환_기준:
임계값_정본: |
임계값은 ch015.config.json의 ch015.compliance.deltaScanThresholds.* 키가 정본이다.
아래 키 값을 로드하여 판정한다 (하드코딩 금지):
- autoReauditRatio (변경 파일 비율 자동 권고 임계)
- askReauditRatio (변경 파일 비율 사용자 확인 임계)
- autoReauditNewFiles (신규 파일 수 자동 권고 임계)
- autoReauditDimensions (영향 차원 수 자동 권고 임계)
자동_권고:
- "변경 파일 비율 ≥ deltaScanThresholds.autoReauditRatio → full-reaudit 강력 권고"
- "신규 파일 ≥ deltaScanThresholds.autoReauditNewFiles 개 추가 → full-reaudit 강력 권고"
- "아키텍처 차원 ≥ deltaScanThresholds.autoReauditDimensions 개에 걸친 변경 → full-reaudit 권고"
사용자_확인:
- "변경 파일 비율이 askReauditRatio 이상 autoReauditRatio 미만 → 사용자에게 full-reaudit 전환 여부 확인"
- "이전 보고서의 CRITICAL/HIGH 관련 파일 변경 → 해당 차원 전수 VA 권고"
delta_유지:
- "변경 파일 비율 < askReauditRatio + 신규 파일 < autoReauditNewFiles → delta scan 유지"
출력: |
Change_Volume_Assessment:
total_source_files: N
changed_files: N
change_ratio: "X%"
new_files: N
affected_dimensions: ["A1", "A3", ...]
recommendation: "full-reaudit | 사용자_확인 | delta-scan"
reason: "[판단 근거]"
note: |
이행점검이 전수 VA를 대체할 수 없는 경우를 조기에 감지한다.
Cross Shop 사례(Compliance 88점 → VA 45점)처럼 변경량이 많은데
delta scan만 실행하면 FN 클러스터가 발생할 수 있다.
Step_3_신규_탐색:
scope: "git diff 범위로 한정된 변경 파일만"
method: |
1. 변경 파일이 속한 아키텍처 차원만 선택적으로 로드한다.
(VA SKILL의 Loading_Strategy.daily_diff 적용)
2. 변경 코드에서 신규 Finding이 있는지 탐색한다.
3. Impact Reachability Gate (Step 1.8) 적용하여 분류한다.
note: "전수 VA 전환 권고는 자동 실행이 아닌 사용자/CISO 확인 후 결정"
Step_3.5_Previously_Undetected_판정:
설명: |
Delta Scan에서 발견된 신규 Finding 중,
이전 audit에서 이미 분석된 파일에 존재했던 항목을 구분한다.
method: |
Baseline의 files_examined.list_path(00_baseline_file_list.txt)를 로드하여
해당 파일이 이전 audit에서 이미 분석된 파일인 경우:
→ Classification에 "Previously_Undetected" 태그 추가
→ 보고서에 별도 섹션(Section 3.5)으로 분리
→ 메시지: "이 Finding은 이전 진단에서 분석된 파일에 존재했으나
당시 탐지되지 않았습니다. 신규 코드 변경으로 인한 취약점이 아닙니다."
→ Compliance Score에는 반영하되, 개발팀 책임 범위가 아님을 명시
fallback: |
Baseline이 없으면:
→ Previously_Undetected 판정 불가
→ 모든 신규 Finding을 "New" 로 표시하되
"Baseline 없음 — 기존/신규 구분 불가" 경고 추가
Step_4_점수_재산출:
action: |
1. PATCHED Finding을 제외하고 점수를 재산출한다.
2. 신규 Finding을 추가하여 점수를 재산출한다.
3. Previously_Undetected Finding은 점수에 반영하되 별도 표시.
4. 이전 점수와 현재 점수를 비교한다.
Step_5_보고서:
template: "{project_root}/templates/compliance-report.template.md"
includes:
- "이전 보고서 참조"
- "Finding별 패치 상태 테이블"
- "신규 Finding (변경 코드 한정)"
- "Previously Undetected Finding (별도 섹션)"
- "점수 변동 (이전 → 현재)"
- "잔여 리스크 요약"
- "권장 조치"
mode_표시: "Mode: delta-scan"
# ─── Mode: full-reaudit ────────────────────────────
Full_Reaudit_Mode:
trigger: "--mode full-reaudit"
action: |
이행점검이 아닌 전수 VA를 실행한다.
1. CISO에게 "/ch015:run 과 동등한 전수 재진단을 실행합니다" 안내
2. 전수 VA 워크플로우(Standard_Flow)를 실행한다.
3. 완료 후 새 Baseline Snapshot을 자동 생성한다.
4. 이전 보고서와 비교하여 점수 변동을 보고한다.
note: |
full-reaudit는 compliance 보고서가 아닌 VA 보고서를 생성한다.
이전 보고서와의 비교 섹션만 추가된다.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 319 lines · 32 tokens per session scan A bc5bda171933
compliance is a command published in the GitHub repository ch015/code-pentester (4 stars, last pushed 13d ago), licensed MIT. It adds 32 tokens to every session and 3,637 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
plan_local
Create implementation plan with codebase analysis.
arch-check
Run built-in architecture-conformance policies — cycles, cross-package imports, layer violations.
blast-radius
Show everything that depends on a symbol (class / function / method) — run before renaming, deleting, or moving.
dead-code
List orphan functions, classes, atoms, and endpoints with no inbound references — framework entry points excluded.
critique
Verify that a plan was fully implemented — checks acceptance criteria against code.
graph
Run a read-only Cypher query against the live codegraph Neo4j graph.