[기고]신뢰를 공격하는 시대, 공급망 보안의 기준이 바뀌고 있다

AI 공격 시대, 소프트웨어 구성요소와 운영 자산의 연결이 중요하다취약점 식별 넘어 출처 검증과 배포 통제까지 이어지는 보안체계 필요이용 위드네트웍스 상무 AI 공격 시대, 공급망 보안은 구성요소를 운영 자산과 연결하는 데서 시작한다 새 취약점이 공개되거나 공급업체가 침해를 공지하면 조직은 먼저 '그 구성요소가 우리 어느 운영 자산에 들어 있는가'에 답해야 한다. 이 질문에 답하지 못하면 패치도 격리도 시작할 수 없다. 여기에 악성 패키지, 변조된 빌드, 탈취된 유지관리자 계정처럼 CVE 검색만으로는 보이지 않는 위험도 존재한다. 따라서 소프트웨어 자재명세서(SBOM)는 구성요소 목록에 그치지 않고 운영 자산·취약점·조치 정보와 연결돼야 한다. 금융권 연쇄 침해를 분석한 한 보안기업의 백서는 금융회사들이 공통 솔루션과 서드파티 제품을 사용하는 유사한 환경에서는 한 곳에서 드러난 취약점이 여러 기관에서 반복될 수 있다고 분석했다. 같은 구성요소를 공유하는 구조에서는 구성요소의 출처·버전·배포 환경을 연결해 두어야 영향 범위를 파악할 수 있다. 공급망 보안의 본질은 더 이상 '취약한 코드 한 줄'을 찾는 데만 있지 않다. 오늘날 공격자는 개발자가 신뢰하는 경로 자체를 겨냥한다. 오픈소스 패키지 저장소, 외주 개발사, 지속적 통합·배포(CI/CD) 파이프라인, 패키지 레지스트리, 코드 서명 체계, 서비스형 소프트웨어(SaaS) 연동, AI 코딩 도구, AI 모델과 학습 데이터까지 모두 소프트웨어 공급망의 일부가 됐다. 이러한 변화는 보안팀에 근본적인 질문을 던진다. 우리가 사용하는 코드와 패키지는 어디에서 왔는가. 그 산출물은 어떤 빌드 환경에서 만들어졌고 지금 어느 서버와 서비스에서 실행되고 있는가. 배포 직전 누가 무엇을 변경했는가. 외부 파트너와 AI 도구는 어떤 데이터와 권한에 접근하는가. 그리고 이러한 질문에 사고가 발생한 뒤가 아니라 배포 이전부터 지속적으로 답할 수 있는가. AI 시대의 공급망 보안은 '취약점을 찾아 고치는 일'에서 '구성요소가 어느 운영 자산에 들어 있는지 파악하고, 그것이 신뢰할 만한 경로로 들어오고 변경됐는지 증명하는 일'로 확대되고 있다. CVE 중심 관리가 놓치는 것 전통적인 취약점 관리는 공통 취약점 및 노출 식별체계(CVE, Common Vulnerabilities and Exposures)를 중심으로 발전해 왔다. 조직은 사용 중인 라이브러리와 프레임워크를 식별하고, 알려진...