cosmos-vulnerability-scanner

cosmos-vulnerability-scanner 스킬 개요

cosmos-vulnerability-scanner가 하는 일

cosmos-vulnerability-scanner 스킬은 Cosmos SDK 코드, CosmWasm 컨트랙트, IBC 통합, Cosmos EVM 스택에서 합의에 치명적인 버그를 찾도록 설계되었습니다. 단순한 코드 냄새가 아니라 체인을 멈추게 하거나, 합의를 깨뜨리거나, 상태를 불일치시키거나, 자금을 잃게 만들 수 있는 이슈에 초점을 맞춥니다. cosmos-vulnerability-scanner for Security Audit 워크플로를 사용 중이라면, “이 체인이 공격받거나 벽돌이 될 수 있는가?”를 묻는 상황에 맞는 선택이지, “코드가 깔끔한가?”를 보는 용도는 아닙니다.

누가 설치해야 하는가

커스텀 x/ 모듈, 브리지나 IBC 로직, 출시 전 app chain, 또는 온체인 가치가 큰 CosmWasm 컨트랙트를 감사한다면 cosmos-vulnerability-scanner 스킬을 사용하세요. 특히 여러 취약점 범주를 아우르는 구조화된 점검이 필요할 때, 즉흥적인 프롬프트 리뷰보다 훨씬 유용합니다. 반대로 순수 Solidity 감사, 일반적인 Go 코드 리뷰, 또는 애플리케이션 레이어 밖의 체인 구성요소에는 효용이 낮습니다.

무엇이 다른가

이 스킬은 단순한 체크리스트가 아니라, 취약점 범주별로 스캔을 정리하고 결과를 별도의 markdown으로 남깁니다. Cosmos 버그는 상태 정산, IBC 패킷 처리, 모듈 권한, EVM/Cosmos 원자성처럼 여러 표면에 걸쳐 나타나는 경우가 많기 때문에 이 점이 중요합니다. 보조 resources/ 파일은 구체적인 패턴군을 제공하므로, 막연한 “버그를 찾아라” 프롬프트보다 훨씬 실행 가능성이 높습니다.

cosmos-vulnerability-scanner 스킬 사용법

설치하고 올바른 저장소를 지정하기

cosmos-vulnerability-scanner install을 할 때는, 환경에서 사용하는 표준 skills 명령으로 에이전트 워크스페이스에 스킬을 추가한 뒤, 대상 저장소를 스캔하기 전에 스킬 파일과 연결된 지원 문서를 먼저 여세요. 실제로는 정확히 어떤 코드베이스를 분석할지, 그리고 결과를 어디에 쓸지 명시할수록 이 스킬이 더 잘 작동합니다. 기본 출력 디렉터리는 .bughunt_cosmos/지만, 워크플로에서 다른 위치를 기대한다면 반드시 바꾸는 편이 좋습니다.

스킬에 맞는 입력 형태를 주기

효과적인 cosmos-vulnerability-scanner usage 프롬프트에는 저장소 경로, 체인 유형, 앱의 목적, 그리고 이미 알고 있는 위험 지점이 들어가야 합니다. 예를 들어: “이 Cosmos SDK app chain을 커스텀 모듈, IBC 핸들러, module-account 로직에서 합의에 치명적인 이슈가 있는지 검사해 주세요. pre-blocker, msg server, keeper write, 그리고 supply, consensus, cross-chain transfer에 영향을 줄 수 있는 코드를 중점적으로 봐 주세요.” 이런 식의 요청은 “이 저장소를 검토해 주세요”보다 훨씬 낫습니다. 스캐너가 정말 중요한 코드 경로로 집중하도록 방향을 잡아주기 때문입니다.

먼저 읽어야 할 파일

SKILL.md부터 시작한 다음, 범위 변경 사항은 CHANGELOG.md에서 확인하고, resources/ 안의 관련 패턴 파일들을 읽으세요: DISCOVERY.md, VULNERABILITY_PATTERNS.md, STATE_VULNERABILITY_PATTERNS.md, IBC_VULNERABILITY_PATTERNS.md, EVM_VULNERABILITY_PATTERNS.md, COSMWASM_VULNERABILITY_PATTERNS.md. 대상이 Cosmos EVM 체인이면 EVM 파일을 먼저 읽고, 컨트랙트 비중이 크면 CosmWasm 파일을 우선하세요. 이 파일들이 실제로 무엇을 검사하는지 알려 주므로, 통째로 놓치는 버그 범주를 줄일 수 있습니다.

실용적인 감사 워크플로를 쓰기

먼저 체인을 분류하세요: 순수 Cosmos SDK인지, IBC가 활성화되어 있는지, CosmWasm이 있는지, Cosmos EVM인지부터 구분합니다. 그다음 커스텀 모듈, ABCI 훅, keeper, message server를 목록화하세요. 이 요소들이 공격 표면을 결정하기 때문입니다. 이후에는 상태 변경, 권한 검사, packet receive/acknowledgement 핸들러, 그리고 bank, staking, authz, module account를 건드리는 경로부터 우선적으로 스킬을 돌리세요. 저장소 순서대로 파일을 훑는 것보다 훨씬 좋은 결과를 줍니다.

