AI 모델 파일은 실행 가능한 공급망 위협이 될 수 있다

Google News 헤드라인은 보안 리더들에게 직설적인 경고를 던졌다. AI 모델은 일반적인 소프트웨어 검토를 통과했더라도 보안 경계를 넘을 수 있다. 문제는 범주를 잘못 이해하는 데서 시작된다. 기업은 모델 파일을 흔히 비활성 데이터로 관리하지만, 일부 형식은 로드될 때 코드를 실행할 수 있다.

Google News 결과는 CISO가 알아차리지 못할 수 있는 거대한 AI 보안 허점을 다룬 Security Boulevard 헤드라인을 가리킨다. 이 헤드라인은 유용한 출발점이지만, 광범위한 주장은 신중하게 해석해야 한다. 방어 가능한 쟁점은 새롭게 공개된 보편적 취약점 하나가 아니다.

더 큰 문제는 AI 도입을 위한 보안 모델이 불완전하다는 점이다. 모델 체크포인트, 어댑터, 지원 코드, 프롬프트, 에이전트 도구, 자격 증명은 새로운 공급망을 이룬다. 소스 패키지와 컨테이너 이미지를 중심으로 설계된 통제는 이러한 구성 요소를 자동으로 포괄하지 않는다.

이 격차는 CISO를 어려운 현실과 마주하게 한다. AI 팀은 빠른 실험과 커뮤니티 모델에 대한 손쉬운 접근을 중시한다. 보안 팀은 출처 검증, 제한된 실행, 인벤토리, 그리고 다운로드한 아티팩트가 변경되지 않았다는 증거를 필요로 한다.

따라서 핵심 대립은 AI 혁신과 보안 사이의 충돌이 아니다. 모델이 단지 데이터라는 약속과, 실제 배포 시 코드·의존성·동작·권한 있는 접근을 도입할 수 있다는 현실의 충돌이다.

Google News 경고가 실제로 바꾸는 것

중요한 변화는 이제 모델 반입이 소프트웨어 반입과 같은 수준의 검증을 받아야 한다는 점이다.

Security Boulevard 헤드라인은 단일 침해 사고, 피해자, 또는 새로 할당된 취약점을 입증하지 않는다. 대신 기업이 다운로드한 모델을 프로덕션 환경에서 실행할수록 심각해지는 노출 유형을 부각한다.

이 구분은 중요하다. 선정적으로 해석하면 모든 AI 모델이 악성이거나 모든 CISO가 동일한 결함을 놓쳤다는 뜻이 된다. 가용한 증거로는 어느 결론도 도출할 수 없다.

더 좁고 근거가 탄탄한 결론도 여전히 중대하다. 조직은 모델 아티팩트가 환경에 들어와 로드되고 동작하는 방식을 충분히 검토하지 않은 채 AI 프로젝트를 승인할 수 있다.

모델 체크포인트는 머신러닝 시스템을 복원하는 데 필요한 파라미터와 관련 정보를 저장한다. 일부 일반적인 체크포인트 형식은 Python의 pickle 직렬화 메커니즘에 의존하며, 로드 과정에서 저장된 객체를 재구성한다.

이 재구성 과정은 함수를 호출할 수 있다. 따라서 악성 아티팩트는 역직렬화 순간에 수동적인 문서라기보다 검토되지 않은 소프트웨어처럼 동작할 수 있다.

역직렬화란 저장된 바이트를 다시 프로그램 객체로 바꾸는 작업이다. 공격자가 통제하는 명령을 통해 객체를 재생성할 때 위험이 발생한다.

이 위험은 Google News 헤드라인 이후에 만들어진 이론적 지침이 아니다. PyTorch는 로딩 프로세스가 unpickler를 사용하므로 신뢰할 수 없는 출처의 데이터를 절대 로드하지 말라고 명시적으로 경고한다.

PyTorch는 버전 2.6에서 torch.load의 기본 동작을 변경했다. 이제 호출자가 사용자 지정 pickle 모듈을 제공하지 않으면 프레임워크는 weights_only=True를 사용한다.

제한된 로더는 텐서, 기본 데이터 형식, 사전, 그리고 명시적으로 허용된 객체를 받아들인다. 또한 Python 표준 unpickler에서 가능한 동적 import도 차단한다.

이 변경은 중요한 보안 개선이다. 동시에 모델 로딩이 조직의 위협 모델 안에 포함되어야 한다는 증거이기도 하다.

PyTorch의 자체 직렬화 가이드는 제한 모드가 원격 코드 실행 노출을 줄인다고 설명한다. 다만 모든 서비스 거부나 메모리 손상 시나리오까지 방어하지는 않는다.

호환성은 또 다른 복잡성을 만든다. 오래된 체크포인트와 사용자 지정 모델 클래스는 더 안전한 설정에서 실패할 수 있고, 이에 따라 개발자는 weights_only=False로 되돌리게 될 수 있다.

그 결과 프롬프트는 두 가지 경로를 제시한다. 팀은 아티팩트를 재설계하거나 변환할 수 있고, 기존 워크플로가 이를 요구한다는 이유로 더 광범위한 실행을 허용할 수도 있다.

배포 압박 속에서 두 번째 경로는 무해한 호환성 수정처럼 보일 수 있다. 그러나 보안 관점에서는 파일이 로더로 하여금 생성하거나 실행하게 할 수 있는 범위를 넓힌다.

바로 이 지점에서 헤드라인이 제기한 CISO의 과제가 구체화된다. 위험한 결정은 정식 예외 처리 절차에 이르지 않은 채 노트북, 배포 스크립트, 또는 모델 서빙 구성에서 발생할 수 있다.

기존 애플리케이션 검토는 일반적으로 어떤 패키지가 빌드에 들어왔는지, 알려진 취약점이 이들에 영향을 미치는지를 묻는다. AI 검토는 각 모델 아티팩트를 누가 만들었고 어떻게 로드되는지도 물어야 한다.

이 변화는 기술적인 만큼 조직적인 변화이기도 하다. 모델 출처 검증은 더 이상 데이터 과학자만이 비공식적으로 담당하는 관심사에 머물 수 없다.

AI 모델 보안이 기존 담당 조직 사이에서 누락되는 이유

모델 탐색부터 프로덕션 접근까지의 전체 경로를 자연스럽게 소유하는 단일 팀이 없기 때문에 노출은 커진다.

머신러닝 엔지니어는 공개 리포지토리에서 모델을 선택할 수 있다. 플랫폼 팀은 이를 패키징하고, 클라우드 팀은 컴퓨팅과 시크릿을 제공할 수 있다.

그다음 애플리케이션 팀은 모델을 고객 데이터에 연결한다. 보안 팀은 앞선 아티팩트 로딩 결정을 보지 못한 채 최종 API를 검토할 수 있다.

모든 참여자는 익숙한 작업을 올바르게 수행하면서도 결합된 시스템을 노출된 상태로 남겨둘 수 있다. 약점은 인계 과정에 존재한다.

이는 이 문제가 고위 보안 리더에게 보이지 않은 채 남을 수 있는 이유를 설명한다. 모델 다운로드는 기존 애플리케이션 구성 요소와 동일한 조달, 의존성, 변경 관리 통제를 촉발하지 않을 수 있다.

다운로드한 파일은 간접 경로로도 유입될 수 있다. 라이브러리가 자동으로 파일을 가져오거나, 노트북이 런타임에 검색하거나, 컨테이너 빌드가 이를 캐시할 수 있다.

각 경로는 인벤토리를 복잡하게 만든다. CISO는 조직이 개발, 테스트, 프로덕션 전반에서 식별할 수 없는 아티팩트를 관리할 수 없다.

오픈 모델 리포지토리는 실험을 쉽게 만들지만, 동시에 신뢰 경계를 바꾼다. 리포지토리의 가용성이 게시자 검증, 아티팩트 무결성, 또는 민감한 워크로드에 대한 적합성을 의미하지는 않는다.

