최근 미국 시장에서는 소프트웨어 물자표(SBOM)를 도입하기 위한 바람이 불고 있다. 아직 구상 단계라 구체적인 문건이나 표준이 정립되지는 않았지만 공급망 공격에 대한 안전 장치로서 각광 받고 있는 건 사실이다. 10월 한국에서 열린 보안 행사 ISEC 2022를 방문한 시높시스의 솔루션 전문가 필립 이반치치 씨와의 인터뷰를 칼럼 형식으로 재구성한다.

[보안뉴스 문가용 기자] 서드파티 라이브러리나 도구, 그 중에서도 오픈소스를 사용하지 않는 기업이나 개발자는 단언컨데 하나도 없다. 최근 보안 업체 시높시스(Synopsys)에서 발표한 ‘글로벌 오픈소스 보안 리스크 보고서(Global OSSRA Report)’에 의하면 97%의 코드베이스에 오픈소스가 포함되어 있다고 할 정도니 말이다. 이런 오픈소스의 적극적인 활용 덕분에 소프트웨어의 개발은 더 빠르고, 더 효율적인 것으로 변했다.


[이미지 = utoimage]

문제는 속도와 효율성이 높아진만큼 리스크 수준도 높아졌다는 것이다. 위에 언급한 글로벌 OSSRA 보고서를 통해 현대 코드베이스의 81%에 적어도 한 개 이상의 취약점이 있다는 사실 역시 밝혀졌다. 그 어느 때보다 빠르게 소프트웨어가 만들어지지만, 그 어느 때보다 취약점이 널리 분포되어 있다고 해도 과언이 아니다. 그래서 최근 도입이 적극 검토되는 것이 SBOM, 즉 소프트웨어 물자표(Software Bill of Material)라는 것이다.

SBOM이란 무엇인가?
SBOM은 복잡한 소프트웨어 공급망을 보호하는 데에 있어 효과적인 전략이다. 좋아하는 식료품을 살 때 어떠한 재료로 만들어져 있는지 구매 전에 직접 보고 확인할 수 있는 것처럼, 소프트웨어 애플리케이션의 구성 요소들을 전부 확인할 수 있게 해 주는 것이 SBOM이기 때문이다. 공급망에 어떤 재료들이 개입되는지 확인할 수 있으니, 공급망 공격의 위험성이 크게 줄어든다.

따라서 SBOM에는 여러 가지 정보가 포함되어 있다. 라이브러리, 코드 패키지, 서드파티 구성 요소 등 한 소프트웨어에 들어가 있는 모든 것들이 명시되어야 제 기능을 발휘할 수 있는 것도 사실이고 말이다. 주로 다음과 같은 정보들이 있다고 볼 수 있다.
 - 각 구성 요소의 라이선스 유형(공유, 오픈소스, 상업용 등)
 - 각 구성 요소의 버전 정보
 - 패치 상태
 - 각 구성 요소들 간 디펜던시 관계

SBOM은 보안의 관점에서만 중요한 것이 아니다. 데이터 프라이버시라는 측면에서도, 그리고 그 데이터 프라이버시를 보호하기 위한 규정을 준수한다는 면에 있어서도 중요하다. 그렇기 때문에 미국에서의 경우 여러 연방 정부 기관과 심지어 백악관까지 나서서 바로 이 SBOM에 대한 이야기를 자꾸만 꺼내는 것이다. 통신정보관리청의 경우 SBOM 생성에 있어 세 가지 형태 중 하나를 지켜달라고 권장하고 있다.

1) 소프트웨어 패키지 데이터 익스체인지(SPDX) : SBOM 생성을 위한 개방형 표준이다. 소프트웨어 구성 요소들과 각각의 라이선스 정보, 저작권 정보, 보안 참조 사항들을 포함하도록 되어 있다.

2) OWASP 사이클론DX(OWASP CycloneDX) : 조금 더 가벼운 형태의 SBOM 표준으로, 리스크 분석에 필요한 소프트웨어 구성 요소들을 전부 망라하도록 되어 있다. 구성 요소들의 유형(애플리케이션, 컨테이너, 라이브러리, 파일, 펌웨어, 프레임워크, OS 등)을 분류하도록 되어 있는 것이 특징이다.

