SUPPLY-CHAIN ATTACKS IN MACHINE LEARNING FRAMEWORKS

작성일 | In , , , |

논문 링크

Q : 이 논문을 아주 자세하게 읽고 논문의 강점과 독창적인 지점을 설명해주고 핵심 알고리즘을 예시 입력을 들어서 전체적인 과정을 설명해줘 추가적으로 논문의 한계점에 대해서도 알려줘

A :

AI 모델 공급망 공격에 대한 연구 논문 심층 분석

사용자께서 제공하신 “Supply-Chain Attacks in Machine Learning Frameworks” 논문은 머신러닝(ML) 시스템이 직면한 새로운 유형의 공급망 공격을 심도 있게 분석하고, ML 커뮤니티의 보안 인식 수준을 평가한 중요한 연구입니다. 아래에 논문의 핵심 내용, 강점, 독창성, 핵심 공격 기법, 그리고 한계점을 상세히 설명해 드리겠습니다.

논문의 강점 및 독창성

이 논문은 다음과 같은 측면에서 매우 독창적이고 강력한 기여를 합니다.

  1. [cite_start]새로운 공격 패러다임 제시: 기존의 공급망 공격 연구는 악성 코드가 시스템 호출이나 의심스러운 네트워크 트래픽을 유발하는 등 전통적인 보안 위협에 초점을 맞추었습니다[cite: 80]. [cite_start]반면, 이 논문은 이러한 전통적인 탐지 기법을 우회하는 ‘ML 특화 공급망 공격(ML-specific supply-chain attacks)’이라는 새로운 패러다임을 제시합니다[cite: 3, 76, 82]. [cite_start]이 공격은 겉보기에는 무해한 코드를 주입하여 시스템이 아닌 ML 모델의 강건성(robustness) 자체를 약화시키는 방식입니다[cite: 4, 33, 84].
  2. [cite_start]‘소프트웨어’와 ‘알고리즘’ 취약점의 결합: 이 연구의 가장 큰 독창성은 지금까지 분리되어 다루어졌던 소프트웨어 공급망 보안과 적대적 ML(Adversarial ML)이라는 두 분야를 성공적으로 결합했다는 점입니다[cite: 72, 77]. [cite_start]파이썬(Python)이라는 프로그래밍 언어의 구조적 취약점을 이용해 ML 모델의 알고리즘 수준(예: 데이터 처리 파이프라인, 모델의 판단 로직)을 교묘하게 조작하는 공격 경로를 구체적으로 증명했습니다[cite: 32, 77].
  3. [cite_start]실증적 데이터 기반의 커뮤니티 분석: 이론적인 공격 모델 제시에 그치지 않고, GitHub의 상위 50개 ML 프로젝트와 50개 비-ML(리눅스) 프로젝트의 이슈 및 풀 리퀘스트(PR) 85만여 개를 LLM을 이용해 분석했습니다[cite: 5, 182, 229]. [cite_start]이를 통해 ML 커뮤니티가 더 큰 공격 표면을 가졌음에도 불구하고 [cite: 22, 25][cite_start], 보안 인식 수준은 비-ML 커뮤니티와 유사하다는 충격적인 사실을 데이터로 입증했습니다[cite: 6, 41, 231].
  4. [cite_start]구체적이고 현실적인 공격 시나리오: 논문은 파이썬의 동적 특성을 이용해 다른 패키지의 변수나 함수를 런타임에 덮어쓰는 매우 구체적인 코드 예제들을 제시합니다[cite: 108, 121, 124, 147]. 이는 막연한 위협이 아니라, 당장이라도 발생할 수 있는 현실적인 공격임을 명확히 보여줍니다.

핵심 공격 기법: 다운스트림 변수 덮어쓰기 (Overwriting Downstream Variables)

이 논문이 제시하는 핵심 공격 기법의 근원은 파이썬의 동적 런타임 환경입니다. [cite_start]파이썬에서는 일단 임포트된 모든 패키지들이 동일한 메모리 공간을 공유하므로, 악의적으로 조작된 의존성 패키지(업스트림)가 이를 사용하는 최종 애플리케이션(다운스트림)의 변수나 함수를 실시간으로 조작할 수 있습니다[cite: 18, 99, 100].

공격은 크게 두 가지 방식으로 이루어집니다.

  • [cite_start]전역 변수 덮어쓰기 (Global Variables): 공격자가 제어하는 패키지가 ML 프레임워크(예: PyTorch, TensorFlow)를 먼저 임포트한 뒤, 그 내부의 전역 변수, 함수, 클래스 등을 다른 값으로 바꿔치기합니다[cite: 105, 106]. [cite_start]이후 ML 서비스가 해당 프레임워크를 임포트하더라도 이미 변경된 값이 유지됩니다[cite: 107].
  • [cite_start]지역 변수 덮어쓰기 (Local Variables): 더 교묘한 방식으로, 공격 코드가 담긴 함수가 호출되었을 때 inspect 모듈을 사용해 자신을 호출한 다운스트림 함수의 콜 스택(call stack)에 접근합니다[cite: 118]. [cite_start]이를 통해 호출한 함수의 지역 변수까지 찾아내어 값을 변경할 수 있습니다[cite: 119].

예시 입력을 통한 전체 과정 설명