Hugging Face는 Hub에 업로드된 pickle 파일을 스캔함으로써 이 문제의 일부를 다룬다. pickle 스캔 프로세스는 파일을 실행하지 않고 업로드된 아티팩트 내부의 작업을 분석한다.

이 통제는 리포지토리 계층에서 유용한 정보를 제공한다. 그렇다고 배포 결정에 대한 책임이 리포지토리 운영자에게 이전되는 것은 아니다.

스캔은 새로운 우회 기법을 놓칠 수 있다. 파일이 변경되거나, 다른 호스트가 아티팩트를 배포하거나, 배포 코드가 추가 구성 요소를 가져오는 경우에는 정보가 오래될 수도 있다.

따라서 보안 팀은 리포지토리 스캔을 하나의 신호로 취급해야 한다. 이는 내부 출처 검증, 격리, 접근 제어, 또는 런타임 모니터링을 대체할 수 없다.

모델에 사용자 지정 코드가 필요할 때 소유권 문제는 더 어려워진다. 일부 리포지토리는 프레임워크가 비표준 아키텍처를 로드할 수 있도록 원격 코드를 허용하라고 안내한다.

사용자 지정 코드가 자동으로 악성인 것은 아니다. 그러나 이를 활성화하면 검토는 데이터 로딩 결정에서 소프트웨어 실행 결정으로 바뀐다.

같은 우려는 모델 서빙 확장 기능, 토크나이저, 이미지 프로세서, 전처리 스크립트에도 적용된다. 모델 파일은 배포된 객체 그래프의 한 부분일 뿐이다.

에이전트는 이 격차를 더욱 넓힌다. AI 에이전트는 데이터베이스를 조회하거나 티켓을 수정하는 등 작업을 수행할 수 있는 도구와 모델을 결합한다.

모델은 신뢰할 수 있는 제공업체가 안전하게 호스팅할 수 있지만, 주변 에이전트는 여전히 과도한 권한을 보유할 수 있다. 반대로 권한이 엄격하게 제한된 에이전트도 신뢰할 수 없는 로컬 모델 아티팩트의 위험을 물려받을 수 있다.

CISO에게는 두 관점 모두 필요하다. 모델 공급망 보안은 시스템이 무엇으로 구성되는지를 다루고, 에이전트 보안은 실행 중인 시스템이 무엇을 할 수 있는지를 다룬다.

압박은 보안 엔지니어링, 머신러닝 운영, 조달, 애플리케이션 소유자에게 함께 가해진다. 어느 한쪽도 정책 메모 하나만으로 문제를 해결할 수 없다.

실행 가능한 소유권 모델은 모든 프로덕션 모델에 책임 소유자를 지정한다. 또한 아티팩트 출처, 다이제스트, 형식, 라이선스, 로더, 의존성, 승인된 사용 사례를 기록한다.

다이제스트는 파일의 암호학적 지문이다. 이를 통해 팀은 검토된 아티팩트가 배포 단계로 들어가는 아티팩트와 일치하는지 확인할 수 있다.

이 증거는 모델이 승격 단계를 거치는 동안 함께 따라가야 한다. 그렇지 않으면 프로덕션 파이프라인이 동일한 리포지토리 이름 아래 더 새로운 파일을 조용히 가져올 수 있다.

이는 덜 일반적인 구성 요소에 적용된 일반적인 공급망 규율이다. 새로움은 추적 가능성의 필요성이 아니라 그 구성 요소의 동작에 있다.

진짜 충돌: 데이터로서의 모델과 코드로서의 모델

팀이 모델이 수학적 가중치만 담고 실행 가능한 결과는 초래하지 않는다고 가정할 때 AI 배포는 무너진다.

이 가정은 합리적으로 보인다. 개념적으로 신경망은 정의된 아키텍처가 사용하는 학습된 파라미터로 구성된다.

패키징 계층은 이 그림을 복잡하게 만든다. 체크포인트에는 텐서, 객체 정의, 옵티마이저 상태, 메타데이터, 원래 환경을 재구축하는 데 필요한 참조가 포함될 수 있다.

pickle은 복잡한 Python 객체를 직렬화할 수 있기 때문에 이러한 유연성을 지원한다. 같은 유연성은 안전하지 않은 로딩을 위험하게 만든다.

