멀티클라이언트 보안 감사를 위한 사양‑체크리스트 자동화 프레임워크 SPECA

초록

SPECA는 자연어 사양을 구조화된 체크리스트로 변환하고, 이를 다수의 구현체에 매핑해 교차 검증을 수행한다. 이론·실험을 이더리움 Fusaka 업그레이드 감사에 적용해 54개의 제출 중 17건이 유효했으며, 그 중 76.5%가 교차‑구현 체크리스트 재사용으로 발견되었다. 오류 보고의 56.8%는 위협 모델 불일치에서 비롯됐으며, 사양‑중심 체크리스트와 명시적 위협 모델링이 false positive를 크게 감소시킨다.

상세 분석

SPECA는 사양‑대‑구현 정합성을 검증하기 위해 두 단계 파이프라인을 제시한다. 1) Knowledge Structuring 단계에서는 LLM 기반 추출기로 RFC 2119‑키워드(MUST, SHOULD 등)를 포함한 규정문을 식별하고, 고유 ID와 원문 위치를 부여한 구조화된 요구사항 데이터베이스를 만든다. 동시에 50여 개의 취약점 패턴을 수집한 Pattern Database와, 키워드‑검색 후 LLM‑보강 의미 매핑을 통해 요구사항‑코드 연관성을 자동 연결한다. 2) Systematic Auditing 단계에서는 세 가지 전략을 병행한다. Strategy A는 정적 분석·심볼릭 실행 등을 활용해 각 구현체가 체크리스트 항목을 충족하는지 직접 검증한다. Strategy B는 한 구현체에서 발견된 위반 패턴을 추상화해 다른 구현체에 동일 패턴을 탐색·검증함으로써 ‘semantic blind spot’—즉, 모든 구현체가 동일한 오해를 공유해 차이점이 드러나지 않는 상황—을 보완한다. 이때 패턴 추상화는 코드 구조·데이터 흐름을 보존하면서 구현체 간 차이를 최소화하도록 설계되었다.

실제 이더리움 Fusaka 감사에서는 11개의 프로덕션 클라이언트를 대상으로 54개의 보고서를 수집했으며, 유효 보고 17건 중 13건(76.5%)이 Strategy B에 의해 발견되었다. 이는 체크리스트 기반 1→N 재사용이 다중 구현체 환경에서 확장성을 크게 향상시킨다는 강력한 실증이다. 반면, 37건의 무효 보고를 코딩 분석한 결과 56.8%가 위협 모델 불일치(신뢰 경계·범위 오해)에서 비롯된 것으로 드러났다. 이는 사양 자체는 정확하더라도 감사 규칙과 보고자의 가정이 일치하지 않을 경우 false positive가 급증한다는 점을 강조한다.

또한, 고위·중위 위험도 결함이 전혀 탐지되지 않은 V1 배포에서는 누락 원인이 사양 세부사항·암묵적 가정(57.1%), 타이밍·동시성(28.6%), 외부 라이브러리 의존성(14.3%)으로 구분되었다. 이러한 오류 유형은 정적·동적 분석만으로는 포착하기 어려운, 사양‑코드 간 미묘한 의미 차이와 실행 환경 의존성을 반영한다.

SPECA의 에이전트 구현은 기존 LLM‑기반 감사 도구(RFCAudit 등)와 달리, 체크리스트와 위협 모델을 명시적 아티팩트로 관리함으로써 검증 과정에서 인간 전문가가 10분 내에 핵심 위반을 확인하고, 전체 보고서 작성에 평균 40분만 소요하도록 효율성을 극대화한다. 이는 인간 감사 비용을 크게 절감하면서도, 높은 정확도(상위 4% 인간 감사자 수준)와 재현성을 확보한다는 점에서 실용적 가치가 크다.