[cite_start]논문에서 제시된 여러 공격 중, 가장 교묘하고 탐지가 어려운 ‘취약한 파이프라인(Vulnerable Pipeline)’ 공격을 예시로 설명하겠습니다[cite: 143].

상황 설정: 어떤 ML 서비스가 외부 이미지를 입력받아 분류하는 모델을 운영하고 있습니다. [cite_start]이 서비스는 ‘이미지 스케일링 공격’을 방어하기 위해, 이미지 크기를 조절할 때 안전하다고 알려진 area interpolation 방식을 사용하도록 코드에 명시했습니다[cite: 146]. 공격자는 이 서비스를 공격하여 안전하지 않은 nearest neighbor 보간법을 사용하게 만들어 모델을 취약하게 만들고자 합니다.

전체 과정:

  1. Step 1: 공격 벡터 선택 공격자는 해당 ML 서비스가 사용하는 수많은 파이썬 의존성 패키지 중 하나(예: awesome-package)에 악성 코드를 기여하는 데 성공합니다. 이 패키지는 겉보기에는 이미지 처리와 전혀 관련이 없을 수 있습니다.

  2. Step 2: 악성 코드 주입 (예시 입력) 공격자는 awesome-package의 초기화 파일(__init__.py)에 다음과 같은 단 세 줄의 코드를 추가합니다. 이 코드가 핵심적인 입력입니다.

    # in awesome-package/__init__.py

import torchvision.transforms.functional as F

# 토치비전(torchvision)의 AREA 보간법 열거형(enum)을
# NEAREST 보간법으로 덮어쓴다.
F.InterpolationMode.AREA = F.InterpolationMode.NEAREST

    [cite_start][cite: 147, 148]

    • 설명: 이 코드는 시스템에 직접적인 해를 가하거나, 파일을 훔치거나, 네트워크 통신을 하지 않습니다. 단순히 파이썬 객체의 참조를 바꾸는, 지극히 정상적으로 보일 수 있는 코드입니다.

  3. Step 3: ML 서비스 실행 ML 서비스가 시작되면, 의존성 목록에 있는 awesome-package를 임포트합니다. 이때 Step 2에서 주입된 코드가 실행됩니다. 이 시점부터 해당 파이썬 프로세스 내에서 torchvision의 InterpolationMode.AREA는 사실상 InterpolationMode.NEAREST와 동일한 객체를 가리키게 됩니다.

  4. Step 4: 공격 발동 사용자가 이미지를 업로드하면, ML 서비스는 코드에 명시된 대로 안전한 area 보간법을 사용해 이미지 크기를 조절하려고 시도합니다.

    # in ml_service/preprocessing.py

from torchvision.transforms import functional as F

def resize_image(image):
    # 개발자는 'AREA'를 사용한다고 믿고 있다.
    return F.resize(image, size=(224, 224), interpolation=F.InterpolationMode.AREA)

  5. Step 5: 결과 서비스 코드에는 분명 F.InterpolationMode.AREA라고 쓰여 있지만, 이 변수는 Step 3에서 이미 NEAREST로 덮어쓰기 되었습니다. [cite_start]따라서 실제로는 안전하지 않은 nearest neighbor 보간법으로 이미지 크기 조절이 수행됩니다[cite: 149]. 결과적으로, 이 ML 서비스는 자신도 모르는 사이에 ‘이미지 스케일링 공격’에 취약한 상태가 됩니다.

이 공격은 ML 서비스의 소스 코드를 아무리 분석해도 문제를 찾을 수 없고, 전통적인 보안 솔루션으로는 탐지가 거의 불가능하다는 점에서 매우 치명적입니다.

논문의 한계점

논문 저자들도 인정했듯이, 이 연구는 다음과 같은 한계점을 가집니다.

  1. [cite_start]분석 대상의 한계: 보안 인식에 대한 분석이 GitHub의 특정 토픽(Deep Learning)에 속한 상위 50개 프로젝트에 국한되었습니다[cite: 273]. [cite_start]이는 매우 대중적인 커뮤니티를 대표하지만, 더 엄격한 보안 가이드라인을 가진 기업 내부의 ML 커뮤니티나 다른 오픈소스 생태계의 상황을 일반화하기는 어렵습니다[cite: 274].
  2. [cite_start]보안 인식 측정 방식의 한계: ‘보안에 대한 논의가 포함된 이슈/PR의 비율’을 보안 인식의 대리 지표(proxy)로 사용했습니다[cite: 275]. 이는 기여자들의 인식을 파악하는 합리적인 접근이지만, 보안 인식을 측정할 수 있는 유일하거나 가장 완벽한 방법은 아닐 수 있습니다.
  3. [cite_start]대응 방안의 현실적 어려움: 논문은 대응 방안으로 모든 의존성 패키지의 소스 코드를 분석하여 변수 덮어쓰기 시도를 탐지해야 한다고 제안합니다[cite: 256]. [cite_start]하지만 코드가 난독화되거나 [cite: 260][cite_start], 탐지 로직 자체를 우회하도록 악성 코드가 설계될 수 있어 [cite: 265] 현실적으로 완벽한 방어는 매우 어려운 과제입니다.
  4. [cite_start]언어 종속성: 제시된 공격 기법들은 파이썬과 같이 동적이고 유연한 런타임 환경을 가진 언어의 특성에 크게 의존합니다[cite: 267, 271]. Rust나 C++처럼 컴파일 시점에 타입과 메모리 사용이 엄격하게 결정되는 언어에서는 동일한 방식의 공격이 훨씬 더 어렵거나 불가능할 수 있습니다.