악성 pickle 페이로드는 모델의 가시적인 성능을 바꿀 필요가 없다. 평가자가 모델에 첫 번째 질문을 하기 전에 로딩 과정에서 운영체제 명령을 시도할 수 있다.

이 순서는 모델 출력에만 집중하는 검토를 무력화한다. 정확도 테스트, 안전 프롬프트, 편향 평가는 초기화 중 이미 실행된 코드를 탐지할 수 없다.

반대 경로는 임의 객체 재구성을 지원하지 않고 텐서를 저장하도록 설계된 형식을 사용한다. Safetensors는 더 안전하고 효율적인 텐서 저장을 위해 개발된 대표적인 사례다.

이 구조는 제한된 메타데이터 헤더와 원시 텐서 데이터를 분리한다. 이 형식을 로드할 때는 Python pickle 명령이 호출되지 않는다.

이 설계는 pickle 역직렬화가 만드는 특정 임의 코드 실행 경로를 제거한다. 그렇다고 완전한 AI 시스템을 신뢰할 수 있게 만드는 것은 아니다.

safetensors 파일도 조작된 모델을 나타낼 수 있다. 모델은 학습 중 습득한 백도어를 포함하거나 특정 트리거 이후 위험한 출력을 생성할 수 있다.

파일 형식 안전성과 모델 동작 안전성은 서로 다른 계층이다. 둘 중 하나를 완전한 보호 수단으로 간주하면 같은 범주 오류를 되풀이하게 된다.

이 구분은 스캐너 하나만으로 사안을 해결할 수 없는 이유도 설명한다. 정적 스캔은 파일 구조와 의심스러운 작업을 검사할 수 있지만, 모델 동작이 무해하다고 보장할 수는 없다.

반대로 동작 평가는 안전하지 않은 초기화 코드가 없었다는 사실을 증명할 수 없다. 보안에는 로딩 전, 평가 중, 배포 후의 검사가 필요하다.

OWASP는 대규모 언어 모델 애플리케이션의 주요 위험 가운데 공급망 약점을 포함한다. LLM 보안 목록은 모델, 데이터, 배포 플랫폼, 외부 구성 요소를 포괄한다.

더 넓은 관점이 중요한 이유는 AI 서비스가 단순한 체크포인트 이상으로 구성되기 때문이다. 여기에는 추론 소프트웨어, 검색 시스템, 플러그인, API, 데이터 처리 계층이 포함된다.

공격자는 이 체인에 진입할 수 있는 신뢰 경로 하나만 확보하면 된다. 탈취된 계정, 변조된 아티팩트, 종속성 대체, 느슨한 로더가 그 경로를 제공할 수 있다.

이는 속도와 보증을 정면으로 충돌하게 만든다. 공개 모델은 팀이 벤더 계약이나 긴 학습 주기를 기다리지 않고 아이디어를 검증할 수 있게 해준다.

그러나 같은 편의성은 변경 가능한 참조와 검토되지 않은 다운로드를 부추긴다. 리포지토리 이름이 검증된 출처를 대신하게 될 수 있다.

올바른 대응은 오픈 모델을 전면 금지하는 것이 아니다. 폐쇄형 서비스에도 제공업체 종속성, 원격 데이터 처리, 제한적인 아티팩트 가시성 등 다른 위험이 존재한다.

보안 리더는 각 배포 경로에 맞는 통제 수단을 마련해야 한다. 관리형 API에는 벤더, 데이터, 신원, 로깅 검토가 필요하다.

자체 호스팅 모델에는 아티팩트 출처 검증, 파일 형식 정책, 격리된 평가, 종속성 통제, 인프라 강화가 추가된다. 동시에 운영자는 이러한 보호 장치에 대해 더 직접적인 통제권을 갖게 된다.

실질적인 트레이드오프는 분명하다. 자체 호스팅은 데이터 통제력을 높일 수 있지만, 공급망 책임은 도입 조직에 더 많이 전가된다.

