solana-vulnerability-scanner

solana-vulnerability-scanner skill 개요

solana-vulnerability-scanner는 일반적인 Rust 코드 리뷰에서는 놓치기 쉬운 Solana 보안 이슈를 집중적으로 점검하는 감사용 skill입니다. 특히 배포 전의 네이티브 Solana 프로그램이나 Anchor 프로그램을 검토하는 엔지니어, 감사자, 보안팀에 적합하며, 코드에 CPI, PDA 로직, signer 검사, account ownership 검사, instruction introspection이 포함될 때 가장 큰 가치를 냅니다.

solana-vulnerability-scanner skill은 범용 스마트 컨트랙트 linter가 아닙니다. Solana에서 자주 발생하는 고위험 실수를 소수의 핵심 패턴으로 좁혀서 드러내고, 프로그램을 출시해도 안전한지 아니면 더 깊은 수동 검토가 필요한지 판단하도록 돕는 데 초점이 맞춰져 있습니다.

이 skill이 잡아내는 문제

이 저장소는 arbitrary CPI, 부적절한 PDA 검증, signer 또는 ownership 검사 누락, sysvar spoofing 같은 6가지 핵심 취약 패턴에 초점을 맞춥니다. 그래서 solana-vulnerability-scanner는 “이 코드가 컴파일되는가?”보다 “공격자가 Solana의 account 모델에서 신뢰 가정을 우회할 수 있는가?”가 더 중요한 상황에서 유용합니다.

가장 잘 맞는 사용 사례

출시가 임박한 프로그램의 Security Audit, 업그레이드 검토, 프로토콜 통합, 그리고 account가 특정 program, authority, sysvar를 가리킨다고 신뢰하는 모든 코드 경로에 solana-vulnerability-scanner를 사용하세요. 반대로 일반적인 비즈니스 로직 리뷰나 Solana가 아닌 Rust crate에는 효용이 떨어집니다.

무엇이 다른가

solana-vulnerability-scanner의 가치는 Solana 전용 판단 로직에 있습니다. 모든 Rust 저장소에 똑같이 적용되는 조언에 시간을 쓰지 않고, 실제 익스플로잇 가능성을 좌우하는 account 검증과 CPI 경계에 집중하게 해줍니다.

solana-vulnerability-scanner skill 사용 방법

skill 설치하기

다음 명령으로 solana-vulnerability-scanner를 설치합니다:

npx skills add trailofbits/skills --skill solana-vulnerability-scanner

이 설치 경로가 중요한 이유는 이 skill이 trailofbits/skills 저장소의 plugins/building-secure-contracts/skills/solana-vulnerability-scanner 아래에 있기 때문입니다. 즉, 일반적인 코딩 보조 프롬프트가 아니라 보안 감사 워크플로로 접근해야 합니다.

적절한 대상과 범위를 먼저 주기

solana-vulnerability-scanner를 가장 잘 쓰는 방법은 감사 대상, 즉 저장소 이름, program entrypoint, framework 유형, 그리고 관심 있는 trust boundary를 분명히 제시하는 것입니다. 예를 들어 다음처럼 구체적으로 주는 편이 좋습니다: “이 Anchor 프로그램에서 arbitrary CPI, PDA derivation 실수, initialize와 withdraw 흐름의 signer 체크 누락을 점검해 주세요.”

반대로 “이 Solana 앱을 스캔해줘”처럼 뭉뚱그린 요청은 중요한 account와 instruction을 놓치기 쉽습니다.

먼저 어떤 파일을 읽을지 정하기

solana-vulnerability-scanner를 설치해 검토할 때는 먼저 SKILL.md를 보고, 그다음 resources/VULNERABILITY_PATTERNS.md를 확인하세요. 이 리소스 파일에는 skill이 기반으로 삼는 구체적 체크 항목과 예시가 들어 있어, 파일명만 보고 추측하는 것보다 훨씬 실용적입니다.

또한 다음을 정의하는 program 파일도 훑어보세요:

• invoke() 또는 invoke_signed()를 사용하는 CPI 호출
• Anchor의 #[derive(Accounts)] 구조체
• PDA derivation과 seed 검증
• account ownership 및 signer constraint
• sysvar 또는 program account 검사

실전 워크플로

skill은 두 단계로 쓰는 것이 좋습니다. 첫 번째로는 잠재적인 취약점 유형과 영향을 받는 instruction을 식별하게 하세요. 두 번째로는 각 플래그가 붙은 경로를 account 단위로 다시 보게 하세요. 예를 들어 어떤 account가 사용자 제어인지, 기대되는 program ID가 무엇인지, validation이 CPI나 state 변경보다 먼저 이뤄지는지까지 확인하는 방식입니다.

좋은 프롬프트 예시는 다음과 같습니다:
“solana-vulnerability-scanner의 6가지 핵심 취약점 기준으로 이 Solana/Anchor instruction들을 검토해 주세요. account validation, CPI target, PDA seed, sysvar trust에 집중하고, instruction별로 findings를 정리한 뒤 exploitability와 false positive 가능성도 설명해 주세요.”

solana-vulnerability-scanner skill FAQ

solana-vulnerability-scanner는 Anchor 전용인가요?

아닙니다. 이 skill은 네이티브 Solana Rust 프로그램과 Anchor 기반 프로그램을 모두 다룹니다. 다만 Anchor 코드는 constraint를 더 선언적으로 표현하는 경우가 많아서, 검토 초점은 constraint가 충분한지, 그리고 program과 account type이 제대로 제한되는지로 옮겨갑니다.

일반 코드 리뷰 프롬프트와 무엇이 다른가요?

일반 프롬프트도 수상한 로직을 찾아낼 수는 있지만, solana-vulnerability-scanner는 Solana의 account 모델과 CPI, PDA 처리, account validation을 공격하는 방식에 맞춰져 있습니다. 그 결과 Solana 보안 감사에서 가장 중요한 문제를 더 잘 포착합니다.

초보자도 쓰기 쉬운가요?

네, program entrypoint와 주요 instruction account를 식별할 수 있다면 충분합니다. 초보자는 solana-vulnerability-scanner를 전체 저장소를 한 번에 감사하는 도구가 아니라, 안내형 체크리스트로 쓰는 편이 가장 효과적입니다. 먼저 플래그가 붙은 instruction을 보고, 그다음 해당 부분에 대해 후속 질문을 이어가는 방식이 좋습니다.

언제는 쓰지 않는 게 좋나요?

토크노믹스, 비즈니스 로직, 거버넌스 설계까지 solana-vulnerability-scanner 하나로 다 해결하려고 하면 안 됩니다. 이 skill은 보안에 치명적인 Solana 패턴에는 강하지만, 더 넓은 프로토콜 정확성이나 경제 모델링에는 목적이 맞지 않습니다.

solana-vulnerability-scanner skill 개선 방법

정확한 instruction 경로를 알려주기

품질을 가장 크게 끌어올리는 방법은 instruction 이름, 기대되는 authority, account 역할을 정확히 적어주는 것입니다. “내 프로그램을 확인해줘”보다, 어떤 handler를 검토할지와 어떤 account가 trusted, mutable, signer-gated, program-owned여야 하는지까지 지정하세요. 그래야 solana-vulnerability-scanner가 실제 노출과 무해한 plumbing을 구분할 수 있습니다.

trust assumption을 먼저 적기

어떤 account가 token program, system program, metadata program, 혹은 특정 PDA여야 한다면 그 점을 명시하세요. user-supplied account가 허용되는 경우도 함께 적어야 합니다. 많은 Solana 버그는 결국 validation 누락 버그이므로, trust assumption이 선명할수록 solana-vulnerability-scanner의 출력도 정밀해집니다.

결과만 말고 exploitability를 물어보기

solana-vulnerability-scanner를 더 잘 쓰려면, 단순한 findings가 아니라 각 문제의 attack path와 익스플로잇 성립 조건까지 요청하세요. 이렇게 하면 output이 “스타일 문제”와 “보안 버그”를 구분하게 되며, Security Audit 워크플로에 꼭 필요한 정보가 나옵니다.

구체적인 코드 구간으로 반복 검토하기

첫 번째 패스에서 CPI나 PDA 패턴이 플래그되면, 해당 function과 그 Accounts 구조체만 범위를 좁혀 다시 검토하세요. 한 번에 하나의 instruction으로 범위를 줄인 뒤, account constraint, program ID, seed가 의도한 trust model과 완전히 일치하는지 확인하는 방식이 가장 좋은 결과를 냅니다.