방어적 출판: GPU_WORKLOAD_MISMATCH

AI 컨테이너 워크로드(Workloads)를 위한 새로운 보안 탐지 카테고리

저자: Carnell Smith, Champtron Systems LLC

날짜: 2026년 6월 9일

소속: NVIDIA Inception 멤버

방어적 출판 고지 (Defensive publication notice): 본 문서는 여기에 기술된 방법들에 대한 선행 기술(prior art)을 확립하고, 제3자가 이러한 기술에 대해 특허 보호를 받는 것을 방지하기 위해 게시되었습니다.

초록 (Abstract)

본 공개 문서는 컨테이너화된 AI 및 GPU 워크로드(workload) 환경에서 이전에 명명되지 않은 새로운 클래스의 보안 설정 오류(security misconfiguration)를 탐지하는 방법을 설명합니다.

이 방법은 호스트 시스템의 컨테이너 런타임(container runtime) 수준에서 GPU 워크로드 의도(GPU workload intent)가 구성되어 있으나, 호스트에 물리적인 NVIDIA GPU, 드라이버 스택(driver stack) 또는 CUDA 런타임(CUDA runtime)이 존재하지 않는 상태를 식별합니다.

이 상태는 다음과 같이 지정됩니다:

GPU_WORKLOAD_MISMATCH

이 상태는 운영 보안 리스크, 컴플라이언스 격차(compliance gaps), 그리고 기존 컨테이너 보안 도구들이 탐지하지 못할 수 있는 검증 불가능한 실행 주장(unverifiable execution claims)을 생성합니다.

본 출판물은 다음 내용을 설명합니다:

• 탐지 방법
• 교차 검증 로직 (cross-check logic)
• 심각도 분류 (severity classification)
• 이 카테고리가 속한 더 넓은 탐지 분류 체계 (finding taxonomy)
• 관련 AI 모델, 양자 내성 암호 (post-quantum cryptography) 및 조치 점수 산정 (remediation scoring) 방법

1. 배경 및 문제 정의 (Background and Problem Statement)

기업 및 정부 환경에서 GPU 가속 AI 워크로드(workloads)가 확산됨에 따라, 기존 보안 도구들이 탐지하도록 설계되지 않은 새로운 클래스의 컨테이너 보안 설정 오류(security misconfiguration)가 발생하고 있습니다.

주요 상용 컨테이너 보안 플랫폼들은 일반적으로 다음과 같은 작업을 수행합니다:

• CVE 스캐닝 (CVE scanning)
• Dockerfile 분석 (Dockerfile analysis)
• Kubernetes 매니페스트 감사 (Kubernetes manifest auditing)
• 런타임 동작 모니터링 (Runtime behavior monitoring)
• 비밀 정보 탐지 (Secrets detection)
• 이미지 취약점 평가 (Image vulnerability assessment)

하지만 이러한 도구 중 상당수는 GPU 및 CUDA 소프트웨어 스택에 대한 완전한 인지 없이 작동합니다.

Docker 호스트 또는 컨테이너 환경이 GPU 워크로드(Workload) 의도를 선언하고 있지만, 기반이 되는 호스트가 물리적 및 기능적으로 GPU 실행이 불가능할 때 특정 취약점 클래스(Vulnerability class)가 발생합니다.

1.1 GPU 워크로드 의도 조건 (GPU Workload Intent Conditions)

호스트 또는 컨테이너는 다음 조건 중 하나 이상을 통해 GPU 워크로드 의도를 나타낼 수 있습니다.

호스트 수준의 GPU 의도 (Host-level GPU intent)

Docker 호스트의 데몬(Daemon) 설정에 NVIDIA Container Runtime이 다음 중 하나를 통해 등록되어 있는 경우입니다:

/etc/docker/daemon.json

또는 다음 명령어를 통해 보고되는 경우:

docker info

이는 GPU 워크로드를 지원하려는 의도를 나타냅니다.

컨테이너 수준의 GPU 의도 (Container-level GPU intent)

실행 중인 하나 이상의 컨테이너가 다음 지표 중 하나를 통해 GPU 워크로드 의도를 선언하는 경우입니다:

• CUDA_VISIBLE_DEVICES 환경 변수 (Environment variable)
• NVIDIA_VISIBLE_DEVICES 환경 변수 (Environment variable)
• NVIDIA 런타임(Runtime) 할당:

HostConfig.Runtime = "nvidia"

• 직접적인 NVIDIA 장치 마운트 (Direct NVIDIA device mounts):

/dev/nvidia*

내부의:

HostConfig.Devices

1.2 GPU 기능 부재 조건 (Missing GPU Capability Conditions)

GPU 워크로드 의도가 존재하면서 다음 사항이 모두 참일 때 위험 조건이 성립합니다:

1. 다음 명령어를 통해 호스트에서 물리적인 NVIDIA GPU를 감지할 수 없음:

lspci

또는:

nvidia-smi

2. NVIDIA 드라이버(Driver)가 설치되어 있지 않거나 작동하지 않음.

3. 다음을 포함하여 CUDA 런타임(Runtime)이 존재하지 않음:

• nvcc
• libcudart.so
• 유효한 CUDA_PATH 환경 변수

1.3 보안 위험 (Security Risks)

이러한 조건이 존재할 때, 호스트는 GPU 실행이 불가능함에도 불구하고 컨테이너 워크로드 및 오케스트레이션(Orchestration) 시스템에 GPU 사용이 가능한 구성 표면(Configuration surface)을 제시하게 됩니다.

이는 다음과 같은 여러 보안 및 운영 위험을 초래합니다.

검증 불가능한 실행 주장 (Unverifiable execution claims)

GPU 가속 실행을 주장하는 워크로드를 검증할 수 없습니다. 감사 로그(Audit logs), 컴플라이언스 보고서(Compliance reports), 및 증명 기록(Attestation records)에는 실행 환경에 대한 허위 또는 지원되지 않는 주장이 포함될 수 있습니다.

스케줄링 및 라우팅 신뢰 위반 (Scheduling and routing trust violations)

연합(Federated) 또는 멀티 노드(Multi-node) 환경에서, 잘못 설정된 호스트는 실행할 수 없는 GPU 워크로드(Workloads)를 수락할 수 있습니다. 이는 보안 또는 컴플라이언스(Compliance) 팀에 드러나지 않는 침묵의 실패(Silent failures)나 예상치 못한 CPU 폴백(CPU fallback) 동작을 유발할 수 있습니다.

컴플라이언스 격차 (Compliance gaps)

DoD(미 국방부), 헬스케어 AI, 금융 서비스와 같이 규제되는 환경에서는 AI 모델 추론(Inference)을 위해 증명 가능한 GPU 실행(Attestable GPU execution)을 요구할 수 있습니다. 이러한 조건이 탐지되지 않을 경우, 조직은 자신의 컴플라이언스 상태(Compliance posture)를 검증할 수 없습니다.

구성 드리프트 지표 (Configuration drift indicators)

이 조건은 다음과 같은 사항을 나타낼 수 있습니다:

• Docker 데몬(Daemon) 설정의 무단 수정
• GPU 드라이버의 부분적 삭제
• 구성 정리(Cleanup) 없는 하드웨어 제거
• 정렬되지 않은 오케스트레이션(Orchestration) 정책
• 선언된 런타임 기능(Runtime capability)과 실제 호스트 기능 간의 드리프트(Drift)

이 각각은 보안과 관련된 이벤트입니다.

2. 탐지 방법 (Detection Method)

탐지 방법은 호스트 시스템 및 실행 중인 컨테이너에 대해 독립적인 점검을 수행한 다음, 보수적인 교차 검증(Cross-check) 로직을 통해 결합된 결과를 평가합니다.

2.1 호스트 수준 점검 (Host-Level Checks)

최소한의 호스트 수준 점검 항목은 다음과 같습니다.

check_gpu_present()

다음과 같은 하드웨어 열거(Enumeration) 점검을 실행합니다:

lspci

및/또는:

nvidia-smi -L

이 점검은 물리적인 NVIDIA GPU 장치가 존재하는지 식별합니다.

예상 반환 값에는 다음이 포함됩니다:

• 불리언(Boolean) 통과/실패 결과
• 가능한 경우, 탐지된 장치 이름
• 가능한 경우, 탐지된 장치 수

check_nvidia_driver()

다음 명령을 실행합니다:

nvidia-smi --query-gpu=name,driver_version

이는 NVIDIA 드라이버가 설치되어 있고 기능하는지 확인합니다.

예상 반환 값에는 다음이 포함됩니다:

• 통과/실패 결과
• 가능한 경우, 드라이버 버전 문자열

check_cuda_runtime()

다음 사항을 검증하여 CUDA 런타임(Runtime) 가용성을 확인합니다:

• nvcc 바이너리 가용성
• 표준 라이브러리 경로 내 libcudart.so 존재 여부
• CUDA_PATH 환경 변수의 유효성

예상 반환 값:

• Pass/fail 결과

2.2 컨테이너 레벨 점검 (Container-Level Checks)

다음 점검 항목들은 Docker 런타임(runtime) 및 컨테이너 레벨에서 GPU 워크로드(workload) 의도를 탐지합니다.

check_docker_gpu_runtime()

다음 명령어를 사용하여 Docker 런타임 설정을 조회합니다:

docker info --format '{{json .Runtimes}}'

그리고 다음 파일을 검사합니다:

/etc/docker/daemon.json

