Automated Vulnerability Injection in Smart Contracts Using Large Language Models

Luca Migliaccio; Roberto Natella; Naghmeh Ivaki; Nuno Laranjeiro; Marco Vieira

Source-linked AI summary

Automated Vulnerability Injection in Smart Contracts Using Large Language Models

Luca Migliaccio, Roberto Natella, Naghmeh Ivaki, Nuno Laranjeiro, Marco Vieira

arXiv:2609.02624v12026년 9월 2일cs.SEcs.AIcs.CR

TL;DR

known ground truth가 포함된 라벨 데이터셋이 희소하기 때문에 smart-contract 취약점 탐지기를 평가하기 어렵다. 이 논문은 LLM을 사용해 Solidity contract에 취약점을 주입하고 검증하며, 193개의 중복되지 않은 주입 중 32개(16.58%)만 모든 검증 단계를 통과하고 analyzer의 탐지 범위도 불완전하고 고르지 않음을 보인다.

문제
효과적인 도구 평가에 중요함에도 known ground truth가 포함된 smart-contract 데이터셋이 희소하기 때문에 취약점 탐지기를 평가하기 어렵다.
방법
이 접근법은 LLM을 사용해 주입 가능성을 평가하고 취약점을 주입한 다음, compilation, execution, business logic, vulnerability 검사를 통해 contract를 검증한다.
결과
중복되지 않은 주입 contract 193개 중 32개(16.58%)가 모든 검증 단계를 통과했으며, 구조적으로 단순한 contract와 국소화된 취약점 패턴에서 성공률이 가장 높았다.
시사점 및 한계
검증된 contract는 세 가지 static analyzer가 주입된 결함에 대해 상호보완적이지만 불완전하고 고르지 않은 탐지 범위를 제공함을 보여준다.
시사점 및 한계
이 case study는 14개의 SmartBugs contract를 사용하므로, 결과가 더 크거나 다양한 contract 집합에 일반화되지 않을 수 있다.

Abstract

from arXiv · show

Assessing vulnerability detection tools for smart contracts requires datasets with known ground truth, yet such datasets are scarce and difficult to build by hand. We propose an approach that uses Large Language Models (LLMs) to automatically inject vulnerabilities into Solidity smart contracts, and demonstrate it in a case study targeting 49 vulnerability types from OpenSCV. Injected contracts are validated through a multi-step pipeline checking compilation, execution, business logic, and the presence of the intended vulnerability. Applied to real-world contracts from SmartBugs, LLMs generate nearly 1,000 candidate variants; after deduplication and validation, 32 confirmed vulnerable contracts spanning 25 vulnerability types survive (a 16.58% survival rate). Surviving contracts concentrate in structurally simpler targets and vulnerability types with localized syntactic patterns. We report practical challenges including LLMs' non-determinism and the difficulty of preserving contract semantics. We then use the validated contracts to assess three static analyzers, revealing complementary and incomplete coverage profiles. Results show that LLM-based vulnerability injection is feasible, while exposing key limitations in scalability and diversity.

I. 서론

기존 labeled dataset은 희소하고 규모가 작으며 수작업으로 구축되고 취약점 범위가 제한적이어서 smart-contract vulnerability detector를 평가하기 어렵다. 이 논문은 multi-step validation을 적용한 LLM 기반 vulnerability injection을 제안하고, static analyzer 분석을 위한 실현 가능성과 유용성을 평가한다.

동기: 기존 smart-contract vulnerability dataset은 희소하고 확장하기 어려우며, 대체로 규모가 작고 수작업으로 구축되고 취약점 유형이 제한적이다,.변경 불가능한 코드를 배포하기 전에 detection capability를 측정하려면 신뢰할 수 있는 ground truth가 필요하다.
접근법: 이 논문은 주입 가능한 취약점 유형을 식별하고, 제약된 injection을 수행하며, 각 결과 contract를 dataset에 포함하기 전에 검증하는 LLM을 제안한다.Validation은 compilation, 제약 준수, business-logic 무결성, vulnerability correctness를 포괄한다.
사례 연구: 14개 SmartBugs contract를 대상으로 49개 취약점 유형을 주입하여 multi-step validation을 위한 거의 1,000개의 candidate vulnerable variant를 생성했다.이 contract들은 다양한 application type과 structural complexity profile을 포괄하며, validation은 compilation, execution, business-logic 보존, 수동 vulnerability confirmation을 포함한다.
응용: 검증된 dataset은 static-analyzer assessment를 가능하게 하며, 상호보완적이지만 불완전한 detection coverage profile을 드러낸다.이는 기존 static analysis tool의 detection capability를 분석하는 데 이 dataset이 유용함을 보여준다.
발견과 한계: 전체 pipeline을 통과하는 candidate는 극히 일부에 불과하며, business-logic 보존이 성공 가능성이 가장 낮은 단계이고, 생존한 결과는 더 단순한 contract와 국소화된 vulnerability pattern에 집중된다.서론은 또한 model non-determinism, validation bottleneck, injection diversity, legacy-tool limitation을 실무적 교훈으로 제시한다.

