solidity-security

solidity-security 스킬 개요

solidity-security는 무엇에 쓰는 스킬인가

solidity-security 스킬은 Solidity 스마트 컨트랙트를 위한 집중형 감사 및 안전 코딩 가이드입니다. 이 스킬은 컨트랙트 로직을 에이전트가 일반적인 익스플로잇 유형 관점에서 검토하고, 더 안전한 구현 패턴을 제안하며, 코드가 프로덕션에 올라가거나 정식 감사에 들어가기 전에 왜 특정 설계가 위험한지 설명해 주길 원할 때 가장 유용합니다.

누가 이 스킬을 설치하면 좋은가

이 스킬은 다음과 같은 경우에 잘 맞습니다:

• 메인넷이나 테스트넷에 컨트랙트를 배포하는 Solidity 개발자
• 1차 리뷰를 수행하는 감사 담당자
• DeFi, 토큰, vault, 또는 admin-controlled 컨트랙트를 외부 Security Audit 전에 정리하려는 팀
• “이 코드 리뷰해줘” 수준의 범용 프롬프트보다 더 구조적인 보안 피드백을 원하는 엔지니어

반대로, non-EVM 프로젝트나 순수한 프로토콜 이코노믹스 분석에는 활용도가 떨어집니다.

사용자가 실제로 해결하려는 일

사용자가 원하는 것은 단순한 취약점 목록이 아닙니다. “이 vault에 reentrancy와 권한 문제가 있는지 봐줘” 같은 거친 목표를, 익스플로잇 경로·더 안전한 구현·수정 우선순위까지 포함하는 반복 가능한 리뷰 흐름으로 바꾸는 데 도움을 원합니다. 이 지점에서 solidity-security는 일반 프롬프트보다 강합니다.

solidity-security가 다른 점

이 스킬은 범위가 좁고 실무적입니다. 블록체인 전반에 대한 넓은 조언 대신, 다음과 같은 Solidity 핵심 실패 패턴에 집중합니다:

• reentrancy
• 산술 관련 엣지 케이스
• access control 실수
• 안전하지 않은 external call
• 보안을 고려한 구현 패턴

그래서 폭넓음보다 정확도가 중요한 상황에 잘 맞습니다.

도입 전에 알아둘 점

이 저장소는 가볍습니다. 스킬 내용은 대부분 SKILL.md에 들어 있고, 추가 규칙, 스크립트, reference 파일은 없습니다. 빠르게 도입하기엔 좋지만, 그만큼 결과물의 품질은 사용자가 제공하는 컨텍스트에 크게 좌우됩니다. “이 컨트랙트 감사해줘”만 던지면 일반론적인 지적이 나올 가능성이 높습니다. 반대로 컨트랙트 목적, 위협 모델, privileged role, 핵심 함수까지 제공하면 solidity-security skill의 활용도가 훨씬 높아집니다.

solidity-security 스킬 사용 방법

solidity-security 설치 방법

skills 호환 클라이언트에서 저장소를 통해 설치하면 됩니다. 흔히 쓰는 패턴은 다음과 같습니다:

npx skills add https://github.com/wshobson/agents --skill solidity-security

에이전트 플랫폼의 설치 방식이 다르다면, 다음 경로에서 스킬을 추가하세요:

https://github.com/wshobson/agents/tree/main/plugins/blockchain-web3/skills/solidity-security

저장소에서 먼저 읽어야 할 파일

먼저 볼 파일은 다음입니다:

• plugins/blockchain-web3/skills/solidity-security/SKILL.md

이 스킬 폴더에는 별도의 README.md, rules/, references/가 없기 때문에 SKILL.md가 사실상 전체 사용 설명서입니다. 어떤 관점으로 리뷰하는지 이해하려면 먼저 “When to Use This Skill”과 취약점 관련 섹션부터 읽는 것이 좋습니다.

이 스킬이 잘 동작하려면 어떤 입력이 필요한가

solidity-security usage의 품질은 구체적인 컨트랙트 맥락에 달려 있습니다. 가능하면 다음을 제공하세요:

• Solidity 버전
• 컨트랙트 파일 또는 핵심 코드 발췌
• 컨트랙트 목적
• 사용자 역할과 privileged role
• 자산 흐름: 누가 deposit, withdraw, mint, burn, liquidate, upgrade를 수행하는지
• 외부 연동: oracles, ERC20s, bridges, routers, callbacks
• 신뢰하는 행위자에 대한 가정
• 원하는 출력 형태: quick scan, deep audit checklist, exploit scenarios, remediations

이 정보가 없으면 스킬은 결국 일반적인 취약점 강의 수준의 답변만 내놓게 됩니다.

첫 리뷰에 적합한 프롬프트 형태

좋은 시작 프롬프트 예시는 다음과 같습니다:

“Use the solidity-security skill to review these contracts for reentrancy, access control, unsafe external calls, arithmetic or accounting mistakes, and other high-severity issues. For each finding, include impact, exploit path, affected functions, and a concrete remediation. Distinguish confirmed issues from areas needing more context.”

이 프롬프트가 효과적인 이유는 다음을 함께 요구하기 때문입니다:

• 구체적인 이슈 유형
• 우선순위가 있는 출력
• 익스플로잇 관점의 추론
• 구현 수준의 수정 제안
• 불확실성 구분

거친 목표를 완성도 높은 프롬프트로 바꾸는 법

약한 프롬프트:

• “Check this Solidity code.”

더 나은 프롬프트:

• “Use solidity-security for Security Audit preparation on this vault contract. Focus on withdrawal flow, share accounting, admin powers, pausing, upgradeability assumptions, and external token interactions. Identify critical and high findings first, then list medium-risk hardening opportunities.”

더 나은 버전은 비즈니스상 중요한 공격면으로 범위를 좁혀 주기 때문에, 신호는 높이고 군더더기는 줄여 줍니다.

감사에 권장되는 워크플로

실무적으로 유용한 solidity-security guide 흐름은 다음과 같습니다:

1. 컨트랙트 묶음을 바탕으로 위협 모델 요약을 먼저 요청합니다.
2. 함수별 위험 맵을 요청합니다.
3. 상태를 변경하는 external call 경로를 깊게 파고듭니다.
4. role 제한 함수와 초기화 로직을 검토합니다.
5. 상위 이슈에 대한 remediation 예시를 요청합니다.
6. 패치한 코드에 다시 스킬을 적용해 남은 위험을 확인합니다.

한 번에 거대한 감사 결과를 요구하는 것보다, 이런 단계형 워크플로가 대체로 더 좋은 결과를 냅니다.

특히 강조할 가치가 큰 리뷰 영역

solidity-security를 호출할 때는 다음 영역에 집중하라고 명시하는 것이 좋습니다:

• withdrawal 및 payout 함수
• callback이 가능한 토큰 상호작용
• role 이전 및 ownership 로직
• initialization 및 upgrade 경로
• accounting invariants
• oracle 또는 가격 의존성
• emergency control
• ERC20 준수에 대한 가정

얕은 프롬프트는 이런 지점의 의미 있는 리스크를 자주 놓칩니다.

이 스킬이 특히 잘 다루는 범위

소스 내용을 기준으로 보면, 이 스킬은 흔한 Solidity 취약점 유형과 안전한 구현 패턴에 가장 강합니다. 특히 reentrancy와 checks-effects-interactions 같은 방어적 코딩 습관 관련 성능이 좋습니다. 따라서 정식 검증이나 프로토콜 수준의 경제 모델링을 대체하는 도구가 아니라, 보안 중심의 코딩 및 리뷰 보조 도구로 쓰는 편이 맞습니다.

출력 품질을 높여 주는 실전 팁

더 나은 solidity-security usage 결과를 얻으려면:

• 자금 이동이 일어나는 정확한 함수를 붙여 넣고
• 어떤 role이 trusted인지, 어떤 role이 외부 통제 가능한지 표시하고
• 컨트랙트가 upgradeable인지 proxy 기반인지 적고
• 단순한 버그 이름이 아니라 exploit 성립 조건을 물어보고
• 근거가 포함된 심각도 분류를 요청하고
• 코드 사실과 가정을 분리해서 설명하라고 요청하세요