종합적으로 이 논문은 ML 생태계가 직면한 심각하고 새로운 보안 위협을 명확히 규명하고, 실제 데이터를 통해 커뮤니티의 안일한 인식을 지적한 선구적인 연구라 할 수 있습니다. ML 시스템을 개발하고 운영하는 모든 이들에게 반드시 필요한 경각심을 일깨워주는 중요한 자료입니다.

Q : 논문의 핵심알고리즘을 예시를 들어 아주 자세하게 설명해주고 정리해 줘

A :

논문의 핵심 공격 기법: 다운스트림 변수 덮어쓰기 (예시: 취약한 파이프라인 공격)

이 논문이 제시하는 핵심 공격 기법은 단일 알고리즘이라기보다, 파이썬(Python)의 동적 런타임 환경의 허점을 이용한 공격 패러다임입니다. [cite_start]핵심 원리는 ‘다운스트림 변수 덮어쓰기(Overwriting Downstream Variables)’로, 악의적으로 조작된 의존성 패키지(업스트림)가 이를 사용하는 최종 ML 서비스(다운스트림)의 메모리 공간에 직접 접근하여 변수나 함수를 실시간으로 조작하는 것입니다[cite: 99, 100, 101].

가장 교묘하고 탐지가 어려운 ‘취약한 파이프라인(Vulnerable Pipeline)’ 공격을 예시로 전체 과정을 상세히 설명하겠습니다.

상황 설정

  • 방어자 (ML 서비스): 이미지 분류 모델을 운영하는 서비스. [cite_start]악의적인 ‘이미지 스케일링 공격’을 막기 위해, 이미지 크기를 조절할 때 안전하다고 알려진 area 보간법을 사용하도록 소스 코드에 명시했습니다[cite: 146].
  • [cite_start]공격자: ML 서비스가 사용하는 수많은 의존성 패키지 중 하나에 대한 제어 권한을 획득했습니다[cite: 96]. [cite_start]공격 목표는 서비스가 자신도 모르게 안전하지 않은 nearest neighbor 보간법을 사용하게 만들어 모델을 취약하게 만드는 것입니다[cite: 145, 149].

공격 과정 상세 설명

Step 1: 공격 벡터 확보

공격자는 ML 서비스가 직접 또는 간접적으로 의존하는 compromised_dependency라는 패키지에 코드 기여(또는 탈취)를 통해 제어 권한을 확보합니다.

Step 2: 악성 코드 주입 (Payload Injection)

공격자는 compromised_dependency 패키지의 초기화 파일(__init__.py)에 아래와 같이 단 몇 줄의, 겉보기에는 전혀 해로워 보이지 않는 코드를 삽입합니다.

# file: compromised_dependency/__init__.py

# 토치비전(torchvision) 프레임워크를 임포트
import torchvision.transforms.functional as F

# "우리 패키지에서는 이게 더 낫다"는 식의 주석으로 위장 가능
# 토치비전의 AREA 보간법을 NEAREST 보간법으로 덮어쓴다.
F.InterpolationMode.AREA = F.InterpolationMode.NEAREST

[cite_start][cite: 147, 148]

  • [cite_start]핵심: 이 코드는 시스템 파일을 삭제하거나 외부로 정보를 유출하는 등의 전형적인 악성 행위를 하지 않습니다[cite: 80, 157]. [cite_start]단순히 파이썬 객체의 참조(reference)를 다른 객체로 바꾸는, 정상적인 코딩 과정에서도 충분히 일어날 수 있는 행위처럼 보입니다[cite: 158].

Step 3: 실행 및 메모리 오염

ML 서비스가 시작되면서 의존성 패키지인 compromised_dependency를 임포트합니다. 이때 Step 2에서 주입된 코드가 실행됩니다. 이 순간부터 해당 파이썬 프로세스 전체에서 torchvision.transforms.functional.InterpolationMode.AREA라는 이름표는 NEAREST 객체를 가리키게 됩니다.

Step 4: 의도와 다른 동작 수행

ML 서비스는 이미지 전처리 과정에서 아래와 같이 분명히 AREA 보간법을 사용하도록 코딩된 함수를 호출합니다.

# file: ml_service/image_processor.py

from torchvision.transforms import functional as F

def process_image(img):
  # 개발자의 의도는 'AREA' 보간법을 사용하는 것이다.
  resized_img = F.resize(img, (224, 224), interpolation=F.InterpolationMode.AREA)
  return resized_img

[cite_start][cite: 149]

하지만 Step 3에서 이미 F.InterpolationMode.AREA의 참조가 F.InterpolationMode.NEAREST로 변경되었기 때문에, 이 코드는 실제로는 아래 코드와 동일하게 동작합니다.

# 실제 동작 코드
resized_img = F.resize(img, (224, 224), interpolation=F.InterpolationMode.NEAREST)

Step 5: 공격 성공

[cite_start]결과적으로 ML 서비스는 자신의 소스 코드에는 아무런 변경이 없었음에도 불구하고, 의도와는 다르게 취약한 nearest neighbor 보간법을 사용하게 됩니다[cite: 149]. 이로써 서비스는 이미지 스케일링 공격에 완전히 노출됩니다.