II. 관련 연구 … C. 이전 연구와의 관계

관련 연구는 smart-contract vulnerability detection, fault-injection methods, 신뢰할 수 있는 vulnerable-contract dataset 구축 노력으로 나뉜다. 본 연구는 49 OpenSCV types에 대해 구조 적응형 LLM injection과 four-step validation을 사용해 이전 연구를 확장한다.

A. Smart Contract의 Vulnerability Detection: Static analysis가 smart-contract vulnerability detection을 주도하는 가운데, dynamic execution은 symbolic execution, taint analysis, pattern-matching 접근법을 보완한다.Vidal et al. 은 100개가 넘는 detection techniques를 조사하고 Mythril, Slither, Oyente를 포함한 도구를 논의한다.
A. Smart Contract의 Vulnerability Detection: 최근 연구는 smart-contract vulnerability detection에 LLMs를 적용하고, language models를 program analysis와 결합하거나 Solidity source code만으로 detection을 직접 평가한다.Sun et al., Boi et al., Sheng et al. 은 LLM-based vulnerability detection을 검토하고 특정 패턴에서 경쟁력 있는 정확도를 보고한다.
B. Vulnerability 및 Fault Injection: Fault injection 연구는 fault models, injection targets, workload selection과 같은 선택을 다루며, 기존 security methods는 web applications와 large-scale vulnerability data를 대상으로 했다.Natella et al., Fonseca et al., Nong et al. 은 이러한 dependability 및 security 지향적 방향을 대표한다.
B. Vulnerability 및 Fault Injection: 기존 smart-contract ground truth는 일관성이 낮고 제한적이며, SolidiFI 와 MuSe 는 predefined mutation mechanisms를 사용해 일부 vulnerability types만 주입한다.SolidiFI 는 fixed operators로 seven types를 seed하는 반면, MuSe 는 mutation-based methods를 통해 six types를 주입한다.
B. Vulnerability 및 Fault Injection: SuMo 는 predefined operators로 faulty contract variants를 생성하지만, specific vulnerability types가 아니라 test-suite assessment를 위한 generic programming mistakes를 대상으로 한다.이는 generic fault seeding과 vulnerability-oriented dataset construction을 구분한다.
B. Vulnerability 및 Fault Injection: FORGE 는 real-world audit reports에서 vulnerabilities를 추출하고 분류하는 반면, 본 연구는 by construction 방식으로 flaws를 생성하고 그 type과 placement를 제어한다.FORGE 는 reported incidents에 기반해 labels를 정하지만, 해당 labels는 source-report quality에 의존한다.
C. 이전 연구와의 관계: OpenSCV 와 prior evaluations 을 바탕으로, 본 연구는 49 types에 걸쳐 contract code에 직접 주입하고 각 결과를 four checks로 검증한다.LLM은 fixed operators나 AST templates가 아니라 각 contract의 structure에 맞춰 injections를 조정하며, compilation, constraint compliance, business-logic integrity, vulnerability correctness를 다룬다. 관련 접근법은 Table I에 요약되어 있다.

III. 취약점 주입 접근법 · A. Phase I – 준비 · B. Phase II – 주입 가능성 평가 및 주입

이 접근법은 취약점이 없고 대표성을 갖는 smart contract를 준비하고, 어떤 OpenSCV vulnerability type을 주입할 수 있는지 평가하며, LLM을 사용해 중복을 제거한 변형을 생성한다. 이후 validation phase에서 compilation, execution, injection, business logic, vulnerability 검사를 통해 이러한 변형을 필터링하여 최종 검증 데이터셋을 산출한다.

III. 취약점 주입 접근법: 전체 접근법은 preparation, assessment and injection, validation으로 구성되며, validated dataset이 최종 산출물로 사용된다.Preparation은 대상을 필터링하고 다양화하며, assessment and injection은 후보 변형을 생성하고, validation은 이를 단계적으로 검증한다.
III. 취약점 주입 접근법: Phase III는 compilation and execution, injection verification, business-logic verification, vulnerability confirmation을 통해 주입된 변형을 단계적으로 검증하여 final dataset을 산출한다.Validation은 접근법의 최종 산출물이며 네 가지 filtering step으로 구성된다.
A. Phase I – 준비: Phase I은 도구가 보고한 vulnerability가 없는 대표적인 real-world contract를 선택하고, 다양한 application type과 code structure를 유지한다.최종 SAT check는 critical vulnerability가 없음을 확인하며, injection에 영향을 주지 않는 minor issue는 남을 수 있다.
A. Phase I – 준비: Phase I은 assessment and injection LLM, target vulnerability type, contract–vulnerability pair별 반복 실행 횟수, injectability-score threshold를 포함한 실험 구성을 고정한다.반복 실행은 LLM non-determinism을 고려하기 위한 것이다.
B. Phase II – 주입 가능성 평가 및 주입: Phase II는 assessment, injection, deduplication의 three steps를 통해 개연성 있는 contract–vulnerability pair를 식별하고 vulnerable variant를 생성한 뒤 중복을 제거한다.Assessment LLM은 각 OpenSCV vulnerability type이 적절한 수정을 통해 현실적으로 도입될 수 있는지 평가하고, 다른 LLM은 제약된 injection을 수행한다.
B. Phase II – 주입 가능성 평가 및 주입: 주입 전에 선정된 OpenSCV target set의 every target contract와 vulnerability type에 대해 injectability assessment를 수행한다.Assessment는 각 vulnerability가 적절한 contract modification을 통해 개연성 있게 도입될 수 있는지 판단한다.

A D 취약점 주입 검증

파이프라인은 먼저 어떤 취약점 유형이 구조적으로 주입 가능한지 평가한 뒤, 제약된 취약 변형을 생성하고 반복 출력을 deduplication한 후 검증한다. 반복 평가와 명시적인 최소 수정 규칙으로 LLM의 비결정성을 다루면서 비현실적인 후보를 제한한다.

1단계 취약점 평가: assessment prompt는 대상 취약점 유형마다 이진 주입 가능성 판단과 간략한 근거를 반환하며, chain-of-thought나 few-shot 예시 대신 명시적인 local-edit 규칙을 사용한다.모든 취약점 유형을 한 번의 호출에서 평가하므로 few-shot prompting은 실용적이지 않았고, 명시적 규칙이 추론을 local edit로 더 잘 제한했다.
1단계 취약점 평가: 평가 규칙은 함수나 state variable의 추가와 pragma 또는 inheritance의 변경을 금지하며, 불확실한 경우 false positive를 줄이기 위해 기본적으로 non-injectable로 예측한다.false positive가 비현실적인 취약점 유형을 injection 단계로 전파할 수 있으므로, 이 보수적 선택은 더 많은 false negative를 수용한다.
1단계 취약점 평가: 반복 실행에서 injectability score가 사전 정의된 threshold를 초과하는 취약점 유형만 injection으로 진행하여, 해당 contract의 구조 및 로직과의 호환성에 대한 더 안정적인 추정치를 얻는다.이 score는 반복 평가 중 취약점이 injectable하다고 예측된 비율이다.
2단계 취약점 주입: 각 적격 contract–vulnerability 쌍에 대해 injection prompt는 전체 statement 로직과 순서를 보존하면서 정확히 하나의 function을 수정해 vulnerable variant를 생성하도록 model에 지시한다.model은 state variable, contract, library 또는 function을 추가하거나 mitigation logic을 도입하거나 // VULN HERE marker를 생략해서는 안 된다.
3단계 Deduplication: 여러 injection 실행 후 whitespace를 정규화했을 때 textually identical한 output을 제거하여, validation에는 동일한 패턴의 반복 복사본이 아니라 간결하고 대표성 있는 집합을 전달한다.반복된 LLM output이 validation workload를 부풀리지 않도록 deduplication은 validation 전에 적용한다.

C. Phase III – 주입된 Smart Contract 검증

Phase III에서는 구조적 무결성, 주입 정확성, 비즈니스 로직 보존, 취약점 악용 가능성을 확인하는 4단계 필터링 파이프라인을 통해 주입된 contract를 검증한다. 최종 확인 단계를 통과한 contract는 이후 논문에서 사용하는 ground truth를 확립한다.

