Pre-Model Representation Failures in GNN-Based Smart Contract Vulnerability Detection
본 논문은 GNN 기반 스마트 계약 취약점 탐지기에 대한 실패 분석을 제시하며, 하드코딩된 변수 화이트리스트, 구조적 모호성, 의미론적 노드의 누락과 같은 그래프 표현 계층의 결정적인 결함이 동일한 코드가 서로 다른 그래프를 생성하게 만들고 완전히 악용 가능한 계약을 안전한 것으로 오분류하게 하여, 결과적으로 후속 모델 개선을 효과 없게 만들 수 있음을 밝힌다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
탈중앙화 금융의 디지털 세계에서, 돈은 스마트 계약이라고 불리는 자기 실행형 컴퓨터 프로그램을 통해 이동합니다. 이 프로그램들은 모든 거래를 기록하는 공공 장부인 블록체인 위에 존재하며, 인간 중개자 없이 실제 자산을 처리하도록 설계되었습니다. 이러한 계약들은 가치 있는 자금을 관리하기 때문에, 단 하나의 숨겨진 결함만으로도 즉각적이고 되돌릴 수 없는 도난으로 이어질 수 있습니다. 이를 방지하기 위해, 연구자들은 코드를 스캔하여 취약점이 악용되기 전에 찾아내는 자동화된 시스템을 개발했습니다. 한 가지 인기 있는 접근 방식은 그래프 신경망(graph neural network)이라 알려진 유형의 인공지능을 사용하는 것입니다. 이 방식이 어떻게 작동하는지 이해하려면, 복잡한 코드 조각을 점과 선으로 연결된 지도로 바꾼다고 상상해 보십시오. 여기서 점은 프로그램의 구성 요소를 나타내고, 선은 그 요소들이 어떻게 상호작용하는지를 보여줍니다. 그러면 컴퓨터는 이 지도를 연구하여 프로그램이 안전한지 아니면 위험한지를 결정합니다. 코드를 단순히 한 줄씩 읽는 것이 아니라 코드의 구조를 살펴봄으로써, 이러한 시스템이 인간이 놓칠 수 있는 미묘한 함정을 포착할 수 있기를 기대하는 것입니다.
카네기 멜론 대학교 아프리카 캠퍼스의 연구팀은 이 접근 방식의 근간 자체를 테스트하기로 했습니다. 그들은 재진입성(reentrancy)이라고 불리는 위험한 결함을 찾아내는 데 널리 사용되는 GNNSCVulDetector라는 특정 시스템에 집중했습니다. 이 결함은 프로그램이 자신의 기록을 업데이트하기 전에 돈을 외부로 보낼 때 발생하며, 이를 통해 공격자가 시스템을 속여 원래 지급되어야 할 금액보다 더 많은 금액을 지급받게 할 수 있습니다. 연구진은 컴퓨터가 얼마나 잘 학습하는지 또는 얼마나 빠르게 생각하는지를 테스트한 것이 아닙니다. 대신, 컴퓨터가 데이터를 보기 전 단계인, 소스 코드를 지도로 변환하는 과정을 조사했습니다. 그들은 지도가 원래의 코드를 정확하게 반영하고 있는지 알고 싶었습니다. 그들의 조사 결과는 충격적인 진실을 드러냈습니다. 바로 지도 제작 과정 자체가 어떤 학습으로도 해결할 수 없는 방식으로 망가져 있었다는 사실입니다.
그들이 발견한 첫 번째 문제는 이 시스템이 코드의 단순한 변화에 쉽게 속는다는 것이었습니다. 연구진은 이미 알려진 취약한 계약을 가져와서, 계약 자체의 이름, 함수의 이름, 그리고 돈을 담고 있는 변수의 이름을 바꾸는 식으로 구성 요소를 변경했습니다. 또한 아무런 기능도 하지 않는 코드 줄들을 추가하여 파일을 복잡하게 만들었습니다. 일반적인 세상이라면 이러한 변화는 프로그램의 외형을 다르게 만들겠지만, 내부의 위험한 로직은 동일하게 유지될 것입니다. 그러나 연구진이 원본과 수정된 버전을 모두 시스템에 입력했을 때, 컴퓨터는 마지막 1바이트까지 동일한 지도를 생성했습니다. 시스템은 두 버전 사이의 차이를 구별하지 못했습니다. 이는 공격자가 탐지기가 어떻게 작동하는지나 어떤 데이터로 학습되었는지 알 필요도 없이, 단순히 변수 이름을 바꾸는 것만으로 보안 검사를 우회할 수 있음을 의미합니다. 시스템은 실제 코드의 구조를 보지 못하고, 오직 고정된 이름의 패턴만을 보고 있었던 것입니다.
더 깊이 파고든 결과, 연구진은 왜 이런 일이 발생하는지 발견했습니다. 지도를 만드는 도구는 인간 프로그래머처럼 코드를 읽고 이해하는 것이 아닙니다. 대신, 이 도구는 인식할 수 있도록 허용된 47개의 특정 변수 이름 목록에 의존합니다. 만약 코드가 이 목록에 있는 이름을 사용하면 도구는 지도에 노드를 생성합니다. 만약 이름이 목록에 없다면, 도구는 이를 무시하거나 일반적인 자리 표시자(placeholder)를 만듭니다. 연구진은 네 개의 서로 다른 계약을 만들어 이 테스트를 진행했는데, 이 계약들은 모두 동일한 위험한 결함을 가지고 있었지만 돈 변수의 이름은 서로 달랐습니다. 변수 이름이 목록과 완벽히 일치할 때 지도는 정상적으로 보였습니다. 이름이 약간만 달라도 지도는 혼란스러운 방식으로 변했습니다. 이름이 목록에 없는 완전히 새로운 이름일 경우, 지도는 중요한 세부 정보를 잃고 퇴화되었습니다. 최악의 경우, 일치하는 이름이 하나도 없을 때 도구는 원래 코드에는 존재하지 않는 부분을 지어내어, 오직 자신의 내부 규칙에 기반한 구조를 만들어냈습니다. 이는 지도의 품질이 프로그래머가 승인된 47개의 이름 중 하나를 사용했는지 여부에 전적으로 달려 있음을 의미했습니다.
두 번째 주요 실패는 공격자를 나타내는 지도의 특정 부분과 관련되었습니다. 시스템 설계상, 외부 호출자(external caller)—즉, 공격을 유발하는 외부 엔티티—를 나타내는 노드가 존재해야 합니다. 재진입성 결함이 존재하려면 이 외부 호출자가 지도에 반드시 나타나야 합니다. 연구진은 문헌상 가장 유명한 취약한 계약 사례에서 이 노드가 완전히 누락되어 있음을 발견했습니다. 도구가 공격자와 취약한 함수 사이의 연결을 그려내지 못한 것입니다. 이는 학습 데이터의 다른 계약들에서는 이 연결이 나타났던 것을 고려할 때, 지도의 설계 한계가 아니라 도구가 지도를 구축하기로 결정하는 과정에서의 불일치였습니다. 이 연결이 누락되었기 때문에, 컴퓨터는 공격 패턴이 코드에 분명히 존재함에도 불구하고 그 패턴을 볼 방법이 없었습니다.
이 누락된 부분이 시스템 실패의 원인임을 증в하기 위해, 연구진은 완전히 악용 가능한 재진입성 결함을 포함한 최소한의 목적 지향적 계약을 구축했습니다. 그들은 첫 번째 문제인 이름 변경 문제가 간섭하지 않도록 승인된 목록에 있는 변수 이름을 사용했습니다. 그들은 이 계약을 시스템에 입력했습니다. 결과는 명확한 오분류였습니다. 시스템은 이 위험한 계약을 '안전함'으로 분류했습니다. 이유는 단순하고 직접적이었습니다. 도구가 외부 호출자와 취약한 함수 사이의 연결을 그리는 데 실패했기 때문에, 지도는 위협을 식별하는 데 필요한 핵심 신호를 갖추지 못했습니다. 컴퓨터는 계산을 틀린 것이 아니었습니다. 단지 불완전한 그림을 가지고 있었을 뿐입니다. 올바른 결정을 내리는 데 필요한 정보가 컴퓨터가 생각을 시작하기도 전에 이미 폐기된 것입니다.
이러한 발견은 이전 연구에서 보고된 높은 정확도 수치들이 오해의 소지가 있음을 시사합니다. 시스템이 잘 작동했던 이유는 테스트 데이터가 우연히 도구가 인식할 수 있는 특정 이름과 패턴을 사용했기 때문입니다. 서로 다른 명명 규칙과 구조를 가진 코드가 쓰이는 실제 환경에서, 이러한 시스템은 소리 없이 실패할 수 있습니다. 연구진은 인공지능 모델 자체를 개선하는 것으로는 이 문제를 해결할 수 없다고 강조합니다. 아무리 더 나은 학습이나 더 많은 데이터를 제공하더라도, 애초에 지도가 잘못 그려졌다면 해결할 수 없습니다. 해결책은 코드를 지도로 변환하는 방식을 바꾸는 것, 즉 단순한 이름 매칭을 넘어 코드가 실제로 무엇을 하는지에 대한 깊은 이해로 나아가는 것입니다. 기초가 고쳐지지 않는 한, 그 위에 구축된 보안 시스템은 자신이 막으려 했던 바로 그 공격에 계속해서 취약할 수밖에 없습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.