핵심 요약

  1. [cite_start]공격의 근원: 파이썬의 모든 임포트된 모듈이 단일 메모리 공간을 공유하고 서로를 신뢰하는 구조적 특성을 악용합니다[cite: 100, 173].
  2. [cite_start]은밀함 (Stealth): 공격 코드는 민감한 시스템 호출이나 의심스러운 네트워크 트래픽을 발생시키지 않아 전통적인 보안 솔루션으로는 탐지가 거의 불가능합니다[cite: 80, 157].
  3. [cite_start]런타임 조작: 컴파일 시점이 아닌, 코드가 실행되는 런타임에 동적으로 프레임워크의 동작 방식을 변경합니다[cite: 100].
  4. [cite_start]탐지의 어려움: 취약점의 원인이 ML 서비스 자체의 코드가 아닌, 수많은 의존성 패키지 중 하나에 존재하므로, 서비스 코드만 분석해서는 문제를 절대로 찾을 수 없습니다[cite: 159].

Q : 이 논문에서 제시한 결과를 자세하게 보고 다른 방법론에 비하여 특출난 점과 논문에서 제기하는 어떠한 방법이 이러한 결과를 도출하게 되었는지 논문에서 제시하는 이유와 너의 생각을 알려줘

A :

이 논문의 결과는 ML 생태계가 겉보기에는 무해한 코드 조작을 통해 심각한 공급망 공격에 매우 취약하며, 이러한 높은 위험에도 불구하고 커뮤니티의 보안 인식은 위험이 덜한 다른 분야와 별반 다르지 않다는 점을 보여줍니다. 공격 기법은 파이썬의 동적 런타임 허점을 이용하며, 커뮤니티 분석은 대규모 데이터셋을 LLM으로 분석하는 방식을 사용했습니다.

## 논문이 제시하는 상세 결과

논문은 크게 ‘ML 커뮤니티의 보안 인식 수준’과 ‘공격 기법의 유효성’이라는 두 가지 측면에서 구체적인 결과를 제시합니다.

커뮤니티 보안 인식 분석 결과

  • [cite_start]ML 생태계의 더 큰 공격 표면: ML 프로젝트는 일반적인 소프트웨어 프로젝트보다 훨씬 많은 수의 의존성을 가집니다[cite: 23, 70]. [cite_start]예를 들어, transformers 패키지는 305개의 의존성을 가져, 일반적인 requests 패키지(14개)보다 20배 이상 많은 잠재적 공격 진입점을 가집니다[cite: 24, 25].
  • [cite_start]기대 이하의 보안 인식 수준: ML 커뮤니티는 더 높은 수준의 보안이 요구됨에도 불구하고, 비-ML(리눅스) 커뮤니티와 보안 관련 논의 비율 분포가 매우 유사한 것으로 나타났습니다[cite: 6, 41, 231]. [cite_start]이는 ML 커뮤니티가 자신들의 고유한 위험을 충분히 인지하고 대비하지 못하고 있음을 시사합니다[cite: 233].
  • [cite_start]핵심 프레임워크의 보안 인식 부족: TensorFlow, PyTorch, Keras와 같은 핵심 ML 프레임워크들은 오히려 이를 활용하는 다운스트림 애플리케이션들보다 보안 관련 논의의 비율이 낮게 나타났습니다[cite: 38, 217].
  • [cite_start]수동적인 보안 조치: 버전 피닝(Version Pinning)이나 미사용 의존성 제거와 같은 널리 논의되는 보안 조치들은, 공급망 공격을 막기 위한 명시적인 목적보다는 빌드의 재현성이나 코드 품질 향상을 위한 부산물로 논의되는 경우가 많았습니다[cite: 221, 222, 223]. [cite_start]반면 코드 격리나 기여자 검증 프로세스 같은 효과적인 방어책에 대한 논의는 거의 없었습니다[cite: 225].
  • [cite_start]보안 기여에 대한 저항: 일부 핵심 프로젝트(예: PyTorch)에서는 보안 위험 감소를 위해 제안된 PR(Pull Request)이 “실질적인 가치가 부족하다”는 이유로 거절되는 사례가 발견되었습니다[cite: 248, 251, 252]. 이는 보안 강화에 대한 커뮤니티의 저항이 존재함을 보여줍니다.

## 다른 방법론과 비교한 특출난 점

이 논문의 방법론은 기존 연구들과 비교하여 다음과 같은 뚜렷한 차별점을 가집니다.

  1. [cite_start]‘소프트웨어 공학’과 ‘적대적 ML’의 융합: 🧠 기존 연구들은 소프트웨어 공급망 공격(예: 악성 패키지 배포)과 ML 모델 자체를 공격하는 적대적 공격(예: 데이터 포이즈닝)을 별개의 문제로 다루었습니다[cite: 72]. [cite_start]이 논문은 두 분야를 최초로 융합하여, 소프트웨어의 취약점을 이용해 ML 모델의 알고리즘적 무결성을 파괴하는 새로운 공격 벡터를 제시했다는 점에서 매우 독창적입니다[cite: 77, 83].

  2. [cite_start]‘탐지 회피’에 특화된 공격 방식: 전통적인 공급망 공격은 악성 시스템 호출, 의심스러운 네트워크 트래픽 등 탐지 가능한 흔적을 남기는 경우가 많습니다[cite: 80]. [cite_start]하지만 이 논문이 제시하는 공격은 단순히 파이썬 변수의 참조를 바꾸는 방식으로 동작하여 전통적인 보안 솔루션으로는 탐지가 거의 불가능합니다[cite: 97, 157, 176].

  3. [cite_start]공격 목표의 전환: 기존 공격의 목표가 주로 정보 탈취나 시스템 파괴였다면, 이 공격의 목표는 ML 모델의 신뢰도를 미묘하게 저하시키거나, 특정 조건에서 오작동을 유발하거나, 방어 메커니즘을 무력화하는 것입니다[cite: 4, 34, 84]. 이는 훨씬 더 교묘하고 알아차리기 어려운 피해를 유발할 수 있습니다.