cosmos-vulnerability-scanner 스킬 FAQ

전체 체인 감사에만 쓰는 도구인가?

아닙니다. cosmos-vulnerability-scanner 스킬은 하나의 커스텀 모듈, 하나의 IBC middleware 스택, 하나의 CosmWasm 컨트랙트 패키지 같은 부분 리뷰에도 유용합니다. 핵심은 해당 코드가 합의 상태, 토큰 이동, 또는 크로스체인 동작에 영향을 줘야 한다는 점입니다. 리뷰 대상이 그 경로에 없다면, 이 스킬은 아마 맞지 않는 도구입니다.

일반 프롬프트와 비교하면 어떤가?

일반 프롬프트도 보안 리뷰를 요청할 수는 있지만, cosmos-vulnerability-scanner는 도메인별 구조, 패턴 라이브러리, 출력 규율을 제공합니다. 그 덕분에 패킷 신뢰 오류, module-account 오남용, EVM/Cosmos 상태 불일치 같은 Cosmos 특유의 실패 모드를 놓칠 가능성이 줄어듭니다. 한 번 쓰고 끝나는 의견보다, 반복 가능한 cosmos-vulnerability-scanner guide 동작이 필요할 때 더 잘 맞습니다.

초보자도 쓰기 쉬운가?

체인 유형과 상태 전이를 정의하는 파일만 식별할 수 있다면 가능합니다. 다만 SDK 버전, IBC 스택, EVM 런타임 사용 여부, 그리고 대상이 출시 전 점검인지 실제 장애 대응인지 같은 맥락을 먼저 조금만 넣어 주면 훨씬 더 유용해집니다. 초보자는 이런 정보를 생략한 채 스캐너가 감사 경계를 알아서 추론해 주길 기대할 때 가장 많이 막힙니다.

언제 쓰지 말아야 하나?

순수 EVM/Solidity 프로젝트, wasmd가 없는 일반 Rust 컨트랙트, 또는 합의 영향이 명확히 없는 코드에는 cosmos-vulnerability-scanner를 쓰지 마세요. 문서 작업이나 프런트엔드/클라이언트 코드에도 잘 맞지 않습니다. 목표가 보안 분석이 아니라 사용성 테스트라면, 다른 워크플로를 선택하는 편이 좋습니다.

cosmos-vulnerability-scanner 스킬 개선하기

코드만 주지 말고 체인 맥락도 함께 주기

가장 좋은 결과는 체인이 무엇을 하는지 알려 줄 때 나옵니다. DEX인지, 스테이킹인지, 브리지인지, 대출인지, 아니면 범용 app chain인지 적어 주세요. 여기에 SDK 버전, ibc-go 버전, 그리고 코드가 x/evm, wasmd, ICA middleware를 사용하는지도 함께 넣으세요. 이렇게 하면 스캐너가 관련 없는 영역에 시간을 쓰지 않고, 맞는 취약점 패밀리를 우선순위로 잡을 수 있습니다.

위험한 경로를 직접 지정하기

이미 의심되는 버그가 있다면 어디를 봐야 하는지 분명히 말하세요: keeper/msg_server.go, app.go, ante.go, IBC OnRecvPacket 핸들러, module account 로직, 또는 커스텀 BeginBlocker/EndBlocker 같은 지점입니다. 입력이 구체적일수록 좋습니다. Cosmos 사고는 대개 상태 변경 지점에서 시작되기 때문입니다. 기능 영역을 알고 있다면 그것도 직접 언급하세요.

발견 사항에서 더 좁은 프롬프트로 이어가기

첫 번째 패스가 끝나면 가장 위험한 발견 하나를 골라, 더 좁은 질문으로 스킬을 다시 돌리세요. 예를 들어 한 모듈의 invariant 붕괴를 재검토하게 하거나, 한 IBC 경로의 channel trust와 packet replay 문제만 다시 확인하게 할 수 있습니다. cosmos-vulnerability-scanner usage의 정밀도를 올리면서 중복 출력에 파묻히지 않는 가장 빠른 방법입니다.

자주 놓치는 케이스를 경계하기

가장 흔한 실패 모드는 상태 전이를 너무 약하게 설명하는 것입니다. 코드는 겉보기엔 무해해 보여도 mint/burn 권한, escrow, 크로스체인 콜백, precompile 경계에 닿는 순간 위험해질 수 있습니다. 또 다른 놓침은 handler가 아니라고 해서 비합의 코드를 안전하다고 가정하는 것입니다. 모듈 헬퍼라도 합의 경로에 입력을 넘기면 충분히 위험할 수 있습니다. 상태가 어디서 바뀌는지, 그리고 누가 그 변경을 트리거할 수 있는지를 알려 줄 때 이 스킬이 가장 잘 작동합니다.