스테이블코인 보안리뷰 체크리스트

도입

보안 리뷰 체크리스트는 코드 리뷰 전에 복사해서 쓰는 목록이지만, 그대로 체크만 하면 출시 판단에 약하다. 실무에서는 각 항목에 evidence, owner, status, blocker 여부를 붙여야 한다. 리뷰가 끝났을 때 남아야 하는 것은 "봤다"가 아니라 "어떤 근거로 출시 가능하다고 판단했는가"이다.

이 강의는 앞선 Solidity 기초, AccessControl, invariant, Slither/Echidna 결과를 하나의 review package로 묶는다. 특히 permit checkout처럼 서명과 token transfer가 섞이는 시스템은 권한, 상태, 서명, 외부 호출, 테스트, 운영을 모두 통과해야 한다.

학습 목표

• 코드 리뷰 체크리스트를 출시 차단 기준으로 바꾼다.
• 토큰/결제/운영 영역별 리뷰 증거를 남긴다.
• 잔여 위험을 owner, 만료일, 승인 조건이 있는 문서로 관리한다.

개념 설명

1. Review package 형식

체크리스트 항목은 release gate와 연결된다. High severity 또는 P0/P1 항목은 "추후 개선"으로 넘기지 않는다.

2. 권한 리뷰

권한 리뷰는 코드만 보지 않는다. Production owner가 누구인지, signer rotation은 가능한지, key compromise 때 어떤 alert가 뜨는지까지 포함한다.

3. 상태 리뷰

상태 리뷰의 핵심은 "성공 경로"가 아니라 "한 번 처리된 일이 다시 처리되지 않는가"이다. 결제에서는 idempotency가 보안이다.

4. 서명 리뷰

서명 리뷰는 보안과 UX가 만나는 영역이다. 사용자가 어떤 spender, recipient, amount, token, chain에 서명하는지 볼 수 없으면 phishing과 운영 사고 가능성이 커진다.

5. 외부 호출 리뷰

외부 호출 리뷰는 "호출이 성공하는가"보다 "실패했을 때 어떤 상태가 남는가"를 묻는다. Refund 실패가 payment success를 덮어쓰면 안 된다.

6. 테스트 리뷰

테스트는 통과 여부뿐 아니라 커버하는 위험을 보여줘야 한다. "invariant 테스트 있음" 대신 어떤 invariant를 막는지 적는다.

7. 운영 리뷰

운영 리뷰는 감사 리포트 이후에도 남는다. 배포 후 role change, pause, freeze, upgrade event를 보지 못하면 리뷰 당시 안전했던 설계도 운영 중 무너질 수 있다.

8. 출시 차단 기준

Yellow 항목은 제한 출시 조건과 owner가 있어야 한다. 예를 들어 typed data copy가 부족하면 beta 한도와 개선 기한을 둔다. 하지만 돈의 상태를 직접 깨뜨리는 항목은 Yellow가 아니라 Red다.

9. 잔여 위험 승인 양식

Accepted risk는 영구 면제가 아니다. 만료일이 지나면 다시 Red 또는 Yellow로 돌아온다.

코드로 확인하기

앞의 보안 기준을 코드와 테스트로 확인한다. 함수가 어떤 전제를 세우고, 테스트가 어떤 실패 조건을 고정하는지 함께 읽는다.

운영리뷰 패킷 YAML 템플릿

각 강의를 통해 모은 증거를 한 곳에 모아 release gate 가 읽을 수 있는 형태로 남긴다. PR 머지 조건으로 이 파일의 모든 status가 green 또는 accepted 여야 한다.