이 책임에는 모델 자체, 로더, 관련 코드, 변환 도구, 향후 업데이트가 포함된다. 초기 보안 승인 이후에도 책임은 계속된다.

따라서 Google News의 경고는 일회성 체크리스트 항목이 되어서는 안 된다. 노출 위험은 모델이 개정될 때마다, 새로운 통합이 추가될 때마다 이어진다.

더 안전한 형식은 위험을 낮추지만 신뢰를 확립하지는 않는다

안전한 직렬화 형식은 하나의 실행 경로를 차단할 뿐, 출처, 모델 동작, 배포 권한 문제는 여전히 해결되지 않은 채 남는다.

Safetensors는 애플리케이션이 텐서 가중치를 저장하고 불러와야 할 때 강력한 기본 선택지다. 더 제한적인 형식으로, pickle이 제공하는 일반 객체 재구성을 피한다.

PyTorch의 제한된 로더는 호환 가능한 체크포인트에 또 다른 유용한 방어 수단을 제공한다. 두 통제 수단 모두 모델을 불러올 때 예기치 않은 Python 객체가 실행될 가능성을 낮춘다.

그러나 어느 통제 수단도 누가 모델을 학습했는지 답해주지 않는다. 배포 전에 공격자가 가중치를 변조했는지 여부도 확인해주지 않는다.

악의적으로 학습된 모델은 파라미터 안에 동작을 숨길 수 있다. 트리거는 표적 오분류, 데이터 유출, 특정 원치 않는 응답을 유발할 수 있다.

이러한 위협은 pickle 페이로드와 다르다. 단순한 파일 파싱이 아니라 동작 테스트, 출처 증거, 모니터링이 필요하다.

모델 변환에도 주의가 필요하다. 안전하지 않은 체크포인트를 더 안전한 형식으로 변환하려면 원본 파일을 불러와야 할 수 있다.

신뢰된 워크스테이션이나 프로덕션 네트워크에서 변환이 이뤄지면, 안전한 출력물이 생성되기도 전에 위험한 작업이 발생할 수 있다. 변환은 격리되고 일회용인 환경에서 수행해야 한다.

해당 환경에는 프로덕션 자격 증명과 민감한 데이터가 없어야 한다. 변환 프로세스에 문서화된 필요성이 없다면 네트워크 접근도 비활성화해야 한다.

변환된 아티팩트에는 새 다이제스트를 부여하고, 원본과 연결하는 기록을 남겨야 한다. 검토자는 스캐너 결과, 변환 로그, 승인 증거를 보관해야 한다.

이 증거는 관리 연속성을 만든다. 이후 경고가 발생했을 때 사고 대응팀이 특정 아티팩트를 받은 시스템을 파악하는 데 도움이 된다.

모델 리포지토리는 이미 유용한 메타데이터, 버전 이력, 스캔 신호를 제공한다. 기업은 개발자의 브라우저 이력에 의존하기보다 이러한 증거를 수집해야 한다.

더 강력한 패턴은 프로덕션 소스로 내부 레지스트리를 사용하는 것이다. 외부 아티팩트는 격리 구역에 들어와 검토를 거친 뒤 변경 불가능한 내부 식별자를 부여받는다.

그 후 프로덕션 시스템은 해당 레지스트리에서 승인된 다이제스트만 가져온다. 외부 브랜치나 태그 아래에 현재 표시되는 임의의 파일을 가져오지 않는다.

네트워크 통제도 이 설계를 강화한다. 모델 서빙 워크로드는 배포 후 무제한 아웃바운드 접근이 필요하지 않아야 한다.

이 접근을 제한하면 숨겨진 다운로더나 자격 증명 탈취 페이로드의 가치가 줄어든다. 또한 예기치 않은 연결을 더 쉽게 탐지할 수 있다.

최소 권한 원칙도 마찬가지로 중요하다. 호스팅 플랫폼이 공유 서비스 계정을 사용한다는 이유만으로 모델 프로세스가 클라우드 관리 권한을 상속해서는 안 된다.