Phase III – 주입된 Smart Contract 검증: 4단계 검증 파이프라인은 컴파일 및 실행, 주입 정확성, 비즈니스 로직 보존, 최종 취약점 확인을 평가한다.결과는 빌드 상태, 수동 검증 결과, 정적 분석 결과를 기록하는 JSON schema에 저장한다.
Step A 컴파일 및 실행: 컴파일 및 실행은 성공적인 컴파일, 배포, 하나 이상의 관련 public 또는 external function 호출을 요구함으로써 구조적 무결성 검사를 수행한다.호출 과정에서 즉각적인 runtime error나 구조적 불일치가 발생해서는 안 된다.
Step B 주입 검증: 수동 주입 검증은 금지된 구조 변경 없이 의도한 취약점이 기존 코드에 도입되었고, 원본과 구문적으로 일관되게 유지되는지 확인한다.평가자는 Phase II 제약조건에 따라 원본 contract와 주입된 contract의 diff를 비교한다.
Step C 비즈니스 로직 검증: 비즈니스 로직 검증은 대상 결함으로 직접 발생한 동작과 의도하지 않은 semantic drift를 구분하며, 그 외의 원본 contract 동작은 보존할 것을 요구한다.이 단계에서는 주입된 취약점 외에 주입된 변경이 의도한 동작을 변화시키는지 평가한다.
Step D 취약점 확인: 최종 취약점 확인은 결함이 대상과 일치하고, 의미가 있으며, 도달 가능하고, 현실적으로 악용 가능한지 검사하여 ground truth를 확립한다.현실적인 악용 가능성을 충족하려면 결함을 유발하고 공격자에게 이익을 제공하는 기술적으로 실행 가능한 transaction sequence가 필요하며, 공격 효과는 해당 취약점 유형의 OpenSCV specification에서 도출한다.

IV. 사례 연구: 실제 Smart Contract에 Vulnerability 주입 · A. Phase I: Contract Selection and Experimental Setup

사례 연구에서는 49개 OpenSCV vulnerability type을 평가하도록 설계된 재현 가능하고 자원 제약적인 pipeline을 사용해 실제 SmartBugs contract에 vulnerability-injection 접근법을 적용한다. Phase I에서는 vulnerability 평가 및 주입에 사용할 구조적으로 다양한 contract와 호환 가능한 open-source model을 선정한다.

IV. 사례 연구: 실제 Smart Contract에 Vulnerability 주입: 사례 연구에서는 제안한 접근법을 실제 smart contract에 적용하며, contract selection, injection assessment, validation, static analyzer 비교를 포괄한다.연구는 세 단계로 구성되며, 최종적으로 생성된 dataset을 사용해 SAT를 비교한다.
A. Phase I: Contract Selection and Experimental Setup: 47,398개의 SmartBugs sbwild contract 중 통합된 9개 SAT가 vulnerability를 보고하지 않은 contract만 필터링한 결과 2,862개 contract가 남았다.이 필터링된 집합을 기반으로 연구 대상 14개 contract를 선정해 safe-contract pool을 구성했다.
A. Phase I: Contract Selection and Experimental Setup: application type, code size, control-flow complexity, function, state variable, external interaction 전반에서 다양성을 극대화하도록 대표 contract 14개를 선정했다.비교를 용이하게 하기 위해 selection metric을 min-max scaling으로 정규화했다.
A. Phase I: Contract Selection and Experimental Setup: Fig. 4는 선정된 contract가 최소 수준의 low-complexity contract부터 광범위한 external interaction과 높은 control-flow complexity를 지닌 대규모 contract까지 다양한 structural profile을 포괄함을 보여준다.heatmap은 14개 contract 전체의 정규화된 complexity metric을 요약한다.
A. Phase I: Contract Selection and Experimental Setup: 실험에는 재현 가능한 Kaggle P100 environment를 사용했으며, proprietary infrastructure와 query당 비용이 대규모 재현성을 제한하므로 closed-source model은 제외했다.code, data, script를 포함한 전체 pipeline은 replication package에서 제공된다.
A. Phase I: Contract Selection and Experimental Setup: 66M에서 15B parameter 범위의 open-source model 16개를 조사했으며, 16GB VRAM 제약하에서 hardware-incompatible model과 non-code model은 제외했다.조사한 model은 encoder-only, decoder-only, instruction-tuned, code-specialized architecture를 포괄했고 training data도 서로 달랐다.
A. Phase I: Contract Selection and Experimental Setup: Qwen2.5-Coder는 가장 강력한 호환 가능 code-specialized option이며, 14B parameter로 hardware constraint에 맞는 해당 계열의 최대 model이므로 assessment 대상으로 선정했다.선정은 code-analysis 적합성과 HumanEval 및 MBPP 결과를 기반으로 이루어졌다.
A. Phase I: Contract Selection and Experimental Setup: pipeline은 49개 OpenSCV vulnerability type을 대상으로 했으며, injected vulnerability를 인식된 LLM 및 SAT output과 직접 비교할 수 있도록 SWC code가 있는 type으로 selection을 제한했다.injection을 위해 명시적으로 우회해야 하는 Integer Underflow/Overflow를 사용해 Solidity 0.8.x contract에서 다섯 candidate model을 평가했다.