이 점검은 nvidia 런타임(runtime) 키의 존재 여부를 확인합니다.

예상 반환 값:

• Pass/fail 결과

check_gpu_enabled_containers()

다음 명령어를 사용하여 실행 중인 컨테이너들을 순회합니다:

docker ps -q

그 후, 각 컨테이너를 다음 명령어로 검사합니다:

docker inspect

이 점검은 다음과 같은 GPU 워크로드(workload) 지표를 탐지합니다:

• HostConfig.Runtime == "nvidia"
• /dev/nvidia*와 일치하는 경로를 포함하는 HostConfig.Devices
• 다음을 포함하는 Config.Env:
  • CUDA_VISIBLE_DEVICES
  • NVIDIA_VISIBLE_DEVICES
  • 기타 CUDA 관련 환경 변수

예상 반환 값:

• GPU 워크로드 지표를 가진 컨테이너 목록

2.3 교차 점검 로직 (Cross-Check Logic)

GPU_WORKLOAD_MISMATCH 탐지 결과는 개별 점검들의 결합된 결과를 평가하는 교차 점검(cross-check) 함수를 통해 도출됩니다.

IF (check_gpu_present() == FAIL)
   AND (check_nvidia_driver() == FAIL)
   AND (check_cuda_runtime() == FAIL)
...

이 로직은 의도적으로 보수적(conservative)으로 설계되었습니다.

하드웨어, 드라이버(driver), 런타임(runtime)에 대한 세 가지 점검이 모두 실패해야 하며, 이는 GPU 기능의 실제 부재를 확인합니다.

또한, 최소 하나 이상의 워크로드 의도 지표가 존재해야 하며, 이는 GPU 기능을 사용하려는 실제 의도를 확인합니다.

이러한 결합(conjunction)을 통해, 단순히 GPU 설정이 없는 비-GPU 호스트(non-GPU hosts) 시스템에서 발생하는 오탐(false positives)을 방지합니다.

2.4 탐지 결과 구조 (Finding Structure)

교차 점검 조건이 충족되면, 구조화된 탐지 결과가 생성됩니다.

속성 (Attribute)	값 (Value)
카테고리 (Category)	GPU_WORKLOAD_MISMATCH
...

2.5 상태 라벨 차별화 (Status Label Differentiation)

두 번째 방법은 교차 점검 결과에 따라 컨테이너 점검 상태 라벨을 차별화하는 것과 관련이 있습니다.

GPU_WORKLOAD_MISMATCH 조건이 존재하는 경우, 오해를 불러일으킬 수 있는 합격/불합격 (pass/fail) 출력을 방지하기 위해 점검 상태가 조정됩니다.

Docker GPU 런타임 상태

Docker GPU 런타임 점검은 런타임이 등록되어 있기 때문에 일반적으로 다음과 같이 표시됩니다:

[PASS]

하지만 물리적인 GPU 기능이 존재하지 않는 경우, 다음과 같이 라벨이 변경됩니다:

[WARN]

이는 구성 (configuration)은 존재하지만 물리적 하드웨어와 대조하여 검증할 수 없음을 나타냅니다.

컨테이너 GPU 워크로드 지표 상태

컨테이너 GPU 워크로드 지표 (workload indicator) 점검은 GPU 워크로드 지표가 발견되었기 때문에 일반적으로 다음과 같이 표시됩니다:

[PASS]

하지만 물리적 GPU가 존재하지 않는 경우, 다음과 유사한 상세 텍스트와 함께 다음과 같이 라벨이 변경됩니다:

[WARN]

N개의 컨테이너에서 GPU 워크로드 지표가 발견되었으나, 이 호스트에서 사용 가능한 물리적 NVIDIA GPU가 없습니다.

이러한 차별화는 운영자에게 보안 상태에 대한 더 정확한 표현을 제공합니다.

단순한 합격/불합격 (pass/fail) 이진 분류로는 부분적인 GPU 구성의 위험을 포착할 수 없습니다.

3. 탐지 카테고리 분류 체계 (Finding Category Taxonomy)

본 공개 사항은 또한 컨테이너화된 환경에서의 GPU, AI 및 양자 내성 암호 (PQC) 보안 탐지를 위한 13개 카테고리의 탐지 분류 체계를 설명합니다.

#	카테고리	설명
1	GPU_SECURITY	일반적인 GPU 하드웨어 및 구성 보안
...

모든 감사 모듈 (audit module)에 의해 생성된 각 탐지 결과에는 이 분류 체계 중 정확히 하나의 카테고리가 할당됩니다.

이를 통해 다음과 같은 작업이 가능합니다:

• 모듈 간 상관관계 분석 (Cross-module correlation)
• 대시보드에서의 카테고리별 집계 (Aggregation)
• 컴플라이언스 프레임워크를 위한 구조화된 보고 (Structured reporting)
• GPU, AI, PQC 및 컨테이너 보안 이슈의 더 나은 우선순위 지정