이런 작은 추가 정보들이 실제 의사결정 품질을 크게 끌어올립니다.

이 스킬에 기대하면 안 되는 것

solidity-security skill이 자동으로 다음까지 해주리라고 기대하면 안 됩니다:

• 테스트 실행
• 배포된 bytecode 검사
• 수학적 invariant 증명
• 전체 수작업 Security Audit 대체
• 언급조차 하지 않은 생태계 특화 이슈 탐지

이 스킬은 사용자가 제공하는 코드와 아키텍처 맥락을 바탕으로, 전문가형 리뷰의 골격을 잡아 주는 도구일 때 가장 효과적입니다.

solidity-security 스킬 FAQ

solidity-security는 Security Audit 준비에 좋은가?

그렇습니다. solidity-security for Security Audit은 외부 감사를 맡기기 전에 명확하거나 중간 정도로 숨겨진 Solidity 문제를 먼저 걸러내고 싶을 때 매우 적합한 활용 사례입니다. 팀이 코드를 더 단단하게 만들고, 가정을 문서화하고, 예방 가능한 지적을 줄인 상태로 감사에 들어가도록 도와줍니다.

범용 “audit my contract” 프롬프트보다 나은가?

대체로 그렇습니다. 범용 프롬프트는 스마트 컨트랙트 위험 요소를 뻔한 목록 형태로 돌려주는 경우가 많습니다. 반면 solidity-security 스킬은 에이전트에 더 좁고 선명한 보안 프레임을 제공하므로, 익스플로잇 경로, 안전한 패턴, 수정 방안의 구체성에 더 집중하는 경향이 있습니다.

solidity-security는 입문자에게도 적합한가?

네, 다만 한계는 있습니다. 입문자는 이 스킬을 통해 Solidity의 대표적인 공격면과 더 안전한 코딩 패턴을 익힐 수 있습니다. 하지만 이것을 완전한 커리큘럼처럼 받아들이면 안 됩니다. 초보자라면 각 finding을 쉬운 말로 설명하고, 안전한 대안을 함께 보여 달라고 요청하는 것이 좋습니다.

어떤 경우에 solidity-security는 잘 맞지 않는가?

다음과 같은 작업에는 적합도가 낮습니다:

• non-Solidity 체인
• 프런트엔드 지갑 보안
• 토크노믹스 설계 리뷰
• 거버넌스 게임 이론
• 코드 맥락 없이 진행하는 프로덕션 장애 대응

이런 작업에는 더 넓은 블록체인 보안 프로세스나, 다른 전문 스킬을 쓰는 편이 낫습니다.

파일 하나만 리뷰할 수 있나, 아니면 전체 코드베이스가 필요한가?

파일 하나만으로도 리뷰는 가능합니다. 다만 주변 맥락이 있을수록 결과는 좋아집니다. 예를 들어 vault 컨트랙트만 있고 token, oracle, access-control, proxy 관련 맥락이 빠져 있으면, 중요한 가정이 다른 곳에 숨어 있어도 겉으로는 안전해 보일 수 있습니다.

이 스킬은 전형적인 버그만 다루는가?

아니요. 다만 중심축은 전형적인 버그에 있습니다. 즉, 완전히 맞춤형인 프로토콜 경제 공격보다, 잘 알려진 Solidity 구현 리스크에서 가장 강한 성능을 기대하는 편이 맞습니다. 핵심 우려가 insolvency, oracle manipulation, liquidation 설계라면 그것을 분명하게 명시해야 합니다.

solidity-security 스킬을 더 잘 활용하는 방법

처음부터 위협 모델을 함께 주기

solidity-security 출력 품질을 가장 빠르게 끌어올리는 방법은 다음을 먼저 정의해 주는 것입니다:

• 공격자 능력
• trusted role
• 보호해야 할 자산
• 절대 허용할 수 없는 결과

예시:

• “Assume any external user is adversarial, admin key is trusted but fallible, and loss of user deposits is the top-risk outcome.”

이렇게 해 두면 에이전트가 스타일 피드백보다 실제 위험 이슈를 우선하게 됩니다.