B. Phase II: 평가 및 주입 · 1) Step 1: 주입 가능성 평가:

Step 1에서는 LLM이 평가한 주입 가능성이 매우 불균일하며, 49개 취약점 유형 중 주입 대상으로 유지되는 유형이 25개로 좁혀짐을 확인한다. 수동 검증 결과, 평가는 보수적이고 정밀도가 높았으며, 깊은 의미론적·구조적 조건보다 국소적 구문 패턴에서 더 우수한 성능을 보였다.

1) Step 1: 주입 가능성 평가:: 주입 가능성 점수는 0% 또는 100% 부근에 집중되어 일관된 예측을 보이며, 국소적으로 도입 가능한 취약점과 구조적으로 양립할 수 없는 변경이 필요한 취약점을 구분한다.Figure 5는 그 결과인 contract–vulnerability 주입 가능성 heatmap을 제시하며, 일부 pair만 일관되게 주입 가능하다고 판단된다.
1) Step 1: 주입 가능성 평가:: 처음 고려한 49개 취약점 유형 중 25개가 적어도 하나의 contract에서 50% 주입 가능성 threshold를 충족하여 주입 대상으로 유지되었다.유지된 공간은 전체 취약점 taxonomy를 포괄하기보다 target contract의 구조와 의미론에 의해 제약된다.
1) Step 1: 주입 가능성 평가:: 주입 가능성은 contract마다 다르다. 일부 contract는 높은 점수의 취약점 유형을 많이 지원하는 반면, 구조적으로 경직된 contract는 그럴듯한 주입을 제한된 집합만 지원한다.이 분포는 target contract의 구조와 취약점 특성 간 상호작용을 반영한다.
1) Step 1: 주입 가능성 평가:: 수동 검증 결과, 평가 오류는 주로 coverage를 낮추는 방향으로 나타났다. 모델이 false positive를 비교적 적게 생성하고 false negative를 더 많이 생성했기 때문이다.검증 sample은 취약점 유형, contract, 반복 실행, 그리고 균형을 맞춘 positive 및 negative 결과에 따라 층화되었다.
B. Phase II: 평가 및 주입: 전반적으로 평가 단계는 현실적이고 제약을 준수하는 결과를 생성할 가능성이 높은 contract–vulnerability pair를 식별하여 주입 search space를 축소한다.이 절에서는 취약점 주입 및 deduplication에 앞선 Step 1로서 주입 가능성 평가를 다룬다.
1) Step 1: 주입 가능성 평가:: 수동으로 검증한 108건의 평가 결정에서 75.9% accuracy, 95.5% precision, 73.6% recall을 달성했으며, false positive는 3건, false negative는 23건이었다.sample이 6,860건의 결정 중 108건(1.57%)을 포함하므로, 이 결과는 확정적이라기보다 시사적이다.

2) 2단계: 취약점 주입: · 3) 3단계: 중복 제거:

주입 단계에서 997개의 후보 컨트랙트가 생성되었지만, 중복 제거 후 검증 대상은 텍스트상 고유한 변형 193개로 줄었다. 중복은 광범위하면서도 균등하지 않게 나타났으며, 이는 컨트랙트 구조와 취약점 유형이 LLM이 생성하는 주입의 다양성을 제약함을 보여준다.