시크릿은 특정 도구에 필요할 때만 제공돼야 한다. 에이전트에는 전체 비즈니스 시스템용 일반 토큰이 아니라 좁은 범위의 작업 단위 권한을 부여해야 한다.

NIST는 안전하고 회복력 있는 운영을 신뢰할 수 있는 AI의 핵심 요소로 본다. NIST의 AI risk framework는 시스템 수명주기 전반에 걸친 지속적인 거버넌스, 측정, 매핑, 관리를 강조한다.

이 수명주기 관점은 흔한 실수를 막는다. 팀은 모델을 한 번 승인한 뒤, 검토 대상 시스템을 바꾸는 자동 업데이트를 허용할 수 있다.

지속적인 모니터링은 아티팩트 변경, 로더 구성 변경, 새로운 아웃바운드 연결, 비정상적인 시크릿 접근을 탐지해야 한다. 에이전트의 작업도 기록해야 한다.

로그에는 발생한 일을 재구성할 수 있을 만큼의 맥락이 필요하다. 모델 버전, 도구 호출, 사용자 신원, 권한 부여 결정이 없는 요청 기록은 조사 가치가 제한적이다.

하지만 로깅 자체도 위험을 초래한다. 프롬프트와 출력에는 규제 대상 정보, 개인정보, 기밀 정보가 포함될 수 있다.

팀은 모든 것을 수집하기 전에 보존, 마스킹, 접근 정책을 정의해야 한다. 보안 텔레메트리가 민감한 비즈니스 데이터의 통제되지 않은 복제본이 되어서는 안 된다.

회의적인 관점은 여전히 중요하다. 어떤 스캐너, 형식, 레지스트리도 AI 시스템이 무해하다는 것을 증명할 수는 없다.

목표는 방어 가능한 위험 감소다. 조직에는 침해를 어렵게 만들고, 피해 범위를 제한하며, 대응을 위한 증거를 보존하는 다층 통제가 필요하다.

다음 모델 배포 전 CISO가 요구해야 할 사항

최소한으로 수용 가능한 통제는 승인된 소스 아티팩트에서 제한된 프로덕션 프로세스까지 추적 가능한 경로다.

첫 번째 요구 사항은 인벤토리다. 모든 프로덕션 AI 시스템은 모델, 버전, 아티팩트 다이제스트, 형식, 소스, 소유자, 로더, 배포 위치를 식별해야 한다.

인벤토리에는 어댑터와 파인튜닝도 포함해야 한다. 기본 모델은 그대로여도 어댑터가 그 동작을 실질적으로 바꿀 수 있다.

기록은 토크나이저, 사용자 지정 코드, 검색 구성 요소, 외부 도구도 포괄해야 한다. 이러한 요소는 모델 가중치를 바꾸지 않고도 보안 결과를 바꿀 수 있다.

두 번째 요구 사항은 반입 게이트다. 팀은 외부 아티팩트를 개발 워크스테이션이나 프로덕션 빌드로 직접 내려받지 말고 격리 구역으로 다운로드해야 한다.

게이트는 존재하는 경우 예상 다이제스트를 검증해야 한다. 파일 유형, 아카이브 내용, 서명, 리포지토리 보안 신호를 검사해야 한다.

안전하지 않은 직렬화 형식에는 기본 거부 규칙이 필요하다. 예외에는 왜 더 안전한 형식이나 제한된 로더로 워크로드를 지원할 수 없는지 문서화해야 한다.

예외에는 평가에 사용한 격리 통제도 명시해야 한다. 잘 알려진 업로더에 대한 신뢰는 관련 요소이지만 완전한 기술적 보호 장치는 아니다.

세 번째 요구 사항은 재현성이다. 배포 파이프라인은 변경 불가능한 아티팩트, 종속성 잠금 파일, 컨테이너 이미지, 구성을 참조해야 한다.

재현성은 방어 담당자가 검토된 시스템을 다시 구축할 수 있게 한다. 또한 테스트와 프로덕션 사이의 조용한 드리프트를 줄인다.

네 번째 요구 사항은 제한된 실행이다. 평가는 프로덕션 시크릿, 민감한 마운트, 광범위한 네트워크 접근이 없는 임시 환경에서 이뤄져야 한다.