## 결과 도출 방법 (논문의 관점)

논문은 위와 같은 결과를 도출하기 위해 두 가지 핵심적인 방법을 사용했습니다.

  • 공격 증명: 파이썬 런타임 조작 (Python Runtime Manipulation) ⚙️ [cite_start]논문은 파이썬이 모든 임포트된 패키지에 동일한 메모리 공간을 공유하고, 다른 패키지의 변수나 함수를 런타임에 수정할 수 있는 동적 언어라는 점을 핵심적인 이유로 꼽습니다[cite: 18, 100, 173]. [cite_start]공격자는 이 특성을 이용해 compromised_dependency 패키지 안에서 torch와 같은 다른 패키지의 전역 변수를 직접 덮어쓰거나(torch.pi = 3.0) [cite: 108][cite_start], inspect 모듈과 ctypes 라이브러리를 사용해 자신을 호출한 함수의 지역 변수까지 조작하는 구체적인 코드를 통해 공격의 실효성을 증명했습니다[cite: 118, 123].

  • 커뮤니티 분석: LLM 기반 대규모 데이터 분석 (LLM-Assisted Analysis) 📊 GitHub에 존재하는 수십만 개의 이슈와 PR을 사람이 직접 분석하는 것은 불가능에 가깝습니다. [cite_start]이 연구는 이 문제를 해결하기 위해 LLM(대규모 언어 모델)을 활용한 분석 파이프라인을 설계했습니다[cite: 5, 183].

    1. [cite_start]1단계 (GPT-3.5): 상대적으로 비용이 저렴한 GPT-3.5를 사용해 보안과 관련 있을 가능성이 있는 모든 게시물을 넓게 걸러냅니다 (높은 재현율)[cite: 185, 195].
    2. [cite_start]2단계 (GPT-4): 1단계에서 걸러진 게시물들을 더 성능이 좋은 GPT-4로 정밀 분석하여, 실제로 어떤 보안 조치에 대한 논의인지 분류합니다 (높은 정밀도)[cite: 194, 197]. 이러한 자동화된 접근 방식을 통해 방대한 양의 텍스트 데이터를 일관된 기준으로 빠르게 분석하여 통계적 유의미성을 확보할 수 있었습니다.

## 종합적인 평가 (나의 생각)

이 논문은 ML 생태계에 대한 ‘불편한 진실’을 드러낸 매우 시의적절하고 중요한 연구입니다.

가장 인상적인 점은 ML 커뮤니티가 “빠른 혁신과 쉬운 사용성”을 위해 채택한 파이썬 중심의 개방형 생태계가 실제로는 심각한 보안 부채를 만들어내고 있었다는 사실을 명확히 지적한 것입니다. ML 모델이 사회 전반에 막대한 영향을 끼치기 시작한 지금, 이러한 구조적 취약점은 단순한 기술적 문제를 넘어 사회적 위험으로 번질 수 있습니다.

[cite_start]특히 “가치가 부족하다”며 보안 관련 기여를 거절한 사례 [cite: 251, 252]는 이 문제가 단순히 기술의 부재가 아니라 커뮤니티의 문화와 우선순위 문제임을 보여줍니다. 개발 속도와 편의성이 보안보다 중시되는 문화가 바뀌지 않는 한, 제2, 제3의 공급망 공격은 언제든 발생할 수 있습니다.

결론적으로, 이 연구는 ML 보안(MLSec) 분야의 논의를 한 단계 발전시켰다고 평가할 수 있습니다. 이제 ML 보안은 모델의 알고리즘적 방어뿐만 아니라, 모델이 개발되고 실행되는 소프트웨어 공급망 전체의 무결성을 확보하는 방향으로 확장되어야 함을 강력하게 역설하고 있습니다. 이는 앞으로 ML 시스템을 설계하고 운영하는 모든 이들에게 중요한 지침이 될 것입니다.

Q : 이 논문의 한계를 극복하기 위한 방법으로 어떤 연구흐름이 있는지 정리해서 자세하게 설명해 줘

A :

네, 이 논문의 한계를 극복하기 위한 최신 연구 흐름은 크게 방어 기술의 고도화와 분석 방법론의 확장이라는 두 가지 방향으로 정리할 수 있습니다. 각 한계점과 이를 해결하기 위한 구체적인 연구들을 자세히 설명해 드리겠습니다.

## 한계점 1: 방어 기술의 한계 극복