코드만이 아니라 invariant도 제공하기

좋은 입력에는 다음과 같은 시스템 규칙이 포함됩니다:

• total shares should never exceed claimable assets
• only governance can change fee parameters
• user withdrawals must not depend on untrusted callbacks

이처럼 invariant를 제공하면, 스킬은 단순히 문법 패턴만 훑는 것이 아니라 의도된 동작과 실제 로직이 맞는지 비교할 수 있습니다.

exploit narrative를 요청하기

흔한 실패 패턴 중 하나는 중요성이 입증되지 않은 finding 목록만 평평하게 나오는 것입니다. 이를 개선하려면 다음을 요청하세요:

• 진입 조건
• 공격 단계
• 예상 영향
• 현실적인 이슈인지, 이론적 가능성에 그치는지

이렇게 해야 solidity-security skill이 단순 linter가 아니라 감사자처럼 추론하게 됩니다.

remediation 요청을 구체적으로 만들기

“이거 어떻게 고치죠?”만 묻지 마세요. 대신 다음을 요청하세요:

• 최소 수정 패치
• 더 안전한 설계 대안
• 각 수정안의 tradeoff
• 패치가 gas cost나 UX를 바꾸는지 여부

구체적인 remediation 프롬프트일수록, 뻔한 secure-coding 조언보다 훨씬 실행 가능한 결과를 얻을 수 있습니다.

패치한 코드로 다시 돌리기

첫 번째 패스가 끝난 뒤에는 수정한 함수나 컨트랙트를 붙여 넣고 다음을 물어보세요:

• 어떤 위험이 제거되었는지
• 어떤 잔여 위험이 남아 있는지
• 수정이 새로운 엣지 케이스를 만들었는지
• 어떤 테스트를 추가해야 하는지

도입 후 solidity-security install 시간을 가장 효율적으로 쓰는 방법 중 하나가 바로 이 재검토 단계입니다.

자주 발생하는 실패 패턴 주의하기

이 스킬을 써도 다음 문제는 여전히 경계해야 합니다:

• 추정성 취약점을 과장하는 것
• inherited contract에 숨은 가정을 놓치는 것
• role 관리 세부사항을 무시하는 것
• 실제 핵심 문제가 accounting 설계인데도 표준 reentrancy 조언만 하는 것
• 모든 external call을 똑같이 위험하다고 취급하는 것

이런 오류는 inheritance 맥락을 제공하고, 각 주장마다 정확히 어떤 함수 경로를 근거로 삼는지 적으라고 요청하면 줄일 수 있습니다.

더 깊은 리뷰를 위한 더 나은 프롬프트

강력한 2차 프롬프트 예시는 다음과 같습니다:

“Use solidity-security to review only the withdrawal, reward-claim, and admin-setter paths. Ignore gas micro-optimizations. For each issue, cite the function, state variable, attacker capability required, exploit sequence, and the safest realistic remediation for this codebase.”

이 프롬프트가 잘 먹히는 이유는 범위와 출력 형식을 동시에 제약하기 때문입니다.

테스트와 수작업 리뷰를 함께 쓰기

가장 좋은 워크플로는 스킬만 단독으로 쓰는 방식이 아닙니다. solidity-security로 가설을 만들고, 다음으로 검증하세요:

• unit tests
• invariant tests
• fuzzing
• manual line-by-line review

이 조합은 일반 프롬프트만 쓰는 방식이나, 코드만 정적으로 읽는 방식보다 훨씬 강합니다.

이 스킬이 실제로 도움이 되는지 판단하는 법

solidity-security guide가 제대로 작동하고 있다면 다음에 도움이 되어야 합니다:

• 가장 위험한 함수를 더 빨리 식별하고
• exploit 가능성을 더 명확히 설명하고
• 더 나은 패치 후보를 만들고
• 외부 감사자에게 더 정제된 질문을 준비하고
• 범용 프롬프트의 추측성 시행착오를 줄이는 것

두 번 정도 반복해도 출력이 계속 모호하다면, 원인은 설치 자체보다 컨트랙트 맥락이 부족한 경우가 대부분입니다.