2) 2단계: 취약점 주입:: 주입 가능성 점수가 50%를 초과한 취약점–컨트랙트 쌍에 대해 Meta-Llama-3가 997개의 컨트랙트를 생성했으며, 선택된 각 쌍에 대해 여러 쿼리를 사용했다.생성은 사전에 정의된 주입 제약을 따랐으며, 평가 단계에서 주입 가능성이 있다고 예측된 경우로 제한되었다.
3) 3단계: 중복 제거:: 중복 제거는 공백을 정규화한 뒤 각 컨트랙트–취약점 쌍에서 텍스트상 구별되는 변형만 남겨, 반복 패턴이 검증을 부풀리는 것을 방지한다.중복은 공백 정규화 후 텍스트가 동일한 경우로 정의된다.
3) 3단계: 중복 제거:: 컨트랙트 193개라는 수치는 정확한 다양성보다는 의미적 다양성을 근사한다. 서식 차이는 서로 다른 것으로 남는 반면, 서로 다른 실행 경로에서 동일한 텍스트는 병합되기 때문이다.이 한계는 공백 정규화 후 텍스트 기반 비교를 수행한 데서 직접 비롯된다.
3) 3단계: 중복 제거:: 취약점 유형별 중복률은 유사했으며, 이는 모델이 소수의 표준 주입 패턴으로 자주 수렴했음을 보여준다.Figure 10은 취약점 유형별 중복 비율을 제시한다.
3) 3단계: 중복 제거:: 논리가 경직되었거나 주입 지점이 더 적은 컨트랙트 대상에서는 출력 수렴이 더 강하게 나타났으며, 이는 다양성이 취약점 유형–컨트랙트 구조 상호작용에 좌우됨을 보여준다.일부 대상은 다른 대상보다 중복 생성물을 현저히 더 많이 산출했다.
3) 3단계: 중복 제거:: 서로 다른 주입의 다양성은 매우 불균등했다. 컨트랙트–취약점 쌍 중 일부만 여러 변형을 생성했으며, 많은 쌍은 하나도 생성하지 못했다.Figure 11은 처음에 14개가 선택되었지만 그중 6개에서 중복되지 않는 주입이 0개 생성되어 읽을 수 있는 컨트랙트 8개만 제시한다.
3) 3단계: 중복 제거:: 중복 제거 후 고유하게 주입된 컨트랙트 193개가 남았으며, 이는 생성된 컨트랙트 997개에서 약 80% 감소한 수치로 검증 파이프라인의 입력을 구성한다.따라서 유효 출력은 원시 생성 횟수가 아니라 서로 구별되는 의미 있는 변형으로 측정된다.

C. Phase III: 검증 · 1) 검증 파이프라인 (단계 A–D):

Phase III에서는 컴파일, 실행, injection 정확성, business logic 보존, vulnerability 유효성을 순차적으로 점검해 중복되지 않은 생성 contract 193개를 검증하고, 16.58%의 survival rate에 해당하는 검증 완료 contract 32개를 남긴다. 필터링 결과 constraint 준수와 semantic 보존이 주요 난제로 나타났으며, 생존한 contract는 static analyzer 평가를 위한 ground truth를 이룬다.

1) 검증 파이프라인 (단계 A–D):: 중복되지 않은 contract 193개 중 32개가 모든 검증 단계를 통과해 최종 survival rate 16.58%를 기록한다.파이프라인은 컴파일 및 실행 가능성, injection 정확성, business logic 보존, 최종 vulnerability 확인을 거치며 contract를 단계적으로 필터링한다.
1) 검증 파이프라인 (단계 A–D):: business logic 보존을 평가하는 Step B에서 Step C로 넘어갈 때 생존 contract가 89개에서 44개로 감소하며 가장 큰 상대적 감소가 발생한다.이는 의도한 contract 동작을 보존하면서 vulnerability를 도입하는 일이 특히 어렵다는 것을 보여준다.
1) 검증 파이프라인 (단계 A–D):: 검증 결과는 LLM이 검증된 vulnerable contract를 생성할 수 있음을 보여주지만, 형식적 수정과 semantic 측면에서 유효하며 exploit 가능한 vulnerability를 구분하려면 multiple filters가 필요하다.파이프라인은 Solidity smart-contract security 경험이 있는 단일 평가자가 수작업으로 실행했다.
1) 검증 파이프라인 (단계 A–D):: Step B에서는 constraint를 위반하거나 의도한 vulnerability를 올바르게 구현하지 못한 injection을 거부해 pool을 150개에서 89개로 줄인다.Phase II에서 vulnerability가 injection 가능하다고 예측한 경우에도 이는 여전히 어렵다.
1) 검증 파이프라인 (단계 A–D):: Step C에서는 syntactically correct한 injection이 충분하지 않은 access-control 검사 약화를 비롯해 의도하지 않은 semantic changes를 일으키는 경우를 식별한다.이 대목은 다른 반복적 실패 패턴과 함께 충분한 자금 없이도 transfer가 허용되는 사례를 보여준다.
1) 검증 파이프라인 (단계 A–D):: Step D에서는 각 vulnerability type의 OpenSCV specification에 정의된 예상 adversarial effect를 사용해 vulnerability-specific exploitability criteria를 일관되게 적용한다.access-control 약화는 하나의 예시에 불과하며, 이 기준은 모든 vulnerability type에 적용된다.
1) 검증 파이프라인 (단계 A–D):: 검증된 contract 32개는 static analyzer를 비교하는 데 사용되는 ground truth를 구성한다.이 contract들은 컴파일, 실행, injection, business logic, vulnerability validity 검사를 통과한 뒤에만 보존된다.

2) 인젝션 생존에 영향을 미치는 요인: · D. 데이터셋을 사용한 탐지 도구 비교