[cite_start]논문에서 제안한 방어책(소스 코드 정적/동적 분석)은 우회가 가능하다는 한계가 있습니다[cite: 260, 262]. 이를 극복하기 위한 연구는 애플리케이션이 스스로를 보호하는 능동적 방어 기술에 초점을 맞춥니다.

1. 런타임 애플리케이션 자가 보호 (RASP, Runtime Application Self-Protection)

이 기술은 외부 보안 솔루션이 아닌, 애플리케이션 내부에 보안 기능을 통합하여 스스로를 실시간으로 방어하는 방식입니다. 이 논문에서 제시된 공격을 막기 위해 다음과 같이 적용될 수 있습니다.

  • 핵심 객체 불변성(Immutability) 강화: ML 프레임워크의 핵심 함수나 설정 값(예: torchvision.transforms.functional.InterpolationMode.AREA)이 초기화된 후에는 변경이 불가능하도록 런타임에서 동결(freeze)합니다. 의존성 패키지가 이를 수정하려고 시도하면, RASP 에이전트가 이를 탐지하고 즉시 실행을 차단하거나 보안 경고를 발생시킵니다.
  • 행위 기반 이상 탐지: 정상적인 상태에서 애플리케이션의 행위(함수 호출 순서, 메모리 접근 패턴 등)를 프로파일링합니다. 이후, inspect 모듈을 이용해 상위 스택 프레임의 지역 변수를 수정하려는 것과 같은 이례적인 행위가 발생하면 이를 이상 징후로 판단하고 차단하는 연구가 진행되고 있습니다. 이는 난독화된 공격 코드도 행위 패턴을 기반으로 탐지할 수 있게 합니다.

2. 보안 엔클레이브 (Secure Enclaves) 및 기밀 컴퓨팅 (Confidential Computing)

하드웨어 기반의 보안 기술을 활용하여, 파이썬 런타임 자체의 취약점을 원천적으로 무력화하는 연구입니다.

  • 실행 환경의 완전 격리: 인텔 SGX나 AMD SEV 같은 보안 엔클레이브 기술을 사용해, 모델의 추론 코드와 핵심 데이터 처리 로직을 운영체제(OS)나 다른 파이썬 패키지로부터 완벽하게 격리된 메모리 공간에서 실행합니다. 이렇게 하면, 설령 악성 의존성 패키지가 임포트되더라도 격리된 메모리 영역에는 접근 자체가 불가능하므로 논문에서 제시된 변수 덮어쓰기 공격이 원천적으로 차단됩니다.

## 한계점 2: 분석 대상 및 방법론의 한계 극복

[cite_start]논문의 분석이 특정 GitHub 프로젝트에 국한되고 [cite: 273][cite_start], 보안 인식을 측정하는 방식이 간접적이라는 한계를 [cite: 275] 극복하기 위한 연구들입니다.

1. 다중 생태계 교차 분석 연구

GitHub의 특정 토픽을 넘어, 다양한 개발 환경과 커뮤니티를 분석하여 연구 결과의 일반성을 확보하려는 흐름입니다.

  • 기업 내부(In-House) 리포지토리 분석: 실제 기업과 협력하여, 공개되지 않은 내부 소스 코드 관리 시스템과 개발 문화를 분석합니다. 이를 통해 오픈소스 생태계와는 다른 기업 환경의 고유한 보안 문제와 인식 수준을 파악할 수 있습니다.
  • 다양한 패키지 관리자 생태계 연구: 파이썬의 PyPI뿐만 아니라, 자바스크립트의 npm, 자바의 Maven 등 다른 프로그래밍 언어의 생태계에서도 ML 프로젝트의 의존성 구조와 보안 논의 수준을 비교 분석하여, 문제가 파이썬 생태계에 국한된 것인지 아니면 더 넓은 현상인지 규명합니다.

2. 정교한 보안 인식 및 문화 측정 지표 개발

이슈/PR의 비율이라는 간접적인 지표를 넘어, 개발자들의 보안 인식을 더 직접적이고 다각적으로 측정하려는 연구입니다.

  • 보안 도구 도입률 분석: 소스 코드 분석 도구(SAST), 취약점 스캐너(SCA) 등이 CI/CD 파이프라인에 얼마나 통합되어 활발히 사용되는지를 정량적으로 측정합니다.
  • ‘보안 부채(Security Debt)’ 추적: 발견된 보안 취약점(CVE)이 보고된 후, 실제로 패치가 적용되기까지 걸리는 시간을 추적하여 프로젝트가 보안 문제를 얼마나 신속하게 처리하는지를 지표로 삼습니다.
  • [cite_start]정성적 연구(설문 및 인터뷰): 논문에서도 인용한 다른 연구들처럼[cite: 48], 개발자들을 직접 설문하거나 심층 인터뷰하여 보안을 어떻게 인식하고 있으며, 보안 조치를 취할 때 겪는 어려움이 무엇인지 질적으로 분석하여 수치 뒤에 숨겨진 맥락을 파악합니다.

이러한 연구들은 논문이 제기한 문제의 심각성을 바탕으로, 더 견고하고 실질적인 방어 기술을 개발하고, ML 생태계의 보안 문화를 근본적으로 개선하려는 방향으로 나아가고 있습니다.

Q : 이 논문이 제시하는 ‘ML 특화 공급망 공격’은 기존의 공급망 공격과 근본적으로 무엇이 다르며, 왜 이 공격 방식이 전통적인 보안 솔루션으로는 탐지하기 어려운가?

