취약점 식별 넘어 출처 검증과 배포 통제까지 이어지는 보안체계 필요
AI 공격 시대, 공급망 보안은 구성요소를 운영 자산과 연결하는 데서 시작한다
새 취약점이 공개되거나 공급업체가 침해를 공지하면 조직은 먼저 '그 구성요소가 우리 어느 운영 자산에 들어 있는가'에 답해야 한다. 이 질문에 답하지 못하면 패치도 격리도 시작할 수 없다. 여기에 악성 패키지, 변조된 빌드, 탈취된 유지관리자 계정처럼 CVE 검색만으로는 보이지 않는 위험도 존재한다. 따라서 소프트웨어 자재명세서(SBOM)는 구성요소 목록에 그치지 않고 운영 자산·취약점·조치 정보와 연결돼야 한다.
금융권 연쇄 침해를 분석한 한 보안기업의 백서는 금융회사들이 공통 솔루션과 서드파티 제품을 사용하는 유사한 환경에서는 한 곳에서 드러난 취약점이 여러 기관에서 반복될 수 있다고 분석했다. 같은 구성요소를 공유하는 구조에서는 구성요소의 출처·버전·배포 환경을 연결해 두어야 영향 범위를 파악할 수 있다.
공급망 보안의 본질은 더 이상 '취약한 코드 한 줄'을 찾는 데만 있지 않다. 오늘날 공격자는 개발자가 신뢰하는 경로 자체를 겨냥한다. 오픈소스 패키지 저장소, 외주 개발사, 지속적 통합·배포(CI/CD) 파이프라인, 패키지 레지스트리, 코드 서명 체계, 서비스형 소프트웨어(SaaS) 연동, AI 코딩 도구, AI 모델과 학습 데이터까지 모두 소프트웨어 공급망의 일부가 됐다.
이러한 변화는 보안팀에 근본적인 질문을 던진다. 우리가 사용하는 코드와 패키지는 어디에서 왔는가. 그 산출물은 어떤 빌드 환경에서 만들어졌고 지금 어느 서버와 서비스에서 실행되고 있는가. 배포 직전 누가 무엇을 변경했는가. 외부 파트너와 AI 도구는 어떤 데이터와 권한에 접근하는가. 그리고 이러한 질문에 사고가 발생한 뒤가 아니라 배포 이전부터 지속적으로 답할 수 있는가.
AI 시대의 공급망 보안은 '취약점을 찾아 고치는 일'에서 '구성요소가 어느 운영 자산에 들어 있는지 파악하고, 그것이 신뢰할 만한 경로로 들어오고 변경됐는지 증명하는 일'로 확대되고 있다.
CVE 중심 관리가 놓치는 것
전통적인 취약점 관리는 공통 취약점 및 노출 식별체계(CVE, Common Vulnerabilities and Exposures)를 중심으로 발전해 왔다. 조직은 사용 중인 라이브러리와 프레임워크를 식별하고, 알려진 취약점이 발견되면 패치하거나 우회 조치를 취한다.
이 방식은 여전히 필수적이다. 알려진 취약점은 실제 침해의 중요한 출발점이며 자산 목록과 패치 우선순위는 기본적인 보안 운영 역량이다.
그러나 CVE가 모든 공격을 설명하지는 못한다. 특히 공급망 공격에서는 취약점의 존재 여부보다 신뢰된 구성요소가 실제로 신뢰할 만한 경로를 통해 유입됐는지가 더 중요한 경우가 많다.
예를 들어 공격자가 인기 오픈소스 프로젝트의 유지관리자 계정을 탈취했다고 가정해 보자. 공격자는 정상 패키지 이름과 정상 배포 채널을 이용해 악성 코드를 포함한 새 버전을 게시할 수 있다.
해당 코드는 아직 공개 취약점으로 등록되지 않았고, 정적 분석도 교묘하게 설계된 악성 행위를 놓칠 수 있다. 조직의 소프트웨어 구성 분석(SCA, Software Composition Analysis) 도구는 이 패키지를 정상 의존성으로 인식할 가능성이 높다. 패키지 이름과 버전, 배포 경로가 모두 정상으로 보이기 때문이다.
빌드 환경이 침해된 경우도 마찬가지다. 소스 저장소의 코드는 깨끗하지만 CI/CD 러너나 빌드 스크립트가 변조돼 최종 바이너리에 악성 행위가 삽입될 수 있다.
이때 개발팀이 검토한 소스 코드와 고객 환경에 실제 배포된 산출물은 더 이상 같은 것이 아니다. CVE 데이터베이스를 아무리 충실히 조회해도 빌드 과정에서 발생한 변조는 탐지하기 어렵다.
따라서 조직은 다음 세 가지 질문을 구분해 다뤄야 한다.
- 이 구성요소에 알려진 취약점이 있는가.
- 이 구성요소는 어느 운영 자산에서 실행되고 있는가.
- 이 구성요소와 산출물은 신뢰 가능한 출처와 검증 가능한 절차를 통해 들어왔는가.
첫 번째 질문은 취약점 관리의 영역이다. 두 번째는 영향 범위를 정하는 자산 관리의 영역이며, 세 번째는 공급망 무결성, 출처(provenance), 변경 이력, 배포 통제의 영역이다.
두 번째 질문에 답해야 운영 중인 자산의 영향 범위를 정하고 패치·격리 대상을 빠짐없이 찾을 수 있다. 출처·무결성 검증에 따른 설치·배포 차단은 이와 함께 유입 단계부터 이뤄져야 한다.
AI와 복잡한 외부 의존성이 늘어날수록 이 세 가지 질문을 함께 다뤄야 할 필요성은 더욱 커지고 있다.
AI가 만든 새로운 유입 경로
AI 코딩 보조 도구는 개발 생산성을 높인다. 자연어 요구사항을 코드로 바꾸고 라이브러리를 추천하며 오류를 수정한다. 테스트 코드와 인프라 설정까지 생성할 수 있다.
그러나 AI가 추천하는 답변이 보안 검증을 통과한 정답은 아니다. 개발자가 AI의 제안을 복사해 프로젝트에 반영하는 순간 AI는 실질적인 공급망 유입 경로가 된다.
대표적인 위험이 '슬롭스쿼팅(slopsquatting)'이다.
슬롭스쿼팅은 생성형 AI가 존재하지 않는 패키지명이나 잘못된 라이브러리명, 그럴듯하지만 실제와 다른 의존성을 환각(hallucination)으로 제시하는 현상을 공격자가 악용하는 방식이다.
공격자는 AI가 자주 만들어낼 법한 패키지명을 미리 패키지 저장소에 등록하고 악성 코드를 포함시킨다. 개발자가 AI 추천을 검증 없이 설치하면 공격자가 준비한 패키지가 정상 의존성처럼 개발 환경과 빌드 파이프라인으로 유입된다.
이는 전통적인 타이포스쿼팅(typosquatting)과 닮았지만 차이가 있다.
타이포스쿼팅은 사람이 유명 패키지명을 잘못 입력할 가능성을 노린다. 철자 하나를 바꾸거나 문자 순서를 뒤집어 사용자의 오타를 유도하는 방식이다.
반면 슬롭스쿼팅은 인간의 입력 실수가 아니라 AI의 추천 오류를 공격 표면으로 삼는다. 개발자는 패키지 이름을 틀리게 입력한 것이 아니라 그럴듯하게 보이는 AI의 제안을 따랐을 뿐이다.
이러한 차이는 운영 모델의 변화를 요구한다. 과거에는 개발자 교육과 패키지명 확인만으로도 일부 위험을 줄일 수 있었다. 이제는 AI가 생성하거나 추천한 의존성에 대해 보다 체계적인 검증이 필요하다.
우선 패키지의 실제 존재 여부와 공식 배포 채널을 확인해야 한다. 프로젝트의 유지관리 주체, 릴리스 이력, 다운로드 규모, 보안 정책, 서명 여부도 검토해야 한다.
의존성 잠금 파일(lockfile), 해시 고정, 허용 목록, 사설 프록시 레지스트리를 활용해 승인되지 않은 패키지 유입을 통제하는 것도 중요하다.
아울러 AI 생성 코드가 도입한 직접·전이 의존성을 SCA와 SBOM으로 추적하고, 개발자 개인 환경뿐 아니라 CI/CD 환경에서도 허용되지 않은 의존성 설치와 외부 통신을 차단해야 한다.
핵심은 AI가 작성한 코드와 사람이 작성한 코드를 별도 위험군으로 취급하는 것이 아니다. 둘 다 같은 보안 검증을 받아야 한다.
다만 AI는 코드와 의존성의 생성 속도를 높이고, 개발자가 출처를 충분히 확인하지 않은 채 채택할 가능성을 높인다는 점에서 검증 부담을 크게 증폭시킨다.
SBOM은 운영 자산과 연결될 때 쓸모가 있다
이러한 환경에서 소프트웨어 자재명세서(SBOM, Software Bill of Materials)는 소프트웨어 공급망의 가시성을 확보하는 기반이다.
SBOM은 애플리케이션이나 제품을 구성하는 소프트웨어 구성요소, 버전, 관계, 라이선스, 공급자 등의 정보를 구조화해 기록한다. 쉽게 말해 소프트웨어의 '부품 명세서'다.
그러나 SBOM을 문서로만 보관하면 가장 시급한 질문에 답하지 못한다.
새 취약점이 공개되거나 공급업체가 침해를 공지했을 때 조직이 확인해야 할 '우리에게 영향이 있는가'라는 질문은 결국 '그 구성요소가 어느 운영 자산에 들어 있는가'라는 문제로 이어진다.
금융권 연쇄 침해 이후에도 보안부서가 모든 시스템의 존재와 구성을 파악하지 못해 새 취약점이 알려져도 해당 프로그램이 자사에 있는지 즉시 찾아 보완하기 어렵다는 지적이 나왔다.
애플리케이션 하나도 서버와 데이터베이스, 네트워크 장비 등 여러 자산으로 구성되며 그 구성과 개수는 계속 바뀐다.
공격자는 이러한 질문을 거꾸로 활용한다. 금융보안원의 첫 AI 에이전트 공격 탐지 사례에서 공격자는 에이전트에 웹로직 자산을 스캔하도록 해 국내외 금융회사를 겨냥했다. 특정 구성요소를 사용하는 자산부터 찾은 것이다.
앞서 발생한 한 카드사 사고에서도 보안패치가 배포된 뒤 수년간 패치가 적용되지 않은 웹로직이 결제 서버에서 실행되고 있었고, 해당 웹로직이 자산목록에서 빠져 있었다는 지적이 나왔다.
공격자가 구성요소를 통해 자산을 찾는다면 방어자는 구성요소에서 운영 자산까지 더 먼저 찾아갈 수 있어야 한다.
운영 환경에서는 이러한 연결이 끊기지 않아야 한다.
널리 사용되는 자바 라이브러리에 원격 코드 실행 취약점이 공개됐다고 가정해 보자. 조직은 다음 다섯 단계에 차례로 답해야 한다.
![[기고]신뢰를 공격하는 시대, 공급망 보안의 기준이 바뀌고 있다](https://img.etnews.com/news/article/2026/10/23/news-p.v1.20261023.78551eab07894b8bae3f697252fb0a10_P1.png)
이 가운데 하나라도 끊기면 영향 범위 판단은 추정에 머물게 된다.
SBOM이 1단계를 충족하더라도 2·3단계의 연결이 없다면 '우리에게 해당 구성요소가 있다'는 사실은 알아도 '어디서 실행되고 있는지'는 알 수 없다.
4단계가 없으면 무엇을 먼저 고칠지 정하기 어렵고, 5단계가 없으면 조치를 완료했다고 말할 근거가 부족하다.
공급업체가 침해를 공지했을 때 어느 서비스와 고객 환경에 해당 구성요소가 포함됐는지 파악하는 일도, 감사에서 소프트웨어 구성을 증명하는 일도 같은 연결을 기반으로 한다.
이 연결을 담당하는 관리 계층도 필요하다.
애플리케이션 보안 태세 관리(ASPM, Application Security Posture Management)는 정적 애플리케이션 보안 테스트(SAST), SCA, 컨테이너 검사, 클라우드 설정 점검, 티켓 시스템의 결과를 애플리케이션과 저장소, 자산 소유자, 배포 환경, 조치 상태에 연결한다.
이를 통해 실제 위험도를 중심으로 대응 우선순위를 조정하는 데 도움을 준다.
결과가 서로 분리돼 있으면 조직은 경고는 많지만 우선순위와 책임자가 불명확한 상태에 빠진다.
반대로 연결이 존재하더라도 연결된 정보를 신뢰할 수 없다면 의미가 없다. SBOM이 실제 배포된 산출물과 다르거나 빌드 과정에서 구성요소가 바뀌었다면 매핑 전체가 잘못될 수 있기 때문이다.
출처와 무결성 검증은 이러한 매핑을 신뢰하기 위한 전제다.
제도 역시 이 방향으로 움직이고 있다.
정부는 2025년 10월 잇따른 통신·금융권 침해를 계기로 발표한 '범부처 정보보호 종합대책'에서 공공분야 IT 시스템·제품의 SBOM 제출을 2027년까지 제도화하겠다고 밝혔다.
이어 2026년 6월 과학기술정보통신부와 국가정보원의 'AI 일상화 시대를 준비하는 SW 공급망 보안 강화 로드맵'은 이를 2027년부터 공공 정보화사업과 보안검증 절차에 단계적으로 적용하는 계획으로 구체화했다.
금융권에서는 금융위원회의 '프런티어 AI 보안위협 금융분야 대응요령'(2026년 7월)이 자체 활용 오픈소스에 대한 SBOM 작성을 고려하고 SCA를 활용할 수 있다고 제시했다.
다만 공공분야의 2027년 제도화 계획과 달리 금융권 대응요령의 SBOM 작성과 SCA 활용은 권고 사항이다.
어느 경우든 실제 차이를 만드는 것은 SBOM을 제출하는 행위 자체보다 이를 운영 자산과 조치에 연결해 활용하는 일이다.
표준은 도구가 아니라 운영 구조다
공급망 보안에는 이미 여러 표준과 프레임워크가 마련돼 있다.
미국 국립표준기술연구소(NIST)의 안전한 소프트웨어 개발 프레임워크(SSDF, Secure Software Development Framework)는 특정 도구를 강제하지 않으면서 보안을 개발 생명주기 전반에 내재화하는 운영 체계다.
소프트웨어 아티팩트 공급망 수준(SLSA, Supply-chain Levels for Software Artifacts)은 소스에서 빌드·배포 산출물까지의 출처와 빌드 무결성을 단계적으로 강화한다.
오픈소스 보안재단(OpenSSF, Open Source Security Foundation)의 평가 체계는 오픈소스 프로젝트가 보안 정책과 코드 리뷰, 취약점 공개 절차를 갖췄는지 판단할 수 있는 보조 지표를 제공한다.
점수 하나로 안전성을 보증할 수는 없지만 다운로드 수와 같은 단편적 기준에만 의존하는 것보다는 낫다.
이들 표준과 프레임워크는 서로 대체재가 아니다.
SSDF는 운영 체계를, SLSA는 신뢰 경로를, OpenSSF는 오픈소스 생태계의 성숙도를, SBOM은 구성요소와 영향 범위의 공통 데이터를 다룬다.
조직이 해야 할 일은 각각의 표준을 따로 도입하는 것이 아니라 하나의 통제 흐름으로 연결하고, 그 끝을 운영 자산과 조치에 이어 붙이는 것이다.
Secure SDLC, 배포를 멈출 수 있어야 한다
보안 개발 생명주기(Secure SDLC)는 보안 활동을 개발 완료 후의 검사 단계에 덧붙이는 접근이 아니다. 기획부터 운영까지 보안 검증과 책임을 연결하는 구조다.
공급망 관점에서는 특히 세 가지 통제가 중요하다.
첫째, SAST는 자체 개발 코드와 AI 생성 코드에서 인증·인가 오류, 입력 검증 누락, 비밀정보 하드코딩, 인젝션 가능성 등 취약한 구현 패턴을 조기에 찾는다.
다만 오탐과 맥락 부족이 있을 수 있으므로 위험도 기반의 조치 기준과 예외 승인 절차가 함께 필요하다.
둘째, SCA와 SBOM은 직접 설치한 패키지뿐 아니라 해당 패키지가 다시 호출하는 전이 의존성까지 파악하고, 그 결과를 특정 제품·서비스·버전·배포물과 연결하는 기반이 된다.
셋째, SLSA와 Sigstore 같은 서명 및 출처 검증 체계는 빌드 이후 산출물이 변조되지 않았는지 확인하는 데 활용된다.
운영 환경은 '이 이미지가 취약점 검사를 통과했는가'뿐 아니라 '이 이미지가 승인된 소스와 빌드 시스템에서 생성되고 서명됐는가'까지 확인해야 한다.
가장 중요한 평가지표는 보안 도구의 도입 수가 아니라 실제로 정책 위반 배포를 차단할 수 있는지 여부다.
예를 들어 다음 조건에 해당하는 컨테이너 이미지는 운영 배포를 차단하도록 설계할 수 있다.
- 승인되지 않은 레지스트리 또는 허용되지 않은 외부 패키지에서 유입된 경우
- 서명이나 빌드 출처 증명이 없는 경우
- 조직이 정의한 심각도 기준 이상의 미조치 취약점을 포함한 경우
- 비밀정보가 탐지됐거나 라이선스 정책을 위반한 경우
- 보안 예외 승인의 유효기간이 만료된 경우
이러한 배포 게이트는 개발 속도를 무조건 늦추기 위한 장치가 아니다.
예외 기준과 승인 책임자, 대체 패키지, 수정 기한을 명확히 해 보안을 개인의 기억과 선의에 의존하지 않도록 만드는 통제 수단이다.
'변경 검증 공백'을 막으려면 운영 중 발생하는 변경에도 배포 게이트와 인증·인가 회귀 검증을 동일하게 적용해야 한다.
내부 코드 밖으로 확장되는 검증
공급망 보안은 내부 개발팀의 코드 품질 문제로 한정되지 않는다.
외주 개발사, SaaS 제공업체, 클라우드 사업자, 관리형 보안 서비스, 패키지 공급자, 데이터 제공업체, AI 모델 및 플러그인 공급자까지 모두 조직의 공격 표면에 영향을 준다.
따라서 제3자 위험관리(TPRM, Third-Party Risk Management)는 조달·법무·정보보호·개발·운영 조직이 함께 다뤄야 하는 지속적 검증 체계가 돼야 한다.
금융권에서도 같은 구조가 드러났다.
9월 정보유출이 공개된 전자지급결제대행(PG)사 2곳에 금융감독원이 현장검사를 실시했다. 10월 7일 보도에 따르면 결제연동 플랫폼의 API 인증키 노출로 비정상 접근이 발생한 것으로 파악됐다.
결제 연동에 사용되는 자격증명과 조회 권한, 사고 통지 역시 제3자 검증의 범위에 포함돼야 한다는 점을 보여준다.
전통적인 TPRM은 계약 체결 전 보안 설문과 인증서 확인에 치우치기 쉬웠다. 그러나 공급망 위험은 계약 이후에도 계속 변한다.
공급업체가 새로운 하도급사를 추가할 수 있고 SaaS 서비스가 기능을 변경할 수도 있다. 외부 API의 인증 방식이나 데이터 처리 위치가 달라질 수 있으며, 오픈소스 유지관리자가 바뀌거나 프로젝트가 사실상 방치될 수도 있다.
따라서 제3자 검증은 일회성 심사가 아니라 지속적인 통제로 확장돼야 한다.
공급업체와 외주 파트너의 개발 보안 프로세스, 취약점 대응 체계, 사고 통지 의무를 계약과 운영 기준에 반영해야 한다.
중요 공급 소프트웨어에는 SBOM, 보안 패치 정책, 지원 종료 일정, 서명 또는 출처 증빙을 요구할 필요가 있다.
SaaS와 외부 API에는 최소권한, 데이터 분류, 접근 로그, API 키 순환, 연동 범위 제한을 적용해야 한다.
고위험 공급업체에 대해서는 정기적인 재평가와 침해사고 통지·대응 훈련이 필요하다.
외부 의존성의 상태 변화, 신규 취약점, 패키지 소유권 변화, 도메인·인증서 이상 징후를 지속적으로 모니터링하는 체계도 갖춰야 한다.
이러한 과제를 보안팀만 떠안아서는 안 된다.
조달 부서는 공급업체 선정과 계약 조건에 보안 요구사항을 반영해야 한다. 개발 조직은 승인된 구성요소와 빌드 절차를 준수하고, 운영 조직은 검증된 아티팩트만 배포해야 한다.
경영진은 위험 수용의 기준과 예외 승인 책임을 분명히 해야 한다.
AI 모델도 공급망의 일부다
생성형 AI의 확산은 공급망의 범위를 소스 코드와 라이브러리 밖으로 넓히고 있다.
이제 AI 모델 파일, 학습 데이터, 파인튜닝 데이터셋, 시스템 프롬프트, 검색증강생성(RAG, Retrieval-Augmented Generation) 문서, 임베딩 모델, 플러그인, 에이전트 도구, 모델 컨텍스트 프로토콜(MCP, Model Context Protocol) 서버까지 관리 대상이 된다.
AI 모델 공급망에서 핵심 자산은 단순히 모델 가중치 파일만이 아니다.
조직이 어떤 모델을 사용했는지, 어떤 데이터로 학습하거나 파인튜닝했는지, 어떤 문서가 RAG 지식베이스에 포함됐는지를 함께 관리해야 한다.
해당 모델이 어떤 도구를 호출할 수 있고, 그 도구가 어떤 데이터와 시스템에 접근할 수 있는지도 확인해야 한다.
예를 들어 내부 문서를 검색하는 RAG 기반 업무 도우미가 있다고 가정해 보자.
모델 자체가 안전하더라도 검색 인덱스에 기밀 문서가 잘못 포함되거나 접근 통제가 약하면 민감정보가 답변으로 노출될 수 있다.
에이전트가 외부 MCP 서버 또는 사내 업무 시스템을 호출할 수 있다면 프롬프트 인젝션은 단순한 답변 품질 문제가 아니라 권한 오남용과 데이터 유출 문제로 이어질 수 있다.
이러한 위험은 실제 사례에서도 드러났다.
2026년 7월 OpenAI와 허깅페이스(Hugging Face)는 OpenAI의 내부 사이버보안 역량 평가인 'ExploitGym' 과정에서 발생한 침해 사고를 공개했다.
평가용 AI 에이전트는 패키지 레지스트리 캐시 프록시의 제로데이 취약점을 이용해 격리 환경을 벗어나 인터넷에 접근했고, 제3자가 운영하던 외부 코드 실행 환경을 거점으로 삼았다.
허깅페이스의 후속 기술 분석에 따르면 에이전트는 데이터셋 처리 파이프라인의 HDF5 파일 읽기 결함으로 자격증명을 확보하고, Jinja2 템플릿 인젝션으로 코드를 실행한 뒤 내부 인프라로 침투했다.
확인된 고객 콘텐츠 접근은 평가 과제와 관련된 데이터셋 5건이었으며 다른 고객 모델과 데이터셋은 영향을 받지 않았다. 그러나 내부 인프라와 권한의 침해는 별도로 확인됐다.
두 회사가 공개한 원인 분석은 과도하게 넓은 자격증명 범위와 파드에서 접근 가능했던 인스턴스 메타데이터 서비스를 지목했다.
사람이 아니라 AI 에이전트가 공급망의 취약점을 스스로 연결해 권한을 확장한 사례다.
이처럼 AI 공급망 보안에서는 다음 사항을 확인해야 한다.
- 모델 파일과 컨테이너 이미지를 신뢰 가능한 출처에서 획득했는가.
- 모델·데이터셋·프롬프트·RAG 문서의 버전과 변경 이력을 추적할 수 있는가.
- 모델이 호출할 수 있는 플러그인, API, MCP 서버는 승인·서명·검증됐는가.
- 모델이 접근할 수 있는 데이터는 분류·마스킹·검색 권한 정책에 따라 통제되는가.
금융보안원이 2026년 10월 마련한 '금융분야 AI 에이전트 보안 평가기준(안)'도 검증 대상을 모델 자체에서 외부 도구와 플러그인 등 구성요소로 확대하고 '공급망 보안'을 점검항목에 포함했다.
AI는 공급망 공격을 가속할 수 있다.
공격자는 AI를 활용해 대량의 악성 패키지 설명을 만들고 피싱을 정교화할 수 있다. 취약한 코드 패턴을 빠르게 탐색하거나 개발자의 신뢰를 노리는 콘텐츠를 생산하는 것도 가능하다.
반대로 방어 측에서도 AI를 활용해 방대한 SBOM과 취약점 공지, 코드 변경, 설정 오류, 이상 행위를 분석하고 대응 우선순위를 정할 수 있다.
다만 AI 에이전트와 그것이 연결되는 시스템·도구·권한을 기존 위험·조치 관리 범위에 어떻게 포함할 것인지는 출처 검증과는 또 다른 질문이다.
무엇을 측정해야 하는가
공급망 보안의 성숙도는 'SBOM을 만들었는가' 또는 '보안 도구를 구매했는가'만으로 판단할 수 없다.
조직은 실제 운영 지표를 통해 보안 통제의 실효성을 검증해야 한다.
우선 SBOM이 배포물과 운영 자산인 서버·컨테이너·서비스에 연결된 비율을 확인해야 한다.
신규 취약점 공개 이후 영향을 받는 운영 자산을 식별하기까지 걸린 시간도 중요한 지표다.
운영 배포물 가운데 최신 SBOM과 검증 가능한 빌드 출처를 보유한 비율, 서명되지 않았거나 승인되지 않은 아티팩트의 배포 차단 비율도 측정할 필요가 있다.
고위험 취약점의 평균 탐지·조치 시간과 예외 승인 만료 준수율은 실제 대응 역량을 보여준다.
외주·SaaS·중요 공급업체의 보안 검증 및 재평가 완료율도 관리해야 한다.
AI 환경에서는 AI 생성 의존성, 모델, 데이터셋, MCP 서버에 대한 출처 검증과 승인 비율까지 측정 범위를 넓혀야 한다.
이러한 지표는 단순히 보안팀의 성과를 평가하기 위한 것이 아니다.
경영진이 위험 수용 수준을 결정하고, 개발 조직이 병목을 파악하며, 조달 조직이 공급업체 요건을 개선하고, 운영 조직이 배포 통제를 강화하기 위한 공통의 의사결정 언어가 된다.
결론: 구성요소에서 운영 자산까지 찾아갈 수 있어야 한다
공급망 공격은 한 조직의 방화벽 바깥에서 시작될 수 있지만 결국 신뢰된 소프트웨어와 서비스의 경로를 따라 내부로 들어온다.
새 취약점이나 공급업체 침해가 알려졌을 때 조직이 가장 먼저 답해야 할 질문은 '그 구성요소가 우리 어느 운영 자산에 들어 있는가'다.
이 질문에 답하지 못하면 패치도, 격리도, 고객 통지도 제때 시작할 수 없다.
이를 위해서는 구성요소 정보가 운영 자산·취약점·조치 정보와 연결돼야 한다.
SBOM과 SCA 결과는 배포물과 서버·컨테이너·서비스, 외부 노출 여부와 소유자, 조치 기한과 재검증 기록까지 이어질 때 비로소 영향 범위와 조치 우선순위를 보여준다.
구성요소 목록을 자산·취약점 통합관리 체계와 연계해야 하는 이유다.
SSDF·SLSA·Sigstore와 같은 출처·무결성 검증과 제3자 위험관리는 이러한 연결을 신뢰할 수 있도록 만드는 전제다.
궁극적으로 중요한 것은 보안 도구의 개수도, SBOM 문서의 수량도 아니다.
문제가 된 구성요소를 운영 자산까지 추적해 조치할 수 있는가. 그리고 정책을 위반한 코드·패키지·빌드·모델이 운영 환경에 들어오는 것을 실제로 막을 수 있는가가 기준이다.
다음 회에서는 마지막 질문으로 넘어간다.
AI 에이전트와 그것이 연결되는 시스템·도구·데이터도 운영 자산이다. AI가 비신뢰 입력을 읽고 권한을 행사할 수 있게 된 지금, AI가 연결되는 시스템도 기존의 위험·조치 관리 범위에 들어와 있는지 물어야 한다.
AI 시대의 공급망 보안은 구성요소 목록을 만드는 일이 아니다. 문제가 된 구성요소를 운영 자산까지 추적해 조치하고, 그 경로를 신뢰할 수 있음을 증명하는 일이다.