01# security-review/v1.2.0.yaml02release: v1.2.003reviewers:04  - role: security-lead05    name: alice06  - role: protocol-lead07    name: bob08sections:09  permissions:10    status: green11    evidence:12      - "test: RoleMatrix.t.sol → PASS"13      - "audit: external-audit-2026-04.pdf §3.2"14  signatures:15    status: green16    evidence:17      - "test: PermitDomain.t.sol → PASS"18      - "test: AuthorizationReplay.t.sol → PASS"19  external_calls:20    status: yellow21    evidence:22      - "transferFrom 실패 상태 처리 partial — issue #482"23    compensating_controls:24      - "merchant beta whitelist 적용"25      - "결제 한도 1k USDC"26    owner: payments-team27    expires: 2026-07-0128  invariants:29    status: green30    evidence:31      - "echidna: 20000 runs, 0 failing"32      - "foundry invariant: nightly 200 depth 통과"33release_gate:34  blocker:35    - "any section status == red"36    - "expired residual risk without re-approval"

운영CI에서 release gate 검사 — GitHub Actions

security-review yaml을 PR 머지 조건으로 강제한다. yellow는 owner와 expiry가 있어야 통과, red는 차단.

01name: release-gate02on:03  pull_request:04    paths: [security-review/**, src/**]0506jobs:07  gate:08    runs-on: ubuntu-latest09    steps:10      - uses: actions/checkout@v411      - name: Validate review packet12        run: |13          npx tsx scripts/check-review-packet.ts security-review/v1.2.0.yaml

01// scripts/check-review-packet.ts02import { readFileSync } from "node:fs";03import { parse } from "yaml";0405const packet = parse(readFileSync(process.argv[2], "utf8"));0607const errors: string[] = [];08for (const [name, section] of Object.entries(packet.sections) as [string, any][]) {09  if (section.status === "red") {10    errors.push(`${name}: status=red — release blocked`);11  }12  if (section.status === "yellow") {13    if (!section.owner) errors.push(`${name}: yellow without owner`);14    if (!section.expires) errors.push(`${name}: yellow without expiry`);15    else if (new Date(section.expires) < new Date()) {16      errors.push(`${name}: yellow expired ${section.expires}`);17    }18  }19}2021if (errors.length > 0) {22  console.error(errors.join("\n"));23  process.exit(1);24}

강의 포인트

실무 예시

운영[CONTRACT] 상황: permit checkout contract를 리뷰한다. 사용자는 EIP-712 permit에 서명하고, relayer가 permit + transferFrom을 실행해 merchant에게 결제한다.

이 표에서 Yellow는 출시 전 제한 조건을 요구한다. 예를 들어 relayer outage runbook이 draft라면 beta merchant만 허용하고 결제 한도를 낮춘다. transferFrom 실패 상태 처리가 없으면 사용자의 permit만 소모되고 결제가 실패할 수 있으므로 구현 전에는 Green으로 바꿀 수 없다.

흔한 오해와 실패 시나리오

실습 과제

1. 운영Security review package 만들기: 권한, 상태, 서명, 외부 호출, 테스트, 운영 영역별로 check, evidence, owner, status, blocker 여부를 채운다.
2. 컨트랙트Permit checkout 리뷰표 작성하기: permit checkout contract를 가정하고 domain separator, nonce, allowance, transferFrom, refund, monitoring 항목의 보안 리뷰 표를 작성한다.
3. 운영잔여 위험 승인 양식 작성하기: false positive 또는 accepted risk마다 risk statement, impact, compensating control, owner, expiry, approver를 포함한 승인 양식을 만든다.

완료 기준

1. 리뷰 범위를 권한, 상태, 서명, 외부 호출, 테스트, 운영 영역으로 나눴다.
2. 출시 차단 항목을 정의했다.
3. 잔여 위험 승인 양식을 만들었다.
4. permit checkout 예시 리뷰표를 작성했다.

근거 자료

• 보안리뷰 체크리스트: 02-보안-테스트/06-보안리뷰-체크리스트.md
• Solidity Security Considerations: https://docs.soliditylang.org/en/latest/security-considerations.html
• OpenZeppelin Contracts: Access Control: https://docs.openzeppelin.com/contracts/5.x/access-control
• OpenZeppelin Upgrades: https://docs.openzeppelin.com/upgrades/
• Foundry Book: Invariant Testing: https://book.getfoundry.sh/forge/invariant-testing
• Safe Smart Account Guards: https://docs.safe.global/advanced/smart-account-guards