검증된 데이터셋은 인젝션 생존을 제한하는 조건과 세 static analyzer 간의 서로 다르고 불완전한 탐지 프로파일을 모두 드러낸다. 단순한 contract와 국소화된 vulnerability pattern은 더 자주 생존하는 반면, 제한적인 coverage와 legacy code 실패로 인해 도구 결과는 참고적인 수준에 머문다.

2) 인젝션 생존에 영향을 미치는 요인:: 단순한 target contract는 복잡한 contract보다 더 자주 validation을 통과하며, 국소화된 vulnerability class는 structural class보다 더 자주 생존한다.분석에서는 lines of code와 cyclomatic complexity의 median split으로 structural complexity를 할당한다. Checking이 우세한 반면, Algorithm/Method와 Assignment/Initialization은 생존율이 더 낮다.
2) 인젝션 생존에 영향을 미치는 요인:: 높은 Phase II injectability가 Phase III survival을 보장하지는 않는다. candidate가 business logic을 변경하거나 의미 있는 defect를 생성하지 못할 수 있기 때문이다.Wrong Caller Identification (8.1.1)은 거의 완벽한 Phase II assessment accuracy와 높은 Phase III survival을 함께 보이는 반면, accuracy가 낮은 type은 생존율도 낮은 경향을 보인다.
2) 인젝션 생존에 영향을 미치는 요인:: 193개의 non-duplicate injection 중 32개, 즉 16.58%만이 전체 pipeline을 통과한다. business-logic verification이 주요 bottleneck으로 작용해 survivor를 89개에서 44개로 줄인다.Checking vulnerability는 Phase II를 통과한 25개 type 중 11개를 차지하며 가장 높은 Phase III survival rate를 달성한다. 반면 더 structural한 type은 성능이 낮다.
D. 데이터셋을 사용한 탐지 도구 비교: 25개 vulnerability type 중 9개만이 하나 이상의 confirmed detection을 받으며, 32개 validated contract 중 13개는 static analysis failure다.analyzable contract가 19개뿐이므로 비교는 qualitative하며, precision과 recall 값은 conclusive한 결과가 아니라 indicative한 결과다.
D. 데이터셋을 사용한 탐지 도구 비교: 모든 13개 static analysis failure contract가 0.3.x부터 0.4.11까지의 version을 사용하고, analyzable contract는 0.4.18 이상을 사용하므로, legacy Solidity의 한계가 많은 analysis failure를 설명한다.실패한 contract는 sha3, legacy delegatecall, callcode를 포함한 deprecated construct도 사용한다.
D. 데이터셋을 사용한 탐지 도구 비교: Slither는 57.9% recall로 perfect precision을 달성하고, Solhint는 false positive와 함께 70.6% recall을 달성하며, Remix는 그 중간에 위치한다.도구의 coverage는 부분적으로 complementary하며, 각 도구는 다른 도구가 놓치는 vulnerability를 탐지한다.
D. 데이터셋을 사용한 탐지 도구 비교: 세 contract에 long-context proprietary model을 사용하면 25개 candidate 중 9개, 즉 36%가 모든 validation step을 통과하며, 이는 smaller model이 선호한 동일한 국소화된 type에 집중된다.이 실험은 동일한 제약과 human evaluation 아래에서 model size 또는 context length가 survival pattern을 변화시키는지 검증한다.
D. 데이터셋을 사용한 탐지 도구 비교: SolidiFI 와 비교하면, LLM 기반 접근법은 49 OpenSCV type을 대상으로 하며 특정 compiler version에 종속되지 않는다. 반면 SolidiFI 는 고정된 bug type 7개를 지원하고 14개 contract 중 3개에서만 실행되었다.SolidiFI 는 toolchain이 Solidity 0.5.12에 고정되어 있었기 때문에 나머지 11개 contract에서 compilation에 실패했다.

V. 교훈 및 실무적 시사점

LLM 기반 취약점 주입은 compilation보다 semantic preservation, contract complexity, 제한된 output diversity, 수동 validation effort에 더 크게 제약된다. 이러한 한계는 dataset을 편향시키고 static-analyzer coverage를 얼마나 확신 있게 해석할 수 있는지 제한한다.

V. 교훈 및 실무적 시사점: 89개에서 44개 candidate만 Step C를 통과하며, compilation과 execution이 성공했음에도 business-logic verification이 pipeline의 상대적으로 가장 큰 병목으로 나타난다.assessment phase는 그럴듯한 contract–vulnerability pair를 식별하지만, 중복이 제거된 193개 contract 중 모든 validation step을 통과한 것은 32개뿐이다.
V. 교훈 및 실무적 시사점: 997개의 raw generation이 193개의 distinct contract로 축약되어, 수렴하는 output과 감소한 dataset diversity, 추가 generation run의 diminishing returns를 보여준다.Temperature variation, prompt perturbation, multi-model ensemble은 mitigation strategy로 탐색하지 않았다.
V. 교훈 및 실무적 시사점: Contract complexity가 높고 external interaction이 많을수록 survival이 감소하며, structural한 Algorithm/Method type보다 Checking vulnerability가 더 쉽게 주입된다.복잡한 control flow에서는 side effect 없이 vulnerability를 삽입하기 어렵고, Checking은 Phase II를 통과한 25개 type 중 11개를 차지한다.
V. 교훈 및 실무적 시사점: Steps B, C, D의 manual inspection은 candidate volume에 따라 증가하므로, validation은 대규모 dataset과 반복적인 model evaluation에서 scalability bottleneck이 된다.case study에서는 단일 evaluator가 모든 candidate를 검사했으며, business-logic check를 자동화할 후보로 differential testing이 제시된다.
V. 교훈 및 실무적 시사점: 검증된 contract 32개 중 13개, 즉 40.6%는 legacy Solidity version과 deprecated construct 때문에 어떤 static analyzer로도 분석할 수 없다.동일한 실패가 원본의 수정되지 않은 contract에서도 발생하므로, 이는 injected vulnerability 때문에 발생한 것이 아니다.
V. 교훈 및 실무적 시사점: Injectability assessment는 intermediate validation을 포함하는 filter로 다뤄야 한다. 그 결과 생성되는 dataset은 simple contract와 Checking defect 쪽으로 편향되기 때문이다.이러한 dataset으로는 represented defect class를 넘어서는 tool-coverage 결론을 뒷받침해서는 안 되며, 실제 Ethereum code에서 발생하는 static-analysis failure도 고려해야 한다.

VI. 타당성 위협 · VII. 결론

LLM 기반 vulnerability injection은 가능하지만 제한적이다. 193개의 중복 제거 contract 중 validation을 통과한 것은 32개뿐이며, semantic preservation, model scope, evaluation uncertainty가 결론을 제약한다. 향후에는 dataset과 model의 범위를 넓히고 validation을 자동화하여 diversity를 높이고 semantic error를 줄여야 한다.

VI. 타당성 위협: Validation Step B–D에서 single evaluator가 수행한 수동 검사는 inter-rater agreement를 측정하지 않았기 때문에 subjectivity를 유발할 수 있다.사전에 정의한 기준과 경계 사례에 대한 신중한 재검토로 이 한계를 완화했지만 제거하지는 못했다.
VI. 타당성 위협: Injectability score는 formal structural analysis가 아니라 proxy이므로 false positives and false negatives가 발생하며, 이로 인해 25개의 retained types가 injectable vulnerabilities를 과소평가할 수 있다.Whitespace normalization 후의 textual deduplication은 whitespace가 아닌 형식이 다른 semantically equivalent injection을 놓칠 수도 있다.
VI. 타당성 위협: 결과는 14개의 SmartBugs contracts 또는 constrained hardware에서 사용한 두 개의 quantized open-source models를 넘어 일반화되지 않을 수 있다.Closed-source models는 재현성과 query당 비용이 large-scale experimentation을 제한한다는 이유로 제외했다.
VI. 타당성 위협: Reliability check는 6,860개의 assessment decisions 중 108개를 대상으로 했으며, 95% Wilson interval이 약 [67.3%, 83.2%]인 75.9% accuracy를 얻었다.따라서 관찰된 accuracy가 vulnerability types 전반에 균일하게 성립하는지에 대해 무시할 수 없는 uncertainty가 남는다.
VI. 타당성 위협: 13건의 static-analysis failures로 analyzable set이 32개에서 19개 contracts로 줄었으므로, 보고된 tool metrics는 definitive하기보다 exploratory한 것으로 보아야 한다.단일 contract의 ground-truth classification 차이가 precision과 recall을 크게 바꿀 수 있다.
VII. 결론: 중복 제거된 injected contracts 193개 중 32개(16.58%)가 모든 validation step을 통과했으며, business-logic preservation이 주요 bottleneck이었다.구조적으로 더 단순한 contracts와 localized syntactic patterns를 가진 vulnerability types에서 survival이 가장 높았다.
VII. 결론: 향후에는 더 크고 다양한 contract sets와 alternative prompting 및 model strategies를 평가하는 한편, differential testing 또는 semantic deduplication을 통해 validation을 자동화할 예정이다.저자들은 추가 generation runs가 diversity를 거의 늘리지 못하므로 model convergence가 diversity ceiling이 된다는 점도 지적한다.