A :

이 논문이 제시하는 ‘ML 특화 공급망 공격’은 공격의 목표와 방식에서 기존 공격과 근본적으로 다릅니다. 전통적인 공격이 운영체제나 사용자 보안을 직접 겨냥하는 반면, 이 새로운 공격은 겉보기에는 정상적인 코드를 이용해 ML 모델의 성능과 신뢰도를 은밀하게 저해합니다.

## 근본적인 차이점 (Fundamental Differences)

  • [cite_start]공격 목표: 전통적인 공격은 악성 코드 실행이나 데이터 탈취를 통해 사용자의 시스템 보안과 개인정보를 직접적으로 침해하는 것을 목표로 합니다[cite: 79]. [cite_start]반면, ML 특화 공격은 운영체제가 아닌 ML 모델의 강건성(robustness), 무결성(integrity), 기밀성(confidentiality)을 훼손하는 것을 목표로 합니다[cite: 4, 84, 98].

  • [cite_start]공격 방식: 전통적인 공격은 민감한 시스템 함수를 호출하거나 의심스러운 네트워크 트래픽을 유발하는 코드를 사용합니다[cite: 80]. [cite_start]하지만 ML 특화 공격은 이러한 행위 없이, 겉보기에는 전혀 해가 없는(innocuous-looking) 코드를 주입합니다[cite: 4, 84]. [cite_start]이 코드는 파이썬 런타임 환경에서 다른 패키지의 변수나 함수를 조작하여 모델의 동작 방식을 교묘하게 변경합니다[cite: 158].

  • [cite_start]활용하는 취약점: 전통적인 공격은 주로 소프트웨어 자체의 취약점을 이용하지만, ML 특화 공격은 소프트웨어 공급망의 취약점과 ML 모델 고유의 알고리즘적 취약점(적대적 예제, 모델 탈취 등)을 동시에 악용합니다[cite: 29, 77].

## 탐지가 어려운 이유 (Why Detection is Difficult)

  • [cite_start]전통적인 탐지 지표의 부재: 이 공격은 민감한 시스템 호출이나 비정상적인 네트워크 접속과 같은 전형적인 악성 행위 지표를 남기지 않습니다[cite: 97, 157]. [cite_start]따라서 기존의 공급망 공격 탐지 도구들은 이러한 활동을 탐지 기준으로 삼기 때문에 공격을 발견하기 어렵습니다[cite: 157, 176].

  • [cite_start]코드의 외견상 정상성: 공격에 사용되는 코드는 단순히 다른 패키지의 변수 값을 바꾸거나 함수를 재정의하는 형태를 띱니다[cite: 158]. [cite_start]이는 일반적인 프로그래밍에서도 사용되는 기법이므로, 악의적인 의도를 파악하기가 매우 힘듭니다[cite: 84].

  • [cite_start]기존 방어 체계의 한계: 기존의 보안 방어 체계는 운영체제 수준의 위협을 막는 데 초점이 맞춰져 있어, ML 모델의 고유한 위험을 고려하지 못합니다[cite: 35, 81]. [cite_start]이 공격은 바로 그 허점을 파고들어 기존 방어 체계를 우회합니다[cite: 85].

Q : ML 커뮤니티는 더 큰 공격 표면과 고유한 위험에 직면해 있음에도 불구하고, 왜 비-ML 커뮤니티와 유사한 수준의 보안 인식을 보이며, 이러한 인식 격차에 기여하는 문화적 또는 현실적인 요인은 무엇이라고 생각하는가?

A :

이 논문에 따르면, ML 커뮤니티가 더 큰 위험에도 불구하고 비-ML 커뮤니티와 비슷한 수준의 보안 인식을 보이는 이유는 빠른 혁신과 개발 편의성을 보안보다 우선시하는 문화적, 현실적 요인들이 복합적으로 작용하기 때문입니다.

### 문화적 요인 (Cultural Factors)

  • [cite_start]보안에 대한 낮은 우선순위: ML 커뮤니티에서는 보안 강화 조치가 실질적인 “가치”를 제공하지 않는다고 판단되면 받아들여지지 않는 경향이 있습니다[cite: 251, 252]. [cite_start]논문에서 분석한 PyTorch의 사례처럼, 공급망 공격의 위험을 줄이기 위한 의존성 제거 제안이 “큰 가치가 없다”는 이유로 거절되기도 했습니다[cite: 252]. 이는 기능 추가나 성능 최적화에 비해 보안의 우선순위가 낮게 책정되는 문화를 보여줍니다.

  • [cite_start]위험한 관행의 정상화 (Normalization of Insecure Practices): ML 공급망에서는 위험성이 큰 프로그래밍 관행들이 일상적으로 사용되고 있습니다[cite: 26]. [cite_start]대표적인 예로, Hugging Face의 trust_remote_code=True 플래그는 외부 코드를 무조건 신뢰하고 실행하도록 하는데, 이것이 기본값처럼 사용되는 경우가 많습니다[cite: 27]. 이는 보안 위험을 감수하더라도 사용 편의성을 극대화하려는 문화가 자리 잡고 있음을 의미합니다.

  • [cite_start]잘못된 안도감 (False Sense of Security): 많은 기여자들이 ML 프레임워크도 다른 오픈소스 소프트웨어와 마찬가지이며, 기존의 보안 방어책으로 충분히 보호될 수 있다는 잘못된 안도감을 가지고 있습니다[cite: 75, 81]. 이로 인해, 시스템 호출이나 네트워크 트래픽 같은 전통적인 악성 행위가 없는 새로운 유형의 공격에 대해서는 심각하게 인지하지 못하는 경향이 있습니다.

