제조사에서 최종 상품을 생산 판매하기 위해서는 해당 상품에 필요한 모든 부품에 대해 상세 데이터가 필요하다. 이를 BOM(Bill of Material), 즉 자재 명세서라고 한다. 이 데이터는 자재 및 필요 부품의 원활한 수급, 생산, 운송, 유통·판매, 재고 관리 등 소비자에게 상품이 최종 공급되기까지의 전 생애주기를 관리하는데 필요한 가장 핵심 정보를 담고 있다.
이를 관리하는 것을 공급망 관리(SCM: Supply Chain Management)라 부른다. 상품의 흐름뿐만 아니라 이와 관련된 정보 및 자금의 흐름도 SCM을 통해 관리된다. 구매, 개발, 제조, 마케팅, 판매, 물류, 서비스와 같은 일련의 모든 활동도 SCM으로 관리되며, 여기의 출발점이자 상품의 근본을 확인할 수 있는 핵심 정보가 바로 BOM이다.
SBOM이란?
SBOM(Software Bill of Material)은 직역하면 소프트웨어 자재 명세서이다. 최종 고객이 사용하는 소프트웨어 혹은 서비스를 완성하기 위해 활용되는 모든 소프트웨어 정보를 담고 있는 명세서라고 할 수 있다. BOM과 개념적으로 같지만, 상품의 특성은 확연히 다르며 고객이 접하는 최종 상품 형태 또한 매우 다양하다. 사용자가 직접 설치하여 사용하는 전통적인 개념의 패키지 소프트웨어, 리눅스나 윈도 같은 운영체제, 다른 소프트웨어 개발을 위해 활용되는 프레임워크나 라이브러리도 포함된다. 특히, 요새는 SaaS(Software as a Service) 형태로 제공되는 서비스 등 다양한 클라우드 서비스도 소프트웨어 관점에서의 최종 상품이다.
일반 상품의 경우 SCM(공급망 관리)에서 가장 중요한 역할을 하는 데이터가 BOM이듯, SBOM도 마찬가지로 소프트웨어 SCM의 범주에서 다뤄지기도 한다. 특히 기존 패키지 소프트웨어와는 달리 현대 소프트웨어는 단일 벤더가 전체를 모두 개발하여 공급하는 경우는 거의 없다. 대부분 애플리케이션은 이미 시장에 나와 있는 여러 패키지를 활용하여 개발하거나, 또는 제3의 서비스에서 제공되는 기능을 활용하여 만든다.
가장 대표적인 예는 오픈소스를 활용하는 것이다. 리눅스 재단에 의하면 현재 활용되는 최신 소프트웨어 솔루션의 70~80%는 오픈소스로 구성되었다고 한다. 오픈소스로 제공되는 프로그래밍 언어 프레임워크 및 소프트웨어 라이브러리, 그리고 다양한 개발 도구를 활용하여 기개발된 기술을 최대한 재사용한다.
또한, API(Application Programming Interface) 호출을 통해 제삼자가 제공하는 서비스를 활용하기도 한다. 예를 들면, 위치정보나 지도, 인증, 결제 서비스 같은 것은 직접 개발할 필요 없이 이미 안정적으로 제공되는 상용 서비스를 API 호출을 통해 적용하는 것이다.
사용하던 상품에 하자가 생기면 서비스센터를 방문하여 수리를 맡긴다. 서비스센터의 기사는 원인을 파악하기 위해 BOM에 명시된 자재를 확인하여 이를 수리하거나 교체함으로써 하자를 해결한다. 마찬가지로 사용하던 소프트웨어에 문제가 생기면 공급자의 서비스 채널을 통해 서비스를 의뢰해야 한다. 그런데, 일반 상품 제조사와는 달리 공급자는 소프트웨어 전체를 모두 직접 개발하지 않기 때문에 문제를 신속하게 찾아 해결하는 것이 거의 불가능하다. 심지어 어떤 패키지들이 포함되어 있는지조차 정확하게 파악하고 있지 못하는 경우가 많다.
더 나아가 직접 구성 요소로 포함되어 있지는 않더라도 다른 소프트웨어 모듈에 대한 종속성으로 인해 종속된 모듈 하나만 문제가 생겨도 바로 영향을 받을 수 있다. 이러한 종속성은 트리 형태로 표현되는데 이를 종속성 트리(dependency tree)라 한다.
한 예로, Log4j의 NPM 모듈만 보아도 수많은 모듈이 복잡하게 얽혀 있음을 알 수 있다(아래 그림 참고). Log4j는 자바(Java) 계열 언어로 개발된 애플리케이션에서 사용되는 시스템 로깅(logging) 도구이며, NPM은 백엔드 개발용으로 많이 사용되는 Node.js용 패키지 관리 도구이다.
SBOM이 사이버 보안에서 주목받는 이유
상품에 이미 조립되어 들어가 있는 부품과는 달리, 소프트웨어는 수시로 버전이 변경되기에 이에 대한 관리가 매우 복잡하다. 일반 상품의 부품을 업그레이드하기 위해서는 일단 상품을 공급자에게 보내 부품을 교체하는 과정을 거쳐야 한다. 따라서 언제 부품이 어떻게 교체되었는지 확실하게 인지할 수 있다. 반면, 소프트웨어는 앞서 ‘종속성 트리’ 도표에서 볼 수 있듯이 매우 복잡하게 얽혀 있는 종속성으로 인해 다른 모듈이 새 버전으로 교체되어도 정확하게 알 수 없는 경우가 다반사다. 하지만 모든 소프트웨어가 끊임없이 진화하기 때문에, 일부 모듈의 변경은 수시로 발생하기 마련이다. 바로 이런 부분이 악성 해커들이 노리는 공격 포인트다.
최근 몇 년 사이 발생한 솔라윈즈(SolarWinds)나 Log4j 사건이 대표적인 사례다. 솔라윈즈 플랫폼과 Log4j의 취약점을 이용한 공격으로 인해 이를 사용하는 수많은 애플리케이션이 영향을 받았다. 솔라윈즈 보안 침해 사고의 경우 수많은 미국 연방 기관 및 대기업이 피해를 입었는데 이 중에는 마이크로소프트와 같은 거대 소프트웨어 공급자도 포함되어 있다. 아파치 소프트웨어 재단에서 오픈소스로 제공하는 Log4j는 수백만 자바 애플리케이션에 영향을 주기도 했다. 자바로 개발된 대부분 애플리케이션이 시스템 로깅을 위해 Log4j를 사용하기 때문이다. 특히 자바로 개발된 금융권 등 기업의 주요 애플리케이션이 영향을 받아 그 파급효과가 더욱 컸었다.
만일, 솔라윈즈나 Log4j의 취약점에 대해 이미 알고 있었다면 이로부터 파생된 보안 위협을 미리 알아챌 수 있었을까? 실상은 그렇지 않다는 것이 일반적인 견해다. 이런 보안 취약점이 알려져 있다고 하더라도, 최종 사용자는 자신이 사용하는 애플리케이션에 이런 모듈이 적용되어 있는지 알지 못하고 있기에 제때 대응하지 못하기 때문이다. 수많은 모듈이 Log4j와 얽혀 있다면 Log4j가 아닌 다른 모듈을 통한 공격에는 속수무책일 것이다. 그러나 종속성 트리에 있는 모든 모듈이 어떤 것인지 정확하게 파악하고 있고, 또 이들 상태를 실시간으로 모니터할 수 있다면 이 중 하나만 문제가 생겨도 일단 애플리케이션 사용을 중단함으로써 문제 확산을 최소화할 수 있을 것이다. SBOM이 사이버 보안에 매우 중요한 요소인 이유다.
클라우드 네이티브 컴퓨팅 보안과 SBOM
클라우드에 최적화된 애플리케이션 개발 및 배포를 위한 개념으로 클라우드 네이티브 컴퓨팅이 등장했다. 특히 기업 관점에서 더욱 효율적으로 클라우드를 활용하기 위해 프라이빗 클라우드와 퍼블릭 클라우드를 혼용하는 하이브리드 클라우드가 대세로 자리매김하며 클라우드 네이티브 컴퓨팅이 급속히 늘어나는 추세다. 클라우드 네이티브 컴퓨팅을 요약하면, 모든 워크로드(workload)가 어디서든 실행될 수 있도록 호환성을 유지하며 필요에 따라 프라이빗 클라우드 혹은 퍼블릭 클라우드에 배포될 수 있도록 하는 개발 및 배포 전 단계에 적용되는 컴퓨팅 패러다임이다. 이를 위해서 일반적으로 다음 네 가지 특성을 갖추어야 한다고 말한다.
- 컨테이너화(Containerization): 모든 실행 워크로드는 컨테이너로 패키징 됨
- 마이크로서비스 구조: 서비스 단위를 기능별로 잘게 쪼개 각각을 독립적인 (마이크로) 서비스로 배포할 수 있도록 함
- 데브옵스(DevOps): 개발/배포/운영 전 과정의 파이프라인이 반복적으로 물 흐르듯 이루어짐
- CI/CD: 통합 및 배포 전 과정 즉 데브옵스 파이프라인을 적절한 도구를 활용함으로써 자동화함
클라우드 네이티브 컴퓨팅 기반 애플리케이션의 특징은 컨테이너와 마이크로서비스로 설명될 수 있다. 사용자가 접하는 최종 애플리케이션은 다수의 마이크로서비스로 구성되어 있고 각각의 마이크로서비스는 각각 독립적으로 운영되며 진화한다. 각 마이크로서비스는 하나 혹은 다수의 컨테이너로 구성될 수 있다. 한편, 컨테이너 자체도 여러 필요한 모듈을 하나로 모아 패키지화 것이다. 이렇게 패키지화할 때는 상호 호환되는 ‘가급적 최신’ 모듈로 구성하는 것이 중요하다. 예를 들어, 모듈 중 어느 하나가 최신 버전으로 업그레이드되었더라도, 이 새 모듈이 다른 기존 모듈과 호환되지 않는다면 아무리 최신 모듈이라도 컨테이너로 패키지화할 때 배제할 수밖에 없다. 이렇게 함으로써 컨테이너의 유효성을 담보할 수 있다. 일단 컨테이너로 포장되면 해당 컨테이너를 실행할 수 있는 엔진이 탑재된 곳 어디서든 실행할 수 있다.
클라우드 네이티브 애플리케이션은 특성상 소프트웨어 구성 자체가 매우 복잡한 모양을 갖고 있다(위 개념도 참고). 많은 모듈이 복잡하게 상호 의존하는 구조이며, 최종 애플리케이션이 실행되기까지는 모든 컨테이너가 배포되어 있어야 하고, 각 컨테이너는 서로 호환되는 패키지들을 모아 빌드해야 한다. 컨테이너를 구성하는 패키지도 흔히 다른 모듈들을 활용한다.
따라서 해커의 눈에는 도처에 공격할 포인트가 보일 수밖에 없는 구조다. 우선 컨테이너를 빌드할 때 활용되는 패키지를 위변조하는 공격이 가능하다. 이 중 일부만 해커가 건드려도 전체 컨테이너, 나아가서 애플리케이션에 치명적인 위협을 가할 수 있다. 그다음 단계로 공격하기 좋은 포인트는 컨테이너 배포 시점이다. 배포 시 원래 컨테이너 대신 해커가 위변조한 컨테이너로 바꿔치기하는 것이다. 이 역시 오염된 컨테이너로 인해 애플리케이션 사용자는 심각한 보안 위협에 노출될 수 있다. 대표적인 예로 사용자의 개인정보 유출을 들 수 있다.
이런 침해 사고를 예방하는 데 필요한 가장 선제 조건이 바로 SBOM을 완벽하게 갖추는 것이다. 최종 사용자 애플리케이션에 도달하기까지 사용되는 모든 소프트웨어 모듈 정보를 정확하게 파악하고 있어야 하며, 각 모듈의 무결성이 담보되어야 한다. 이를 위해서는 각 모듈의 첵썸(checksum) 데이터 같은 것을 활용하여 수시로 모듈의 위변조 상태를 확인할 수 있어야 한다. 일부 정체가 불분명한 모듈을 절대 사용하지 않는 것도 중요한데 이는 확실히 검증된 모듈을 확인할 수 있는 화이트리스트 도구를 활용하여 가능하다.
좀 더 넓은 의미의 사이버 보안 관점에서는 구성하고 있는 소프트웨어 모듈의 위변조 상태뿐만 아니라 각 모듈 간의 호환성도 중요하다. 동일한 기능을 수행하는 소프트웨어라고 하더라도 이들을 조합하여 더 큰 애플리케이션으로 활용할 때 서로 호환되는 소프트웨어를 사용하는 것이 필수적이기 때문이다. 예를 들면 파이썬과 밀접하게 결합하는 텐서플로우 같은 경우 서로 호환되지 않는 버전들이 존재한다. 이 경우 각 패키지는 아무 문제가 없더라도 이를 바탕으로 전체 애플리케이션을 만들어 활용할 때 제대로 동작하지 않거나, 혹은 의도하지 않은 결과를 만들어 낼 수 있다.
호환성 이슈와 함께 중요한 것이 라이선스 이슈이다. 배포하는 패키지에 일부 소유권 또는 사용권이 제한되는 모듈이 포함되어 있다면 전체 애플리케이션 배포 자체가 무효화 될 소지가 있다. 이런 상황은 오픈소스를 활용할 때 더욱 문제가 될 가능성이 있다. 오픈소스마다 적용되는 다양한 라이선스 정책으로 인해 배포 및 사용에 각각 다른 제약이 따를 수 있기 때문이다.
예를 들어 결과물의 모든 소스 공개를 원칙으로 하는 라이선스 정책을 고집하는 오픈소스를 활용하여 상용 애플리케이션을 개발한다면 이 역시 모든 소스를 공개해야 하는 의무가 있음에도 불구하고 이를 간과하는 경우가 흔히 있다. 이 경우, 오픈소스 라이선스 정책에 대한 정확한 이해 없이 결과물을 배포했다가 사업적으로 치명적인 손해를 입을 수 있다.
사이버 보안, 애플리케이션 호환성, 라이선스, 이 모든 이슈가 클라우드 네이티브 컴퓨팅 환경에서 극복해야 할 과제다. 따라서 SBOM에 포함되어야 할 정보도 매우 복잡해질 수밖에 없다. 소프트웨어 버전, 첵썸 정보, 그리고 종속성 트리 및 호환성 정보 등을 모두 갖추고 있어야 한다. 또한, 이 모든 정보는 기계가 판독할 수 있어야 한다. 따라서, SBOM을 구성하는 정보를 정형화해서 가능한 표준화하는 것이 필요하여, SPDX, CycloneDX, SWID와 같은 주요 포맷들이 정의되어 있다.
클라우드 네이티브 컴퓨팅에서 중요한 특성은 데브옵스 및 CI/CD(연속 통합/배포) 파이프라인을 자동화하는 것이다. 요새는 사이버 보안을 강조한 데브섹옵스(DevSecOps)로 확장하여 이 프로세스 구현을 위한 전략 및 도구에 관한 관심이 높다. 상용 혹은 오픈소스로 나와 있는 보안 솔루션, 특히 엔드포인트 보안 솔루션에 SBOM을 생성하는 기능이 탑재되고 있으며, 이들 보안 솔루션의 핵심 기능으로 자리매김하고 있다. 또한, 데브섹옵스 파이프라인 상의 빌드, 통합, 배포 각 단계에 SBOM 정보를 바탕으로 각 패키지를 확인함으로써 최종 배포되는 애플리케이션 취약점을 사전에 탐지할 수 있다. 마이크로서비스 형태로 이미 배포되었을 때 이를 실시간으로 모니터하며 이상을 감지하는 것도 엔드포인트 보안 도구의 주요 기능이다.
SBOM이 주목받는 이유
소프트웨어 SCM(공급망 관리)에서 보안의 중요성이 대두되면서 SBOM이 큰 주목을 받기 시작했다. 앞서 잠깐 언급한 솔라윈즈나 Log4j 보안 사고는 소프트웨어 SCM 보안 중요성을 새삼 각인시켰다. 클라우드 네이티브 애플리케이션은 기존 온-프레미스 애플리케이션과는 비교하기 어려울 정도로 소프트웨어 공급망이 복잡하다.
참고로 클라우드 네이티브 컴퓨팅은 미국 정부 소프트웨어 현대화의 중심 기조이기도 하며, 이를 뒷받침하는 사이버 보안과 관련된 정책이 구체화 되고 있다. 이에, 바이든 대통령이 서명한 ‘국가 사이버 보안 개선’을 위한 행정명령에 따라 NTIA(국가 정보통신 관리국)는 SBOM에 관해 비교적 상세한 요구 사항을 제시하였다.
일반기 업에서도 소프트웨어 SCM 및 SBOM의 중요성을 인식하고 있으며 앞으로 모든 상용 애플리케이션 및 서비스 도입 시 SBOM은 필수 요구 사항으로 제시될 것이다. 이미 활용 중인 애플리케이션으로부터 SBOM을 생성하고 각각의 모듈을 모니터하는 것은 사이버 보안의 중요한 기능으로 여겨지고 있으며, 이는 단지 사용자뿐만 아니라 애플리케이션 공급자에게도 매우 중요한 요소이기도 하다. 자신이 공급하는 애플리케이션과 함께 상세 SBOM을 고객과 공유해야 하기 때문이다. 따라서 사용자든 공급자든 지금부터 당장 SBOM에 대한 준비를 시작해야 한다. SBOM 표준 및 관련 도구에 대해서는 추후 좀 더 상세하게 기술적인 관점에서 살펴보도록 하겠다.
[divide style=”2″]
[box type=”note”]
본 글은 한국지능정보사회진흥원의 지원을 받아 작성되었으며, 디지털서비스 이용지원시스템에 동시 게재합니다.
[/box]
