BOM(Software Bill of Material)은 “특정 소프트웨어”에서 활용되는 제3의 소프트웨어 명세서를 뜻한다. 여기서 말하는 “특정 소프트웨어”란 사용자가 직접 설치해 사용하는 전통적인 개념의 패키지 소프트웨어, 프레임워크(Framework) 같은 또 다른 소프트웨어나 서비스를 위해 활용되는 라이브러리 모음, 더 나아가 SaaS(Software as a Service) 형태로 제공되는 서비스 등을 포괄적으로 지칭한다.
물론 리눅스나 윈도 같은 운영체제도 이 범주에 포함된다.최신 소프트웨어 애플리케이션 및 서비스는 일반적으로 여러 구성 요소를 적용해 개발하거나, 또는 제3의 서비스에서 제공되는 기능을 활용해 만들어지며, 오픈소스 활용은 이에 해당하는 가장 대표적인 예라고 말 할 수 있다.
리눅스 재단은 현재 활용되는 최신 소프트웨어 솔루션의 70~80%가 오픈소스로 구성돼 있다고 보고한 바 있다. 또한, API(Application Programming Interface) 호출을 통해 제3자가 제공하는 서비스도 다양하게 활용되고 있는 중이다.
예를 들어 위치정보나 지도, 인증, 결제 서비스 같은 부분들은 직접 개발할 필요 없이 이미 안정적으로 제공되고 있는 서비스를 API 호출을 통해 구현하고 있다. 이 밖에도 프로그래밍 언어 프레임워크 및 소프트웨어 라이브러리도 이 같은 범주에 포함될 수 있다.이처럼 복잡한 개발환경에서 응용프로그램 개발과 관련된 모든 소프트웨어 구성요소 및 종속성을 파악하는 일은 매우 중요하다.
SBOM은 응용프로그램의 구성요소와 모든 종속성을 망라한 인벤토리 정보를 의미한다. 명세서 없이 전자제품을 생산하는 일이 상상하기 조차 힘든 일인 것과 마찬가지다. 실제로 전자제품 생산자의 가장 중요한 책임이자 의무 중 하나는 BOM(자재 명세서)을 정확하게 관리하는 일이다.
하지만 SBOM의 경우는 상황이 조금 다르다. 애플리케이션 또는 서비스 공급업체가 구성요소 및 종속성 정보를 정확하게 제공하는 것이 일반적이지 않기 때문이다. “인벤토리” 정보가 없다는 것은 애플리케이션이 내포하고 있는 잠재 버그와 보안 취약점, 오픈소스 활용과 관련된 라이선스 충돌 등으로 인해 발생할 수 있는 사고를 예방하거나, 사후 대응하기 위한 기본 장치가 안 돼 있다는 뜻이다.
SBOM에는 응용프로그램 개발 시 활용한 오픈소스 코드, 또는 제3자가 개발한 소스코드, 빌드에 포함된 오브젝트, 프로그램 작동을 필요한DLL(동적 링크 라이브러리) 및 미들웨어 목록이 포함돼 있다. 또한 프로그래밍 프레임워크에 대한 의존도 정보도 탑재돼야 한다. 이러한 의존도는, 개발자가 직접 활용한 구성요소뿐만 아니라 각 구성요소 출처에 대한 정보까지 나타내야 한다.
종속성 트리는 애플리케이션 구성요소의 소프트웨어 공급망에 대한 가시성 확보를 위해 필요하다.최근 몇 년 사이 발생한 솔라윈즈(SolarWinds)나, Log4j 등 사고는 소프트웨어 공급망 일부의 보안 침해로 인한 피해가 얼마나 심각한지를 각인시킨 대표적 사례다.
솔라윈즈 침해 사고로 인해 많은 미국 연방 기관과 대기업들이 피해를 입었으며, 마이크로소프트도 이들 중 하나였다. 아파치 소프트웨어 재단에서 개발한 자바(Java) 로깅 프레임워크 Log4j에서 취약점이 발견된 것은 엄청난 파장을 불러일으키기도 했다. 이를 사용하는 수백만 개의 거의 모든 자바 애플리케이션이 보안 침해 영향권에 들어가면서 큰 이슈가 됐었다.
많은 사람들이 솔라윈즈 플랫폼의 보안 취약점과 Log4j의 취약점 문제에 대해 소문으로 알고 있었다고 하지만, 자신이 사용하고 있는 애플리케이션에서 솔라윈즈나 Log4j를 실제 사용하고 있다는 사실을 인지하지 못했다면 당연히 전혀 대응을 못하거나 또는 뒤늦게 알아챈다 하더라도 응대가 매우 더딜 수밖에 없다.
솔라윈즈나 Log4j 침해 사고는 실제로 이같은 상황이 현실로 나타난 사건이다. 두 가지 침해 사건은 SBOM이 사이버 보안에 매우 중요한 역할을 할 수 있다는 것을 단적으로 보여준다.적절한 SBOM을 사용하면 내가 실행하는 응용프로그램 소프트웨어에서 어떤 패키지가 배포됐는지 정확히 알 수 있다.
사용하는 패키지가 무엇이며, 버전까지 확인할 수 있기 때문에 보안을 위해 필요한 업데이트가 적용된 버전인지도 알 수 있다. 이 밖에도 혹시라도 사용하고 있는 패키지 사이에 상호 호환되지 않는 버전이 있다면 이 것도 찾아 낼 수 있으며, 사용권 제약이나, 혹은 오픈소스 라이선스 충돌 여부도 식별할 수 있다.
즉, 사이버 보안 뿐만 아니라 지속 가능한 비즈니스를 저해하는 위험 요소를 최소화할 수 있다는 것이다.
그렇다면 “적절한 SBOM”은 무엇일까? 먼저 인벤토리 정보가 정확하고, 기계가 판독할 수 있는 정형화된 정보가 필요하다. 그 다음 중요한 부분은 실시간 SBOM생성이 가능해야 한다. 데브섹옵스(DevSecOps) 파이프 라인에서 개발/배포가 지속적으로 자동 실행되는 것은 최근 일반화되고 있는 소프트웨어 개발 라이프 사이클이다.
따라서, 자동 배포되는 패키지(이미지)에 대해서 실시간으로 SBOM을 업데이트할 수 있어야만 한다. 특히 배포 이미지에 포함돼 있지 않지만 공통으로 사용되는 동적 라이브러리나 미들웨어, API 등을 인벤토리 목록에서 업데이트 하기 위해서는 실시간 SBOM 생성 및 업데이트가 중요하다.
사용자 PC 같이 엔드포인트(Endpoint)에서 실행되는 소프트웨어도 마찬가지다. 엔드포인트에서 실행되는 소프트웨어 목록뿐만 아니라 각 소프트웨어의 SBOM 관리도 필요하다. 보안팀은 각 엔드포인트의 SBOM을 바탕으로 보안 취약점을 실시간으로 모니터링 할 수 있어야만 한다.
사용중인 소프트웨어의 일부 구성요소에서 취약점이 발견되면 새로운 패치 적용 전에 해당 소프트웨어 실행을 강제로 유보시켜야 하기 때문이다. SBOM은 소프트웨어 공급망 강화를 위해 반드시 구축해야 하는 필수요소가 되고 있다.
아울러 기존 온-프레미스 레거시 소프트웨어는 물론 클라우드 네이티브 애플리케이션의 보안 취약성 대응에도 매우 중요한 요소로 각인되고 있다. 현재 기업과 규제기관을 포함한 전 산업분야에서 SBOM에 대해 엄청난 관심을 나타내고 있다.
예를 들어, 바이든 대통령이 서명한 "국가 사이버 보안 개선"을 위한 행정명령에서 NTIA(국가 정보통신 관리국)는 SBOM에 대해 비교적 상세한 요구사항을 제시한 바 있다. 일반 기업에서도 보안 및 자산 관리를 위해 SBOM을 각별하게 주시하고 있으며, 앞으로 모든 상용 소프트웨어 및 서비스의 필수 요소로 자리매김할 것으로 예상된다.
소프트웨어를 활용하는 고객이든 또는 공급업체이든 지금부터 당장 SBOM에 대한 준비를 갖춰야 할 것이다. 공급업체들은 SBOM을 어떻게 고객과 공유할 수 있는지 나름의 해법을 찾아야 하며, 고객은 이를 최대한 효과적으로 활용할 수 있는 방법에 대해 진지하게 고민해야 한다.