LLM-Assisted Dynamic Threat Analysis for Attacker-Reachable Software Weaknesses in Autonomous Vehicles
이 논문은 Autoware를 위한 동적 익스플로잇 아티팩트 생성을 자동화하기 위해 대규모 언어 모델을 사용하는 것의 타당성을 평가하며, 추론 모델이 초기 컴파일 단계에서 코드 특화 모델보다 우수한 성능을 보이지만, 소프트웨어 약점을 확인하는 데 있어 주요 장벽은 후보 생성이나 퍼징이 아니라 의존성 연결 및 스터브 코드에 대한 의존성으로 인해 발생하는 높은 빌드 통합 실패율임을 밝히고 있다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
자율주행 자동차 내부의 소프트웨어를 거대하고 북적이는 도시라고 상상해 보세요. 이 도시에는 수백만 개의 작은 일꾼들(코드 라인)이 서로 대화하며 언제 핸들을 돌릴지, 혹은 브레이크를 밟을지를 결정합니다. 이 도시를 안전하게 유지하기 위해 엔지니어들은 탐정 역할을 합니다. 먼저, 그들은 "정적 분석(static analysis)"을 사용합니다. 이는 마치 도시의 전체 설계도를 스캔하여 낯선 이가 나쁜 메시지를 몰래 들여와 혼란을 일으킬 수 있는 지점을 찾아내는 초고속 지도 판독기와 같습니다. 하지만 지도는 실제 도시가 아닙니다. 설계도상으로는 길이 열려 있는 것처럼 보일지라도, 실제로 그 길을 걸어갈 수는 없을지도 모릅니다. 예를 들어, 문이 잠겨 있거나 존재하지 않는 다리가 있을 수도 있기 때문입니다. 이를 확실히 하기 위해서는 실제 탐사원을 도시로 보내 그 길을 직접 걸어보게 해야 합니다. 이것을 "동적 분석(dynamic analysis)"이라고 부릅니다.
수년 동안, 인공지능(AI), 특히 이야기 쓰기나 수학 문제를 푸는 데 사용되는 것과 같은 기술인 대규모 언어 모델(LLM)이 이러한 탐사 역할을 해줄 것이라는 기대가 있었습니다. 엔지니어가 의심스러운 지점마다 매번 맞춤형 "테스트용 자동차"를 직접 만드는 대신, AI에게 그 일을 대신 시키겠다는 아이디어였습니다. 만약 AI가 이러한 테스트용 자동차를 자동으로 제작하고, 이를 소프트웨어 안으로 몰고 들어가서 충돌이 발생하는지 확인할 수 있다면, 우리는 자율주행 자동차의 안전성을 빛의 속도로 점검할 수 있을 것입니다. 이 논문은 아주 단순하면서도 중대한 질문을 던집니다. 과연 이 AI 탐정들이 자율주행 자동차가 정말로 안전한지 증명할 수 있을 만큼 테스트용 자동차를 잘 만들어낼 수 있을까요, 아니면 겉보기에는 진짜 같지만 실제로는 작동하지 않는 가짜 자동차를 만드는 데 머물러 있을까요?
위대한 AI 시승 실험
이 연구에서 연구진은 많은 자율주행 자동차의 기반이 되는 유명한 오픈 소스 소프트웨어 스택인 Autoware를 사용하여 거대한 실험을 설계했습니다. Autoware를 로봇 자동차를 위한 운영체제라고 생각하면 됩니다. 이는 185개의 서로 다른 패키지(도시의 서로 다른 동네와 같은 역할)와 수천 개의 파일로 구성되어 있습니다.
설정: 지도와 AI 제작자들
먼저, 연구진은 "지도 판독기(정적 분석)"를 사용하여 공격자의 나쁜 입력이 자동차를 멈추거나 가게 하는 것과 같은 안전에 직결된 결정에 도달할 수 있는 Autoware 코드 내의 740개 특정 지점을 찾아냈습니다. 이 지점들이 바로 "용의자"였습니다.
그다음, 연구진은 이 740개의 용의자를 두 가지 서로 다른 AI 모델(하나는 코딩 특화 모델, 다른 하나는 일반 추론 모델)에게 전달하며 "테스트 하네스(test harness)"를 구축하라고 요청했습니다. 쉽게 말해, 테스트 하네스는 코드의 특정 지점을 찔러보아 문제가 생기는지 확인하도록 설계된 작은 프로그램입니다. 연구진은 AI에게 용의자 주변의 코드, 문제에 대한 설명, 그리고 도로의 규칙(빌드 환경)을 제공했습니다.
여정: AI가 길을 잃은 곳
그 후 연구진은 이 AI가 생성한 테스트 프로그램들을 실제 Autowware 소프트웨어와 함께 컴파일(빌드)하려고 시도했습니다. 여기서 이야기에 반전이 일어납니다.
2,960번(740개의 타겟 × 4가지 AI 조건)의 테스트 프로그램 빌드 시도 결과, 결과는 매우 냉혹했습니다.
- "빌드"의 벽: 대부분의 AI 첫 번째 시도는 컴파일에 실패했습니다. 실패 원인의 약 **80%**는 AI가 잘못된 로직을 작성했기 때문이 아니라, AI가 테스트 프로그램을 자동차의 나머지 소프트웨어와 어떻게 연결해야 하는지 몰랐기 때문이었습니다. 이는 마치 AI가 자동차 엔진은 만들었지만, 바퀴나 연료 라인을 연결하는 것을 잊어버린 것과 같습니다.
- "스텁(Stub)"의 함정: 연구진은 AI에게 두 번째 기회를 주었습니다. 에러 메시지를 보여주고 코드를 수정하도록 요청한 것입니다(이를 "컴파일러 인 더 루프(compiler-in-the-loop) 복구"라고 합니다). AI는 에러를 수정하는 능력이 향려되었고, 결국 **100%**의 프로그램을 컴파일하는 데 성공했습니다.
- 하지만, 함정이 있었습니다. 코드를 컴파일하기 위해 AI는 종종 자동차 소프트웨어의 실제 복잡한 부분들을 "스텁(stub)"으로 대체했습니다. 스텁은 문 모양의 판지 모형과 같습니다. 겉보기에는 문처럼 보이고 테스트 프로그램이 그 문을 "열 수"도 있지만, 그것은 실제 문이 아니며 아무 데도 연결되지 않습니다. AI는 본질적으로 실제 소프트웨어가 아닌 판지 모형을 향해 달리는 테스트용 자동차를 만들고 있었던 것입니다.
결과: 사고가 발견되지 않음 (실제 주행이 일어나지 않았기 때문에)
모든 수정과 컴파일을 마친 후, 연구진은 테스트를 실행해 보았습니다.
- 원래의 2,960번 시도 중 실제 Autoware 소프트웨어와 연결되어 퍼저(fuzzer, 코드를 망가뜨리려는 부분)에 도달한 것은 단 652번뿐이었습니다.
- 원래의 740개 용의자 중 위험하다고 확인된 사례는 0건이었습니다.
- 발생한 유일한 37건의 충돌은 무엇이었을까요? 그 충돌들은 모두 실제 Autoware 소프트웨어가 아니라, AI가 만든 "스텁"(판지 모형) 내부에서 발생한 것이었습니다.
이것이 의미하는 바
이 논문은 AI가 코드 조각을 쓰는 데는 뛰어나지만, 현재로서는 완전한 자율주행 자동차를 안전하게 테스트하는 데 필요한 복잡하고 통합된 테스트 환경을 자동으로 구축할 수는 없다고 결론짓습니다.
주된 장벽은 AI가 로직을 쓰지 못해서가 아니라, AI가 자신의 테스트 프로그램을 실제 자동차 소프트웨어와 연결할 때 시스템을 망가뜨리거나 연결을 가짜로 만들지 않고 어떻게 연결해야 할지 파악하지 못한다는 점입니다. 연구진은 "테스트 자체의 생성"이 아니라 "빌드 통합"(테스트가 실제 자동차 소프트웨어와 실제로 대화하게 만드는 것)이 병목 현상임을 발견했습니다.
핵식 요약:
이 연구는 우리가 자율주행 소프트웨어의 안전성을 확인하기 위해 아직 AI에 자율적으로 의존할 수 없음을 시사합니다. AI는 실제 사물이 아닌 "가짜" 테스트를 만드는 경향이 있으며, 이는 컴파일은 되지만 실제로는 아무것도 테스트하지 못하는 결과로 이어집니다. AI가 판지 모형이 아닌 실제 도시로 달리는 테스트용 자동차를 만드는 법을 배울 때까지, 이러한 안전 필수 경로를 검증하는 무거운 작업은 여전히 인간 엔지니어의 몫으로 남을 것입니다. 정적 분석(지도)은 어디를 살펴봐야 할지 찾는 데 여전히 유용하지만, 동적 확인(테스트 드라이브)은 아직 AI가 스스로 해내기에는 준비가 되지 않은 영역입니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.