프로덕션 추론은 자체 신원으로 실행해야 한다. 이 신원은 승인된 사용 사례에 필요한 권한만 가져야 한다.

다섯 번째 요구 사항은 AI 사고 대응 계획이다. 대응팀에는 모델 폐기, 에이전트 비활성화, 노출된 자격 증명 교체, 영향을 받은 배포 위치 파악을 위한 절차가 필요하다.

기존 엔드포인트 경고는 의심스러운 명령을 실행한 컨테이너를 식별할 수 있다. 대응자는 어느 모델 아티팩트와 로더가 그 프로세스를 시작했는지도 파악해야 한다.

여섯 번째 요구 사항은 책임성이다. 보안팀이 모든 모델 결정을 맡을 수는 없지만, 승인에 필요한 증거를 정의할 수는 있다.

모델 소유자는 프로덕션 아티팩트가 검토된 다이제스트와 일치함을 보증해야 한다. 플랫폼 팀은 승인된 레지스트리와 로더 정책을 강제해야 한다.

조달 부서는 벤더에게 모델 출처, 업데이트 관행, 보안 테스트, 사고 통지를 설명하도록 요구해야 한다. 계약 문구는 엔지니어링 통제를 대체할 수 없지만 책임을 설정할 수는 있다.

AI 자재 명세서가 이 기록을 뒷받침할 수 있다. 이는 소프트웨어 구성 요소 인벤토리를 모델, 데이터세트, 프레임워크, 관련 AI 자산까지 확장한다.

이 개념은 기존 소프트웨어 자재 명세서보다 표준화 수준이 낮다. 그럼에도 조직은 검증할 수 있는 정보부터 수집해야 한다.

Cloud Security Alliance는 악의적인 모델 리포지토리를 새로운 공격 표면으로 설명했다. 해당 repository analysis는 모델 파일, 주변 코드, 배포 파이프라인을 서로 연결된 위험으로 지목한다.

보안 리더는 이러한 우려를 강제 가능한 플랫폼 기본값으로 전환해야 한다. 즉시 작동하는 노트북 명령 앞에서 지침만으로는 밀릴 수밖에 없다.

좋은 기본값은 승인된 경로를 더 쉽게 만든다. 팀에는 지원되는 내부 레지스트리, 자동화된 스캔, 변환 지원, 재사용 가능한 격리 평가 환경이 제공돼야 한다.

예외는 가시적이고 일시적이어야 한다. 기술적 제약이 사라지거나 더 안전한 아티팩트를 사용할 수 있게 되면 만료돼야 한다.

CISO는 이러한 통제가 제공하는 것을 과장해서도 안 된다. 깨끗한 스캔이 모델의 동작을 인증하는 것은 아니며, 승인된 모델도 여전히 오용될 수 있다.

목표는 거버넌스가 적용된 배포 경로다. 이는 명확한 신뢰 경계를 만들고 하나의 보증 계층이 실패했을 때 발생할 수 있는 일을 제한한다.

격차가 좁혀지고 있는지 보여줄 세 가지 신호

다음 단계는 더 안전한 기본값, 검증 가능한 모델 출처, 강제 가능한 런타임 경계로 평가될 것이다.

첫 번째 신호는 실행 불가능한 모델 형식과 제한된 로더의 사용 확대다. PyTorch의 기본값 변경은 이미 생태계를 그 방향으로 움직이고 있다.

엔터프라이즈 플랫폼이 안전하지 않은 로딩을 자동으로 거부하는지 지켜봐야 한다. 개발자가 레거시 호환성을 유지하기 위해 더 안전한 설정을 일상적으로 무시하는지도 살펴봐야 한다.

빈번한 재정의는 낙관적인 전망을 약화시킬 것이다. 이는 워크플로 마찰이 여전히 안전한 기본값을 무력화하고 있음을 보여준다.

예외 비율이 낮아진다면 반대의 결론을 뒷받침할 것이다. 이는 모델 게시자와 애플리케이션 팀이 패키징 관행을 조정하고 있음을 의미한다.

