최근 기업 인프라를 위협하는 보안 취약점 트렌드는 소프트웨어 공급망의 신뢰 관계를 악용해 정상 업데이트 경로로 악성 코드를 배포하는 공급망 공격이 대다수다. 방어를 위해 SBOM(Software Bill of Materials)이 필요하다. 소프트웨어 구성 요소를 투명하게 드러내 취약한 라이브러리를 즉시 찾아내고 대응 속도를 높이는 핵심 역할을 한다.
최신 보안 취약점 및 공급망 공격 동향 분석과 위협 메커니즘
현대 기업 인프라는 단일 벤더 솔루션이 아니라 수많은 오픈소스 라이브러리와 서드파티 API가 결합된 복합 아키텍처로 구성된다. 공격자는 견고해진 외곽 방어선 대신 상대적으로 검증이 느슨한 소프트웨어 공급망 취약점을 노린다. CI/CD 파이프라인 내 빌드 도구나 업데이트 서버를 장악해 정식 서명된 파일에 백도어를 심는 방식은 탐지가 어려워 치명적이다.
전형적인 공격 경로는 타이포스쿼팅(Typosquatting)처럼 오픈소스 저장소에 악성 패키지를 올리거나, 널리 쓰이는 라이브러리 관리자 계정을 탈취해 악성 코드로 업데이트하는 경우다. 일단 내부 인프라에 침투한 악성 코드는 신뢰된 프로세스 권한을 이어받아 네트워크를 횡적 이동하며 핵심 데이터베이스나 관리자 계정을 탈취한다. 피해 범위가 단일 취약점 공격보다 훨씬 넓고, 신뢰 관계에 기반하므로 기존 시그니처 기반 탐지 시스템으론 한계가 있다.
CISO와 보안 운영팀은 외부 침입뿐만 아니라 내부로 유입되는 소프트웨어 자산 오염에서 시작된다는 점을 인지해야 한다. 신뢰할 수 있는 소스 배포뿐 아니라 배포 후 구성 요소에 대한 지속적인 무결성 검증이 필수다. 특히 클라우드 네이티브 환경 컨테이너 이미지 속 구형 라이브러리는 공격자의 최적 진입점이다.
SBOM 도입의 필요성과 보안 아키텍처 내의 역할
SBOM은 소프트웨어를 구성하는 모든 컴포넌트, 버전, 라이선스, 종속 관계를 명시한 명세서다. 공급망 공격이 고도화되면서, 내 소프트웨어에 어떤 오픈소스 라이브러리가 있는지조차 모르는 가시성 부재가 큰 리스크다. SBOM을 도입하면 제로데이 취약점이 발표됐을 때, 조직 내 수천 개 애플리케이션 중 해당 취약점 라이브러리를 쓰는 서비스를 단 몇 초 만에 찾을 수 있다.
기존 취약점 관리는 전체 시스템 스캔 방식이라 제외된 영역이나 런타임에 로드되는 라이브러리를 놓칠 수 있다. 반면 SBOM 기반 관리는 정적 명세서를 바탕으로 취약점 데이터베이스(NVD 등)와 매핑해 즉시 결과를 도출한다. 사고 대응 시간을 크게 줄이고 패치 우선순위 결정에 객관적 근거를 제공한다.
또한 SBOM은 규제 준수 측면에서도 필수 요소로 자리 잡았다. 미국 행정명령(EO 14028) 등 전 세계적으로 소프트웨어 공급자에 대한 SBOM 제출 요구가 강화되고 있으며, 기업 간 거래 시 보안 신뢰성을 증명하는 표준 지표다. SBOM은 단순 보안 도구를 넘어 소프트웨어 라이프사이클 전체 거버넌스 기반이 된다.
| 비교 항목 | 전통적인 취약점 스캔 (Vulnerability Scanning) | SBOM 기반 취약점 관리 (SBOM-based Management) |
|---|---|---|
| 탐지 방식 | 런타임 또는 파일 시스템 스캔을 통한 패턴 매칭 | 소프트웨어 구성 명세서와 취약점 DB의 상호 매핑 |
| 가시성 범위 | 스캔 설정 범위 내의 설치된 파일 위주 | 의존성 트리를 포함한 모든 하위 컴포넌트 가시화 |
| 대응 속도 | 전체 인프라 재스캔 필요 (수 시간 ~ 수 일 소요) | 명세서 쿼리를 통한 즉각적 식별 (수 초 ~ 수 분 소요) |
| 핵심 목적 | 현재 설치된 소프트웨어의 취약점 발견 | 공급망 전체의 투명성 확보 및 지속적 추적 |
CISO가 보안 아키텍처에 즉시 반영해야 할 3가지 핵심 전략
공급망 공격 위협에서 인프라를 보호하려면 단순 툴 도입을 넘어 아키텍처 차원의 전략 변화가 필요하다. 첫째, 제로 트러스트 원칙을 소프트웨어 업데이트 및 배포 프로세스에 적용한다. 신뢰된 벤더 업데이트라도 무조건 신뢰하지 않고, 스테이징 환경에서 샌드박스 분석 후 단계적으로 배포하는 파이프라인을 구축한다.
둘째, 소프트웨어 구성 요소의 전 생애주기 관리 체계를 수립한다. 개발 단계부터 SBOM을 자동 생성하고 중앙 저장소에서 관리하며, 배포 단계에서 SBOM 무결성을 검증하는 프로세스를 자동화한다. 이는 개발자와 보안팀 간 간극을 줄이고 DevSecOps를 실현하는 구체적 방법론이다.
셋째, 지속적인 모니터링과 빠른 회복 탄력성(Resilience) 확보에 집중한다. 모든 취약점을 완벽히 막는 건 불가능하므로, 침해 사고 시 영향 범위를 즉시 격리하고 정상 상태로 빠르게 복구할 백업 및 롤백 전략을 수립한다. 특히 마이크로서비스 아키텍처(MSA) 환경에서는 서비스 간 통신을 엄격히 제한하는 서비스 메시(Service Mesh) 도입을 통한 횡적 이동 차단 전략이 유효하다.
세부 실행 단계는 다음과 같다.
- 자산 식별 및 가시성 확보: 현재 운영 중인 모든 상용 소프트웨어 및 자체 개발 소프트웨어의 목록을 작성하고, 가능한 경우 벤더사에 SBOM 제공을 요청한다.
- 자동화 도구 도입: CycloneDX 또는 SPDX와 같은 표준 포맷을 지원하는 SBOM 생성 도구를 CI/CD 파이프라인에 통합해 빌드 시마다 최신 명세서를 생성한다.
- 취약점 매핑 자동화: 생성된 SBOM을 CVE(Common Vulnerabilities and Exposures) 데이터베이스와 실시간으로 연동해 새로운 취약점 발생 시 자동 알림 체계를 구축한다.
- 정책 수립 및 강제화: 특정 수준 이상의 심각도(CVSS 점수 기준)를 가진 취약점이 발견된 컴포넌트가 포함된 빌드는 배포를 자동 차단하는 게이트웨이 정책을 적용한다.
결론 및 제언
최신 보안 취약점 및 공급망 공격 동향을 보면, 공격 대상이 개별 시스템에서 소프트웨어 생태계 전체로 확장됐음을 알 수 있다. 내부 방화벽만으론 외부에서 유입되는 오염된 소프트웨어를 막을 수 없다. SBOM 도입을 통한 구성 요소 투명성 확보만이 근본적인 대응책이다. CISO는 SBOM을 단순 문서가 아닌 실시간 취약점 대응을 위한 데이터베이스로 활용해 조직의 보안 가시성을 극대화해야 한다.
지금 당장 우리 조직 소프트웨어 공급망 내 ‘알 수 없는 컴포넌트’가 얼마나 있는지 점검해보자. 가시성이 없는 곳에 보안은 없다. 전문적인 SBOM 관리 체계 구축을 통해 예측 가능한 보안 환경을 만들어가자.