security-bounty-hunter

security-bounty-hunter 스킬 개요

security-bounty-hunter는 실제 저장소에서 버그 바운티로 이어질 만한 취약점을 찾는 데 초점을 둔 스킬입니다. 원격에서 도달 가능하고, 사용자 입력으로 제어되며, 트리아지 단계에서 살아남을 가능성이 높은 이슈를 특히 중시합니다. Security Audit 작업을 할 때, 단순히 “버그를 찾아라” 수준의 범용 프롬프트보다 더 나은 것이 필요하고, 소음 많은 로컬 전용 문제보다 보고 가능한 발견에 무게를 둔 워크플로가 필요한 사람에게 가장 적합합니다.

security-bounty-hunter가 찾도록 설계된 것

security-bounty-hunter 스킬은 SSRF, 인증 우회, SQL injection, command injection, path traversal, 원격 역직렬화, 업로드 후 RCE로 이어지는 체인, 자동 트리거 XSS 같은 실제로 악용 가능한 경로를 우선합니다. 따라서 핵심 질문이 “이 발견이 책임 있는 공개나 바운티 제출을 뒷받침할 수 있는가”일 때 유용합니다.

누가 사용해야 하나요

애플리케이션, 패키지, API를 검토하면서 실제로 보안 보고서가 성립할 가능성이 있는지 빠르게 판단해야 한다면 이 security-bounty-hunter 스킬을 사용하세요. 특히 리서처, 레드팀 담당자, 버그 바운티 헌터, 그리고 코드베이스에 고임팩트 노출이 있는지 확인하려는 엔지니어에게 잘 맞습니다.

무엇이 다른가요

이 스킬의 핵심 가치는 판단력입니다. 기술적으로는 안전하지 않지만 실제 제출에서는 거의 의미가 없는 패턴은 모델이 무시하도록 유도합니다. 그 결과 원격에서 도달 가능한 공격 경로, 악용 가능성, 영향 범위에 집중하게 되며, 바로 그 지점이 보통 바운티 수락을 가로막는 이유입니다.

security-bounty-hunter 스킬 사용 방법

설치하고 활성화하기

스킬 관리자에서 security-bounty-hunter 설치 명령을 실행한 뒤, 평가하려는 저장소를 지정하세요. 중요한 점은 작업을 광범위한 코드 리뷰가 아니라 바운티 관점을 둔 보안 감사로 명확히 설정하는 것입니다.

올바른 입력 주기

구체적인 대상, 범위, 목표부터 시작하세요. 좋은 프롬프트 예시는 다음과 같습니다: “이 Node API에서 원격으로 도달 가능한 취약점을 감사해 주세요. 바운티로 인정될 수 있는 이슈를 우선하고, 인증 우회, injection, 파일 접근, SSRF를 중점적으로 보세요. 스타일 문제나 영향이 낮은 로컬 전용 발견은 제외하세요.” 이런 입력은 스킬이 바운티 리뷰어와 비슷한 기준으로 판단하도록 돕습니다.

먼저 읽어야 할 파일

SKILL.md부터 시작한 다음, README.md, AGENTS.md, metadata.json, 그리고 존재한다면 rules/, resources/, references/, scripts/ 폴더를 확인하세요. 이 저장소에서는 핵심 소스가 SKILL.md이며, 별도의 지원 폴더는 없으므로 실제로 유용한 가이드는 대부분 스킬 본문에 들어 있습니다.

빠르게 범위를 좁히는 워크플로 사용하기

좋은 security-bounty-hunter 사용 흐름은 다음과 같습니다: 애플리케이션 표면을 파악하고, 신뢰 경계를 찾고, 사용자 입력이 민감한 작업으로 이어지는 경로를 추적한 뒤, 특권 접근 없이도 그 경로가 실제로 도달 가능한지 시험하는 것입니다. 출력이 단순한 이론적 취약성보다 악용 가능성, 노출도, 제출 가치를 더 잘 반영하도록, “bounty-worthiness”를 명시해서 요청하세요.

security-bounty-hunter 스킬 FAQ

security-bounty-hunter는 숙련된 감사자만 써야 하나요?

아닙니다. 대상 스택을 이미 알고 있거나 저장소를 명확하게 설명할 수 있다면 초보자도 충분히 사용할 수 있습니다. 이 스킬은 구체적인 코드베이스를 주고, 추상적인 하드닝 조언보다 실제 악용 경로에 집중해 달라고 요청할 때 가장 큰 효과를 냅니다.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트는 대체로 넓은 체크리스트를 만들어 냅니다. 반면 security-bounty-hunter 스킬은 더 좁습니다. 원격에서 도달 가능하고, 영향이 크며, Security Audit이나 버그 바운티 맥락에서 수락될 가능성이 높은 발견 쪽으로 분석을 편향시킵니다.

언제 사용하면 안 되나요?

일반적인 보안 코딩 가이드, 컴플라이언스 검토, 전체 아키텍처 평가가 필요하다면 사용하지 마세요. 또한 보고 가능한 취약점의 우선순위 목록보다 모든 사소한 이슈를 빠짐없이 훑는 것이 목적이라면 적합하지 않습니다.

어떤 저장소에서나 잘 작동하나요?

웹앱, API, 서비스, 그리고 요청 처리나 데이터 흐름이 분명한 코드베이스에서 가장 잘 작동합니다. 정적 콘텐츠, 아주 작은 유틸리티, 또는 실제로 감사할 만한 공격 표면이 없는 저장소에서는 효용이 떨어집니다.

security-bounty-hunter 스킬 개선 방법

범위와 제약을 더 구체적으로 주기

가장 좋은 security-bounty-hunter 결과는 중요한 것을 분명히 지정할 때 나옵니다. 대상 언어, 진입점, 인증 모델, 배포 환경, 그리고 무엇이 범위 안에 들어가는지를 명확히 하세요. 예를 들어 “인터넷에 노출된 엔드포인트만 검토하고 내부 전용 관리자 도구는 제외해 주세요”라고 하면, 모호하게 “취약점을 찾아라”라고 하는 것보다 우선순위가 훨씬 잘 잡힙니다.

보고서 제출에 바로 쓸 수 있는 출력 요청하기

유용한 Security Audit 결과를 원한다면, 증거, 악용 가능성, 영향, 그리고 왜 그 이슈가 바운티 대상인지까지 요청하세요. 그러면 스킬이 CWE 레이블만 나열하는 대신 공격 경로를 설명하도록 유도할 수 있습니다.

저장소 이름만 주지 말고 코드 경로를 함께 주기

이미 의심스러운 파일, 핸들러, 라우트를 알고 있다면 프롬프트에 함께 넣으세요. 예를 들어 “src/routes/upload.ts와 그 호출 경로를 모두 살펴서 path traversal 또는 SSRF를 확인해 주세요”라고 하면, 무작정 전체를 뒤지게 하는 것보다 훨씬 강력합니다.

첫 번째 결과를 바탕으로 반복하기

첫 출력에서는 가치가 낮은 후보를 걸러내고, 가장 유력한 항목에 대해 더 깊은 검증을 요청하세요. 가장 흔한 실패 방식은 범위를 너무 넓게 잡는 것이고, 가장 좋은 해결책은 한 번에 하나의 공격 클래스, 하나의 신뢰 경계, 하나의 엔드포인트 계열로 탐색을 좁히는 것입니다.