3) 소프트웨어 식별 표준(SWID) : 국제표준화기구(ISO)와 국제전기표준회의(IEC)에서 개발한 것으로 최종적으로는 XML 파일 형태로 SBOM이 제작된다. 소프트웨어 구성 요소들과 라이선스 정보, 패치 상태, 설치 번들 정보 등이 포함된다.

왜 SBOM이 중요한가?
소프트웨어 공급망을 보호하려면 SBOM이 필요하다. 소프트웨어 공급망이란, 애플리케이션을 개발하는 데 필요한 모든 도구, 프레임워크, 라이브러리를 일컫는다. 소프트웨어 개발자들과 개발사들은 한 번 썼던 코드와 소프트웨어 패키지, 라이브러리를 굉장히 많이 재활용하는데, 그렇기 때문에 이런 요소들을 하나하나 보호하지 않는다면 언제 어느 틈에 취약점이 생기게 될 지 알 수도 없고 예상도 할 수 없다. 이 때문에 51%의 조직들이 오픈소스 소프트웨어와 소프트웨어 공급망을 안전하게 관리하고자 하는 노력을 강화하고 있기도 하다. 그러면서 SBOM에 대한 인지도가 빠르게 올라가는 중이다. 하지만 온전한 가시성을 확보한 기업은 거의 없다.

SBOM을 사용했을 때 얻을 수 있는 이점을 정리하면 다음과 같다.
 - 취약한 소프트웨어 구성 요소를 반복해서 사용하는 일이 없어진다.
 - 현재 사용되고 있는 애플리케이션들의 취약점을 해결할 수 있게 된다.
 - 소프트웨어 공급망을 통해 발생하는 위험 요소들을 보다 잘 관리할 수 있게 된다.
 - 소프트웨어 자체의 생태계와 디펜던시 등 구성 요소들 간 복잡한 관계를 보다 잘 이해할 수 있게 된다.
 - 점점 더 복잡해지는 데이터 관련 규정들을 보다 효과적으로 준수할 수 있게 된다.
 - SBOM을 살펴봄으로써 보다 안정적으로 소프트웨어를 관리하는 벤더사를 찾을 수 있다.
 - 취약점 발견과 해결에 들어가는 시간과 자원이 줄어든다.
 - 소프트웨어 공급망과 관련된 위험 상황이 발생했을 때 빠르게 소식을 전파해 대처할 수 있다.

SBOM, 어떻게 만드나?
SBOM을 만드는 방법은 여러 가지다. 개개인이 수동으로 작성할 수도 있고, 자동화 기술을 활용할 수도 있다. 하지만 현대 소프트웨어 애플리케이션들의 복잡한 구조를 생각했을 때 수기 작성법은 그리 권장되지 않는다. 하지만 덩치가 작은 프로젝트를 진행하고, 구성 요소의 수가 적다면 자동화 기술을 도입하는 것보다는 손으로 직접 목록을 작성하는 게 나을 수 있다. 이것은 상황에 따라 각 조직이나 개발자가 정해야 한다.

SBOM 작성에 도움이 되는 자동화 기술들은 시장에 이미 여러 개 나와 있다. 디펜던시를 전부 스캔하게 해 주는 제품들도 있고 오픈소스 리스크를 총체적으로 관리하게 해 주는 블랙덕(Black Duck) 같은 솔루션들도 인기가 높다. 블랙덕의 경우 최근 소프트웨어 개발 및 출시의 중요한 덕목인 CI / CD와도 궁합이 좋다. 자동으로 소프트웨어 구성 요소들을 스캔하고, 상업 요소들과 오픈소스 요소들을 구분해 내며, 데브옵스에도 부드럽게 통합된다.

SBOM은 여러 가지 측면에서 도움이 될 제도이자 장치가 될 것으로 예상된다. 우리가 사용하고 있는 소프트웨어들은 매우 복잡하게 구성되어 있고 점점 더 복잡해져 가는데, 언제까지 아무 것도 모른 채 사용할 수는 없는 노릇이다. SBOM이 아니더라도 언젠가는 비슷한 것이 나와 소프트웨어 생태계에 대한 가시성 확보의 중요성이 강조될 것이다. SBOM은 찬성과 반대의 주제로 접근할 것이 아니라, 어떻게 해야 더 효과적으로 구현할 것인지를 논해야 할 주제다.

글 : 필립 이반치치(Philip Ivancic), 솔루션 책임, Synopsys
[국제부 문가용 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>