4. AI 모델 보안 스캐닝 방법

본 공개 사항은 추가적으로 실행 중인 컨테이너 파일 시스템을 스캔하여 내장된 AI 모델 파일을 찾고, 해당 모델의 보안 태세 (security posture)를 평가하는 방법을 설명합니다.

4.1 모델 형식 탐지

이 방법은 다음과 같은 명령어를 사용하여 컨테이너 파일 시스템을 스캔합니다:

docker exec <container_id> find / -type f

AI 모델 형식 (Model formats)과 관련된 확장자를 가진 파일들을 검색합니다.

확장자 (Extension)	모델 형식 (Model Format)
.onnx	ONNX
...

4.2 안전하지 않은 형식 탐지 (Unsafe Format Detection)

Pickle 형식의 모델 파일은 다음 확장자를 통해 식별됩니다:

• .pkl
• .pickle

이러한 형식은 역직렬화 (Deserialization) 과정에서 임의 코드 실행 (Arbitrary code execution)을 허용할 수 있기 때문에 보안에 민감합니다.

탐지될 경우, 다음과 같은 결과가 할당됩니다:

속성 (Attribute)	값 (Value)
카테고리 (Category)	AI_GOVERNANCE
...

4.3 무결성 검증 (Integrity Verification)

이 방법은 모델 파일과 함께 존재하는 SHA256 해시 사이드카 (Sidecar) 파일을 확인합니다.

예상되는 사이드카 패턴:

<model_file>.sha256

다음과 같은 최소 크기 임계값 이상의 모델:

50 MB

해당하는 해시 기록이 존재하지 않을 경우 플래그 (Flag)가 지정됩니다.

이는 모델 무결성 검증 (Model integrity verification)이 누락되었음을 나타냅니다.

4.4 CUDA 연산 불일치 (CUDA Compute Mismatch)

컨테이너 이미지 이름이나 환경 변수가 CUDA 또는 NVIDIA 요구 사항을 나타내지만, 호스트 수준의 GPU 확인 결과 물리적 GPU가 존재하지 않는 경우 CUDA_HARDENING 결과가 발생합니다.

이 결과는 컨테이너의 연산 요구 사항을 호스트가 충족할 수 없음을 나타냅니다.

4.5 LLM 엔드포인트 노출 (LLM Endpoint Exposure)

이 방법은 알려진 LLM 서빙 프레임워크 (Serving frameworks)와 관련된 이미지 이름 패턴을 매칭하여 대규모 언어 모델 (LLM) 추론을 제공하는 컨테이너를 탐지합니다.

예시는 다음과 같습니다:

• ollama
• vllm
• triton
• tgi

이 방법은 다음 주소에서 추론 포트 (Inference ports)를 노출하면서 환경 변수에 인증 관련 설정이 누락된 컨테이너를 확인합니다:

0.0.0.0

이는 적절한 접근 제어 (Access control) 없이 노출될 수 있는 LLM 추론 엔드포인트를 식별합니다.

5. 양자 내성 암호 (Post-Quantum Cryptography) 컨테이너 스캐닝 방법

본 공개 사항은 실행 중인 컨테이너 환경에서 양자 취약 암호 알고리즘 (Quantum-vulnerable cryptographic algorithm) 설정을 탐지하고, 탐지 결과를 NSA CNSA 2.0 준수 통제 항목에 매핑하는 방법을 설명합니다.

5.1 탐지 방법

해당 방법은 컨테이너 환경 변수(environment variables)와 이미지 레이블(image labels)을 스캔하여 양자 취약 알고리즘(quantum-vulnerable algorithms)과 관련된 문자열 패턴을 탐지합니다.

패턴에는 다음 항목에 대한 참조가 포함됩니다:

• RSA 키 사양 (RSA key specifications)
• ECDSA 참조 (ECDSA references)
• ECDH 참조 (ECDH references)
• Diffie-Hellman 파라미터 (Diffie-Hellman parameters)
• SHA-1
• MD5
• AES-128 암호 사양 (AES-128 cipher specifications)
• TLS 1.2 설정 문자열 (TLS 1.2 configuration strings)

5.2 준수 매핑 (Compliance Mapping)

탐지된 각 패턴은 CNSA 2.0 통제 식별자(control identifier)에 매핑됩니다.

통제 영역 (Control Area)	통제 ID (Control ID)
키 캡슐화 (Key encapsulation)	KE-1
...

5.3 PQC 알고리즘 탐지 (PQC Algorithm Detection)

해당 방법은 다음을 포함하여 CNSA 2.0에 부합하거나 양자 내성 암호 (PQC, post-quantum cryptography) 알고리즘에 대한 참조를 스캔합니다: