LLM-Assisted Dynamic Threat Analysis for Attacker-Reachable Software Weaknesses in Autonomous Vehicles
- 게시일: 2026-08-14
- arXiv: 2608.13450v1 · PDF
- 저자: Md Wasiul Haque, Sagar Dasgupta, Mizanur Rahman, Md Rayhanur Rahman
- 분야: cs.SE, cs.CR, cs.LG
- 선정 점수: 8.05
- 선정 이유: 최근성 0.8, 인용 영향 0.0 (인용 0회), 저자 영향 1.4 (최고 h-index 8), AI 주제 적합성 2.8, 개발자 관심 0.7, 학술 신호 0.9, 오픈 웨이트·주요 연구조직 신호 1.6
← 2026-08-14 목록으로 돌아가기
한 문장 요약
대규모 정적분석으로 Autoware의 안전 관련 후보지(결정 규칙·검증 체크·입력→출력 흐름)를 뽑아 로컬 오픈웨이트 LLM으로 테스트 하니스·뮤테이터·결함주입 아티팩트를 자동 생성하고, 네이티브 빌드에서 컴파일·수정·퍼징하여 LLM 기반 동적 확인의 실현 가능성과 실패 지점을 평가했다.
해결하려는 문제
대형 자율주행 소프트웨어에서 정적분석은 공격자 입력으로 도달 가능한 후보지를 대량으로 식별하지만, 런타임에서 실제로 도달·악용 가능한지를 확인하려면 대상과 정확히 통합되는 실행 가능한 하니스(빌드·초기화·메시지 포맷 등)를 수작업으로 만드는 것이 병목이다. 최근 LLM이 테스트 코드 자동생성에 유망하지만, 완전한 AV 스택(ROS 2 기반)과 네이티브 빌드에 대해 LLM이 하니스 생성→빌드 통합→동적확인(퍼징) 전 과정을 자동화할 수 있는지 불확실하다.
핵심 기여
- Autoware 전체 저장소를 컴파일-정확성(compile-precise)으로 분석해 185개 패키지에서 1,375개의 결정 규칙, 2,274개의 검증 체크, 482개의 입력→안전 출력 흐름을 복구하고, 이를 기반으로 AV 특유의 약점 분류체계를 도출함.
- 정적 후보(우선순위 P1/P2 포함, 총 740개)를 대상으로 LLM 기반 아티팩트 생성→네이티브 빌드에서 Sanitizer-enabled 컴파일→컴파일러-인-루프 수리(최대 3회)→링크·고정 예산 퍼징→사후 분류를 포함하는 재현 가능한 엔드투엔드 파이프라인을 설계·구현·공개함.
- 두 개의 로컬 오픈웨이트 모델(코드-특화 모델 codestral:22b, 일반 추론 모델 gpt-oss:20b), 정적 컨텍스트 제거(ablation), 그리고 단순 메타데이터 기반 베이스라인을 통제 비교하여 모델·컨텍스트가 결과에 미치는 영향을 정량적으로 평가함.
- 빌드 통합 실패에 대한 세부 택소노미를 제시하여, 초기 컴파일 실패의 약 80%가 코드 논리 문제보다 의존성 결합(헤더·경로 등) 문제에서 발생함을 규명하고, 컴파일 성공이 실제 대상 실행을 보장하지 않음을 입증함.
접근 방법
- 파이프라인은 Phase0~4로 구성된다.
- Phase0에서 clang을 이용해 Autoware(185개 패키지, 1,857개 소스)의 컴파일 명령을 적용한 AST·조건·간단 호출그래프와 launch/YAML을 수집해 결정 규칙·검증 체크·토픽 인터페이스·패키지 단위 입력→출력 흐름을 회수하고 우선순위(P1:≥8, P2:5–7)를 매긴 뒤 740개(P1+P2)를 선정한다.
- Phase1에서 고정 템플릿 프롬프트에 대상 메타데이터와(또는 제거한) 정적 컨텍스트(소스 윈도우·발견 설명·입력 토픽·안전 출력 등)를 채워 LLM에 보내 각 대상에 대해 libFuzzer 함수형 하니스, ROS2 메시지 뮤테이터(mutator.py), 결함주입 명세(fault_injection.yaml), ASan/UBSan 빌드 설정을 생성하게 한다.
- Phase2에서 생성물을 Autoware의 실제 빌드 구성(include 경로·전처리기 정의 등)을 사용해 clang++(ASan+UBSan)으로 객체 컴파일을 시도한다.
- 실패하면 최대 3회의 컴파일러 진단을 모델에 되돌려 수정(compiler-in-the-loop)시키며, 컴파일 후 링킹된 libFuzzer 바이너리에 대해 고정 퍼징 예산(설정 600s, 실제 실행 60s)을 적용한다.
- Phase3에서 크래시·도달성·재현성을 수작업으로 분류하여 진정한 대상 실행인지 판단하고, Phase4에서 모델별·단계별 집계를 산출한다.
- 비교 조건은 2모델×{static, no-static} + naive baseline(메타데이터 기반 스캐폴드)으로 총 5조건이다.
주요 결과
- 정적분석: 185개 패키지·1,857개 소스 파일에서 786개의 ROS 인터페이스(구독 248/발행 500/서비스 38), 1,816 파라미터, 2,749 컴파일-정확 조건 사이트, 1,375 결정 규칙, 2,274 검증 체크, 482 입력→안전 출력 흐름을 회수함.
- 대상 샘플: P1+P2로 계층화된 740개 후보(214 P1, 526 P2)를 선정하여 실험(시드·재현성 확보).
- 아티팩트 생성 총계: 5조건×740 = 3,700 세트(LLM 조건만 4×740 = 2,960).
- 초기(첫 시도) 컴파일 실패: 2,960 LLM 하니스 중 2,259개(76%)가 첫 시도에서 실패. 실패 원인 중 의존성 관련(헤더 누락 1,436건, 소스 파일 경로 오류 381건)이 1,817건(약 80%의 첫샷 실패)을 차지함. 나머지는 API 불일치(225), 시그니처 불일치(110), 문법 오류(81) 등.
- 모델별 차이: 추론형 모델(gpt-oss:20b)은 정적 컨텍스트가 있을 때 473/740(63.9% ≈64%)을 첫 시도에서 객체 컴파일했고, 컨텍스트 제거시 179/740(24.2%)로 떨어짐. 코드특화 모델(codestral:22b)은 각각 46/740(6.2%)·3/740(<1%)으로 매우 낮음 — 정적 컨텍스트가 결과에 중요함을 정량적으로 확인함. (문서 표/본문 수치 그대로 사용)
수리 이후(object compileability): 리페어 루프는 추론형 모델에서 평균 1.2~1.3회 수리로 객체 컴파일을 100%까지 끌어올렸으나, 이는 많은 경우 실제 종속성을 대체하는 로컬 스텁(stub) 도입에 의해 달성됨(스텁 수렴). 결과적으로 LLM 조건 전체에서 링크되어 퍼징까지 도달한 하니스는 652/2,960(22%)에 불과함(최종 linked & fuzzed 합계).
퍼징·크래시: 퍼저까지 도달한 케이스들 중 총 37개의 크래시가 관찰되었고, 모든 크래시는 Autoware의 원래 코드가 아닌 모델이 생성하거나 수정한 스텁/대체 구현에서 발생했음. 동적 확인(confirmed weakness)은 예산 내에 단 하나도 성립하지 않았음(0건).
한계
- (저자가 명시한 한계) 결정 규칙 분류 및 패키지 수준 흐름 분석은 휴리스틱이며 완전한 인터프로시저·정밀 테인팅을 제공하지 않아 보고치는 ‘관찰된’ 공격 표면을 특성화할 뿐 합리적 과대·과소 근사를 증명하지 않음.
- (저자가 명시) 컴파일-정확 인벤토리는 compile_commands가 제공된 패키지에만 기여함(모든 패키지가 포함되지 않을 수 있음).
- (저자가 명시) 모든 실험은 소프트웨어-인-더-루프(SiL)에서 수행되어 물리 차량에서의 악용 가능성은 주장하지 않음.
- (저자가 명시) 퍼징 설정은 구성상 타깃당 600초였으나 실제 실행 시간은 60초였음; 다만 실행에 도달한 하니스가 극히 적었기 때문에 주요 결론에는 영향이 제한적임.
(저자가 명시) ‘컴파일 가능’은 객체단계(object compilation)로 정의되어 전(완전) 링크·실제 타깃 실행보다 느슨함; 많은 컴파일 성공이 실제 대상 바인딩(링크) 대신 스텁 도입에 의해 얻어졌음.
(저자가 명시) 리페어 루프는 객체 컴파일 최적화를 목표로 하고 동일 모델로 최대 3회만 수행됨 — 링크 인지(link-aware) 수리 전략이 더 나을 수 있음.
(저자가 명시) 연구는 Autoware와 두 개의 오픈웨이트 모델만 평가하므로 다른 코드베이스·모델로 일반화하기 어렵다.
(추론으로 확인 가능한 제약) 베이스라인은 모든 하니스를 컴파일시켰지만 실제 타깃을 실행하지 못해 ‘컴파일 성공’만으로는 분석의 유효성을 판단할 수 없음(스텁 수렴이 핵심 실패 모드).
개발자 관점
- 대형 ROS 2 기반 AV 스택에서 LLM로 하니스 자동생성 연구·적용 시 가장 먼저 투자할 영역은 빌드·의존성 통합(헤더/생성된 메시지 타입/패키지·링크 타깃 해결)과 네이티브 링크 보장임. 단순히 코드를 생성하고 컴파일 에러를 없애는 것이 아니라 실제 구현 심볼이 실행 경로에 존재함을 검증해야 한다.
- LLM에 정적 컨텍스트(문맥: 소스 윈도우, 발견 설명, 관련 토픽·출력)를 제공하면 첫-시도 객체 컴파일 성공률이 크게 개선되므로 프롬프트 설계에서 문맥 제공은 비용 대비 효과가 높음.
- 컴파일러-인-루프 수리는 객체 컴파일 가능성을 높이나 많은 경우 스텁을 도입해 실제 타깃 실행을 무력화하므로, 수리 과정은 ‘실제 타깃 심볼에 바인딩’과 ‘런타임에 의도한 함수가 호출되는지’를 최우선 제약으로 삼도록 설계해야 함(링크-인식 수리).
- 평가 기준을 명확히 하라: 객체 단위 컴파일 성공을 성과로 삼지 말고, (a) 실제 패키지 심볼에 링크되는지, (b) 런타임 호출 스택에 대상 함수가 존재하는지, (c) 퍼징 중 도달성·재현 가능한 크래시가 대상 코드에서 발생하는지를 종합적으로 검증해야 함.
- 실무 적용에서는 LLM이 완전 자동화 대신 ‘하니스 초안’ 또는 ‘빌드-문제 진단 보조’ 역할로 유용할 수 있다. 인간 검토·수정과 빌드-지향 툴(compile_commands·패키지 메타데이터 활용)을 결합하면 현실적 진전이 가능함. 또한 실험 재현을 위해 compile_commands.json·빌드 환경·프롬프트·로그를 함께 보관·공개하라.
근거 범위: 이 분석은 제공된 논문 PDF 본문 전체(제시된 모든 페이지의 텍스트)를 기반으로 작성되었으며, 표·그림·본문에 명시된 수치와 표기를 그대로 인용·요약했습니다. 표(Table 7 등), 그림(Fig.6–8) 및 본문 단락에서 직접 확인 가능한 수치를 우선 사용했습니다. 논문이 밝힌 실험 환경·모델 이름(codestral:22b, gpt-oss:20b), 하드웨어, 퍼징 예산 및 리페어 라운드(≤3) 등도 본문에서 취합했습니다. 외부 검증은 수행하지 않았고, 런타임 로그나 공개된 저장소의 추가 세부 구현(예: 실제 생성된 하니스 코드 내용)은 본 PDF만으로는 검증할 수 없습니다.