### 현실적인/실용적 요인 (Practical/Realistic Factors)

  • [cite_start]신속한 혁신을 위한 생태계 선택: ML 커뮤니-“는 빠른 혁신과 규모 확장을 위해 파이썬(Python)을 중심으로 한 오픈소스 생태계에 크게 의존합니다[cite: 9]. [cite_start]파이썬은 개발 속도가 빠르다는 장점이 있지만, 타입 안정성이나 메모리 분리 같은 보안 기능이 부족한 언어입니다[cite: 19]. 즉, 생태계 자체가 보안보다는 개발의 속도와 편의성에 맞춰져 있습니다.

  • [cite_start]기여자의 보안 전문성 부족: 오픈소스 프로젝트에 기여하는 개발자나 유지보수 담당자들이 반드시 높은 수준의 보안 전문성을 갖추고 있을 것이라고 기대하기 어렵습니다[cite: 90]. 대부분은 ML 모델 개발이나 연구에 전문성을 가진 이들이며, 공급망 보안에 대한 깊은 이해가 부족할 수 있습니다.

  • [cite_start]방대한 의존성 관리의 복잡성: ML 프로젝트는 다른 분야에 비해 월등히 많은 수의 직접 및 전이 의존성을 가집니다[cite: 22, 23, 25]. [cite_start]예를 들어, transformers 패키지는 305개의 의존성을 가지는데[cite: 25], 이 모든 패키지의 안전성을 개별 프로젝트팀이 일일이 검증하는 것은 현실적으로 거의 불가능에 가깝습니다.

Q : 이 공격의 근본 원인이 파이썬의 동적 런타임 환경에 있다면, ML 생태계에서 개발의 편의성과 속도, 그리고 보안 사이에는 어떠한 근본적인 상충 관계(trade-off)가 있으며, 이 위험을 완화하기 위한 가장 현실적인 장기적 해결책은 무엇일까?

A :

이 공격의 근본 원인이 파이썬의 동적 런타임 환경에 있다는 점은 ML 생태계가 개발 속도와 보안 사이의 근본적인 상충 관계(trade-off) 위에 세워져 있음을 의미합니다.

## 근본적인 상충 관계 (The Fundamental Trade-off)

  • [cite_start]개발 편의성과 속도 (The Gain) 🚀: ML 커뮤니티는 빠른 혁신과 규모 확장을 위해 파이썬 생태계에 크게 의존합니다[cite: 9]. 파이썬의 동적 런타임 환경은 복잡한 선언 없이도 코드를 빠르게 작성하고 테스트할 수 있게 하여, 아이디어를 신속하게 프로토타입으로 만들고 실험하는 데 최적화되어 있습니다. 이는 빠르게 변화하는 ML 분야에서 강력한 장점입니다.

  • 보안 (The Cost) 🛡️: 이 편의성의 대가는 보안 취약성입니다. [cite_start]파이썬에서는 모든 패키지가 동일한 메모리 공간을 공유하며, 다른 패키지의 변수나 함수에 접근하여 수정하는 것이 가능합니다[cite: 18, 173]. [cite_start]이는 마치 모든 집에 같은 마스터키가 존재하는 것과 같아서, 하나의 의존성 패키지만 손상되어도 전체 애플리케이션의 동작을 은밀하게 조작할 수 있는 심각한 위험을 내포합니다[cite: 20, 173]. 즉, 개발의 유연성과 편의성을 위해 패키지 간의 격리라는 보안의 기본 원칙이 희생된 것입니다.

## 현실적인 장기적 해결책 (Realistic Long-Term Solutions)

이 위험을 완화하기 위해 논문에서 제시 및 암시하는 가장 현실적인 장기적 해결책은 다음과 같습니다.

  1. [cite_start]소스 코드 분석 강화 및 전문가 개입: 단기적으로는 모든 직접 및 전이 의존성 패키지의 소스 코드를 분석하여, 다른 패키지의 변수를 덮어쓰려는 시도와 같은 위험한 코드를 탐지하는 방어 전략을 도입해야 합니다[cite: 256]. [cite_start]이 과정은 미묘한 ML 취약점을 이해할 수 있는 보안 전문가와 ML 전문가의 협업이 반드시 필요합니다[cite: 257, 258].

  2. [cite_start]보안 중심 언어로의 점진적 이전: 가장 근본적인 해결책은 보안이 중요한 ML 애플리케이션이나 프레임워크의 핵심 부분을 컴파일 언어(Compiled Language)로 점진적으로 이전하는 것입니다[cite: 272]. Rust나 C++와 같이 메모리 안전성(memory safety)과 강력한 타입 시스템을 제공하는 언어는 파이썬의 동적 런타임이 가진 구조적 문제를 원천적으로 방지할 수 있습니다. 전체를 바꾸는 것은 비현실적이므로, 데이터 처리 파이프라인이나 모델 추론 엔진과 같이 보안에 민감한 핵심 모듈부터 전환하는 것이 현실적인 접근법입니다.