공급망 보안 (Supply Chain Risk)

오늘날 AI 시스템을 처음부터 끝까지 자체적으로 만드는 조직은 거의 없습니다. 대부분은 사전학습 모델(pretrained model), 오픈소스 가중치, 공개 데이터셋, ML 프레임워크와 라이브러리, 때로는 제3자 fine-tuning 서비스나 플러그인을 조합해 시스템을 구성합니다. 이 모든 외부 구성요소가 곧 공급망(supply chain)이며, 전통적인 소프트웨어 공급망 공격(악성 패키지, 의존성 하이재킹)의 개념이 AI 영역에서는 모델, 데이터셋, 토크나이저, 학습 코드까지 확장됩니다. OWASP LLM Top 10의 LLM05: Supply Chain Vulnerabilities가 이 영역을 다룹니다.

    flowchart LR
    subgraph EXT["외부 공급망 구성요소"]
        E1["사전학습 모델/\n오픈소스 가중치"]
        E2["공개 데이터셋"]
        E3["ML 프레임워크/\n라이브러리 의존성"]
        E4["제3자 파인튜닝\n서비스 / 플러그인"]
    end

    subgraph RISK["진입 가능 위험"]
        R1["백도어 모델\n/ 출처 불명 체인"]
        R2["사전 오염된 데이터\n(pre-poisoning)"]
        R3["pickle 역직렬화\n→ RCE / 악성 패키지"]
        R4["권한 남용\n/ 데이터 재사용"]
    end

    subgraph MIT["완화 / 가시성"]
        M1["모델 카드 +\n레드팀 평가"]
        M2["데이터시트 +\n해시 기록"]
        M3["safetensors +\nSCA 의존성 스캔"]
        M4["권한 최소화 +\nAI SBOM"]
    end

    E1 --> R1 --> M1
    E2 --> R2 --> M2
    E3 --> R3 --> M3
    E4 --> R4 --> M4

    M1 -.등록 전 검증.- E1
    M2 -.버전 고정.- E2

    classDef ext fill:#e7f1ff,stroke:#3b82f6,color:#1e3a8a;
    classDef risk fill:#fff3cd,stroke:#d39e00,color:#664d03;
    classDef mit fill:#e7f1ff,stroke:#3b82f6,color:#1e3a8a;
    class E1,E2,E3,E4 ext;
    class R1,R2,R3,R4 risk;
    class M1,M2,M3,M4 mit;
  

사전학습 모델 / 오픈소스 가중치 사용 시 위험

Hugging Face Hub, GitHub, 클라우드 마켓플레이스 등에서 받아오는 사전학습 모델은 편리하지만, “누가, 어떤 데이터로, 어떤 목적으로 만들었는지"에 대한 신뢰를 그대로 가져오는 행위이기도 합니다.

• 백도어가 삽입된 모델: 특정 트리거 입력에서만 비정상적으로 동작하도록 학습된 모델이 정상 모델과 구분 없이 배포될 수 있습니다. 이는 공격 기법 → 데이터 포이즈닝에서 다루는 백도어 공격이 “학습 데이터"가 아니라 “최종 가중치” 형태로 공급망에 들어오는 경우입니다.
• 출처 불명확한 파인튜닝 체인: 모델 A를 기반으로 누군가 파인튜닝한 모델 B를, 다시 누군가가 파인튜닝한 모델 C… 이런 체인이 길어질수록 원본 모델의 라이선스, 학습 데이터, 안전성 검증 이력을 추적하기 어려워집니다.
• 벤치마크 결과의 신뢰성: 공개된 벤치마크 점수가 실제 가중치 파일과 일치하는지 검증할 방법이 없는 경우가 많습니다. 점수가 좋다고 해서 안전성·정확성이 보장되지 않습니다.
• 라이선스 리스크: 모델 가중치나 학습에 사용된 데이터셋의 라이선스 조건(상업적 사용 제한, 재배포 제한, 출처 표기 의무 등)을 위반하면 법적 리스크로 이어집니다. 이는 보안 문제는 아니지만 공급망 거버넌스의 일부로 함께 관리되어야 합니다.

완화 방안:

• 신뢰할 수 있는 출처(공식 조직 계정, 검증된 organization)에서만 모델을 가져옵니다.
• 가져온 모델은 자체 평가 데이터셋과 레드팀 테스트를 거쳐 MLOps 파이프라인 보안에서 다룬 평가 단계를 통과한 뒤에만 서빙 환경에 등록합니다.
• 모델의 변경 이력(commit history, 버전 태그)을 확인해 비정상적인 갱신 패턴이 없는지 점검합니다.

데이터셋 출처 검증

학습/파인튜닝/평가에 사용되는 데이터셋도 동일한 공급망 문제를 가집니다.

• 출처 메타데이터 부재: “이 데이터셋은 어디서, 어떻게, 누구에 의해 수집되었는가"에 대한 정보가 없는 데이터셋은 의도적인 오염 여부를 검증할 방법이 없습니다.
• 크롤링 기반 데이터셋의 오염 가능성: 웹 크롤링으로 구성된 대규모 데이터셋은 공격자가 사전에 웹에 악성 콘텐츠를 배치해 향후 학습에 포함되도록 유도하는 “데이터셋 사전 오염(pre-poisoning)” 공격에 취약합니다.
• 데이터셋 버전 변경: 동일한 이름의 공개 데이터셋이 시간이 지나며 내용이 갱신되는 경우, 과거 평가 결과가 현재 버전에는 더 이상 유효하지 않을 수 있습니다.

완화 방안:

• 가능한 경우 데이터셋의 출처, 수집 방법, 라이선스, 알려진 이슈(known issues)를 문서화한 데이터시트(Datasheet)를 함께 확보합니다.
• 데이터셋을 받아오는 즉시 해시를 기록하고, 이후 동일한 이름으로 다시 받았을 때 해시가 달라지면 변경 사항을 검토합니다.
• 신뢰도가 낮은 데이터셋은 학습에 사용하기 전, 통계적 분포 분석과 샘플 수동 검토를 거칩니다.

의존성(라이브러리/프레임워크) 무결성 — pickle 역직렬화 위험

ML 생태계는 Python 기반 라이브러리(PyTorch, TensorFlow, scikit-learn, Hugging Face transformers 등)에 크게 의존하며, 이들 라이브러리의 의존성 트리는 매우 깊고 넓습니다.

• 악성 패키지(typosquatting/dependency confusion): 인기 있는 ML 라이브러리 이름과 유사한 악성 패키지를 PyPI 등에 업로드해, 오타나 잘못된 패키지 인덱스 설정으로 설치를 유도하는 공격입니다.
• pickle 역직렬화 위험: PyTorch의 .pt/.pth 파일을 포함한 많은 모델 직렬화 형식은 내부적으로 Python의 pickle 모듈을 사용합니다. pickle.load()는 임의의 Python 객체를 역직렬화하는 과정에서 임의 코드를 실행할 수 있는 구조적 위험을 가지고 있습니다. 즉, 신뢰할 수 없는 출처에서 받은 모델 파일을 단순히 “로드"하는 행위만으로도 원격 코드 실행(RCE)이 발생할 수 있습니다.
  • 완화: 가능하면 safetensors처럼 임의 코드 실행이 불가능한 직렬화 형식을 사용합니다. pickle 기반 형식을 불가피하게 사용해야 한다면, 신뢰된 출처의 모델만 로드하고, 격리된 샌드박스 환경에서 1차 로드 후 검증합니다.
• 빌드 도구체인의 무결성: CUDA, cuDNN, 컴파일된 wheel 파일 등 바이너리 형태로 배포되는 구성요소는 소스코드 검토가 어려워, 공급망 공격의 탐지가 더 어렵습니다.

완화 방안:

• requirements.txt/pyproject.toml에 정확한 버전과 해시(--hash 옵션)를 고정합니다.
• 의존성 취약점 스캐너(예: pip-audit, Dependabot, Snyk 등 SCA 도구)를 CI 파이프라인에 통합합니다.
• 내부 패키지 미러/프록시(Artifactory 등)를 통해 외부 패키지를 한 번 검증 후 배포하는 구조를 운영합니다.

Third-party Fine-tuning / Plugin 위험

LLM 애플리케이션은 종종 제3자가 제공하는 파인튜닝 서비스나 플러그인/확장 기능을 통해 기능을 확장합니다.

• 제3자 파인튜닝 서비스: 외부 서비스에 학습 데이터를 업로드해 파인튜닝을 맡기는 경우, (1) 업로드한 데이터가 서비스 제공자 측에 어떻게 보관/재사용되는지, (2) 결과로 받은 모델에 백도어나 의도하지 않은 동작이 포함되지 않았는지를 검증할 책임이 사용자 측에 남습니다.
• LLM 플러그인/확장: 외부 플러그인이 모델의 컨텍스트에 임의의 콘텐츠를 주입하거나, 모델의 출력을 가로채 외부로 전송할 수 있는 권한을 갖는 경우, 플러그인 자체가 공급망 공격의 매개체가 됩니다.
• 권한 범위의 명확화: 플러그인이나 외부 서비스에 부여하는 권한(읽기 전용 vs 쓰기, 접근 가능한 데이터 범위)을 최소화하고, 정기적으로 검토합니다.

SBOM for AI (모델 카드, 데이터시트)

전통적인 소프트웨어 공급망 보안에서 SBOM(Software Bill of Materials)은 “이 소프트웨어에 어떤 구성요소가 포함되어 있는가"를 명시한 목록입니다. AI 시스템에서는 이 개념이 다음과 같이 확장됩니다.

• 모델 카드(Model Card): 모델의 아키텍처, 학습 데이터 개요, 의도된 사용 사례, 알려진 한계와 편향, 평가 결과를 문서화합니다. “이 모델은 무엇으로 만들어졌고, 무엇을 위해 만들어졌는가"에 대한 답입니다.
• 데이터시트(Datasheet for Datasets): 데이터셋의 수집 방법, 구성, 전처리 과정, 라이선스, 알려진 이슈를 문서화합니다.
• AI SBOM의 구성 요소: 모델 가중치 버전, 학습/파인튜닝에 사용된 데이터셋 버전과 해시, 사용된 프레임워크/라이브러리 버전, 토크나이저 버전, 안전성 평가 결과 등을 포괄적으로 기록한 목록입니다.

이러한 문서는 단순한 형식적 절차가 아니라, 사고가 발생했을 때 영향 범위를 빠르게 파악하기 위한 실질적인 자료입니다. 예를 들어 특정 오픈소스 라이브러리에서 취약점이 발견되었을 때, AI SBOM이 있다면 “이 취약점이 영향을 미치는 모델/파이프라인이 무엇인지"를 즉시 조회할 수 있습니다.

정리

AI 공급망은 모델 가중치, 데이터셋, 프레임워크/라이브러리, 외부 서비스라는 네 갈래로 구성되며, 각각 고유한 위험(백도어 모델, 오염된 데이터셋, pickle RCE, 신뢰 경계가 불명확한 제3자 서비스)을 가집니다. MLOps 파이프라인 보안과 모델 서빙 보안에서 다룬 내부 통제가 “우리가 만드는 것"을 보호한다면, 공급망 보안은 “우리가 가져오는 것“을 검증하는 영역입니다. 두 영역이 합쳐져야 SAIF가 말하는 AI 파이프라인 전체의 보안이 완성됩니다.