두 번째 신호는 배포 이후에도 유지되는 모델 출처다. 리포지토리 메타데이터는 도움이 되지만, 기업에는 정확한 프로덕션 아티팩트와 연결된 변경 불가능한 내부 기록이 필요하다.

클라우드 플랫폼과 모델 레지스트리가 표준 배포 워크플로를 통해 서명, 증명, 종속성 세부 정보, 승격 이력을 제공하는지 주목해야 한다.

증명은 아티팩트가 어떻게 생성되거나 검증됐는지에 관한 서명된 증거다. 그 가치는 서명 뒤에 있는 신원, 프로세스, 정책에 달려 있다.

출처에는 파인튜닝과 변환도 포함돼야 한다. 그렇지 않으면 서명된 기본 모델이 추적 불가능한 프로덕션 파생물로 이어질 수 있다.

이 영역의 진전은 모델 반입이 거버넌스가 적용된 공급망으로 자리 잡고 있다는 관점을 강화할 것이다. 파편화된 메타데이터와 변경 가능한 참조는 이를 약화시킬 것이다.

세 번째 신호는 에이전트와 모델 서빙 워크로드를 위한 더 나은 격리다. 여기에는 워크로드 신원, 도구 수준 권한, 아웃바운드 네트워크 정책, 완전한 작업 로그가 포함된다.

에이전트 도입은 위험의 중심을 생성된 텍스트에서 실행된 행동으로 옮기고 있습니다. 이메일, 소스 코드 또는 재무 시스템에 접근할 수 있는 모델은 부정확한 답변을 넘어선 결과를 초래합니다.

보안팀은 공급업체가 관리자가 테스트하고 감사할 수 있는 권한 경계를 제공하는지 살펴봐야 합니다. 안전한 자율성에 관한 마케팅 주장은 충분하지 않습니다.

유용한 통제 수단은 어떤 ID가 행동을 승인했는지, 어떤 도구가 이를 실행했는지, 어떤 모델이 이를 제안했는지, 그리고 어떤 정책이 이를 허용했는지를 보여줘야 합니다.

조직은 비상 종료 절차도 테스트해야 합니다. 구성 문서에만 존재하는 통제 수단은 실제 사고 발생 시 실패할 수 있습니다.

정기적인 격리 테스트의 증거는 신뢰를 강화할 수 있습니다. 공유 자격 증명과 제한 없는 도구는 에이전트 배포가 거버넌스를 앞지르고 있음을 보여줄 것입니다.

이 세 가지 신호는 함께 봐야 합니다. 안전한 파일은 초기화 위험을 줄이고, 출처 추적은 신뢰 판단을 강화하며, 격리는 배포 후 피해를 제한합니다.

어느 하나만으로 완전한 보장을 제공하지는 않습니다. 그러나 함께 사용하면 암묵적 신뢰 모델을 검사하고 검증할 수 있는 시스템으로 대체합니다.

Google News 헤드라인은 보안 리더들이 더 정확한 질문을 던지게 할 때 성공합니다. 쟁점은 AI가 막연한 미래의 위험을 제시하는지 여부가 아닙니다.

당면한 질문은 배포된 모든 모델에 알려진 출처, 안전한 로딩 경로, 제한된 ID가 있는지입니다. 많은 조직은 아직 이 세 가지 모두에 답하지 못합니다.

이 검증 격차가 진짜 보안 허점입니다. 이는 익숙한 도구가 낯선 신뢰 결정을 만들어 내는 실험과 운영 환경 사이에 존재합니다.

보안 리더는 이번 주 배포된 모델 하나를 선택해 그 이력을 거슬러 추적해야 합니다. 해당 모델의 다이제스트, 소스, 로더, 사용자 지정 코드, 권한 및 업데이트 경로를 파악하십시오.

어떤 연결 고리라도 기억이나 기록되지 않은 개발자 선택에 의존한다면, 조직은 실행 가능한 과제를 발견한 것입니다. 다음 Google News 경고가 그 연결 고리가 경영진의 관심을 처음 받는 계기가 되어서는 안 됩니다.