[비개발자의 눈] #5 - Security study : SBOM (Software Bill of Material)이 공급망 보안에서 필요한 이유

최근에 많은 분들이 찾아보는 주제 중 하나는 바로 SBOM입니다. 오픈소스 보안 및 위험을 관리하는 것의 시작이라고 할 수 있고 운영 환경을 위해 필수이며, 리눅스재단은 이번 연도까지 대부분의 기업이 SBOM을 활용할 것이라고 예측하기도 했어요. 이미 몇 년 전부터 다방면으로 그리고 지속적으로 SBOM의 필요성과 중요성이 강조되어 왔답니다.

실제로 오늘날 우리는 많은 부분에서 소프트웨어에 의존하고 있고 이에 따라 보안 위협이 심각해지고 있는 가운데, 이에 대응할 수 있는 방법 중 하나로 SBOM의 활용이 대두되고 있는데요, 그 정의와 등장하게 된 배경 그리고 이점에 대해서 알아봤습니다.

SBOM (Software Bill of Material) 정의

소프트웨어 자재 명세서(SBOM)에 대해서 NTIA(National Telecommunications and Information Administration)는 소프트웨어 구성요소 목록이라고 정의했어요. 포함되는 내용으로는 작성자의 이름, 구성 요소의 이름, 라이선스 정보와 버전 그리고 고유 식별자, 협력 업체 이름 등이 포함된다고 하죠. 주로 표준화된 형식으로 구성 컴포넌트에 관한 메타정보를 의미한다고 소개했습니다.

개인적으로, SBOM을 이해할 때 원산지 표시판을 떠올리니 이해가 쉬웠습니다. 식당을 방문했을 때 쉽게 확인할 수 있는 원산지 표시판은 음식에 들어가는 재료들의 출처를 알 수 있는 리스트인데, 어떤 음식을 먹고 알레르기와 같은 이상 증상이 발생했을 때 이 원산지 리스트를 확인하면서 대응해 볼 수 있어요. 이렇게 식당의 원산지 표시판처럼, SBOM은 소프트웨어에 들어가는 구성 요소들의 출처인 것이죠. 소프트웨어 구성 요소로 인해 어떠한 문제가 발생했을 때 SBOM을 살펴보면서 문제의 원인을 찾고 대응할 수 있는 것이라고 이해할 수 있었습니다.

SBOM (Software Bill of Material) 등장배경

디지털 전환이 가속화되면서 우리 삶에 소프트웨어 역할의 중요성이 커졌습니다. 그런데, 2020년부터 2021년까지 사이버 보안 사건들이 계속하여 발생했죠. 2020년 12월에는 연방정부 조달 솔라윈즈 SW(MS, VMWare관련) 대상 해킹 사건이 발생했고 2021년 5월에는 미국 최대 송유관 기업인 콜로니얼 파이프라인이 SW 랜섬웨어에 감염되면서 남부 지역에 큰 혼란이 찾아왔습니다.

사이버 보안 사건이 연달아 발생하는 가운데, 오픈소스 소프트웨어는 더욱 활성화되었고 재사용이 증가하는 것을 원인으로 소프트웨어 패키지가 컴포넌트들로 구성되면서 리스트 관리의 필요성이 대두되었습니다. 특히 오픈소스 중심으로 소프트웨어가 개발 · 운영되면서 소프트웨어 컴포넌트 관리 매우 중요해졌습니다. 뿐만 아니라 최근 무기 체계와 에너지, 통신과 교통 등 사회 기반 시설에도 소프트웨어를 사용하면서 국가 안보를 위해 소프트웨어 공급망의 투명성을 확보해야 한다는 목소리가 커졌어요.

이에 미국에서는 2021년 5월 12일에 국가 사이버 보안 개선에 대한 대통령 행정 명령 (EO) 14028을 발표했습니다. 소프트웨어 공급망의 보안 및 무결성과 관련된 다양한 이니셔티브를 통해 사이버 보안이 강화되도록 여러 기관에 청구한 것인데요, 이 행정 명령의 Section 4에서는 소프트웨어 보안을 평가하는 기준, 개발자 및 공급업체의 보안 관행을 평가하는 기준, 보안 관행 준수를 입증하는 혁신적 도구 또는 방법을 식별하도록 지시했습니다. 이에 따라 NTIA (국가 정보통신 관리국)는 SBOM과 관련하여 상세한 요구 사항을 제시했고요, 일반 기업에서도 SBOM의 중요성을 인식하면서 필수 요구 사항으로 제시될 것이라는 전망이 있습니다. 행정 명령 14028의 선례에 따라서 보안 및 규정 준수와 관련된 팀은 소프트웨어 프로젝트의 오픈소스 구성 요소를 식별하고 새로운 위협에 대한 취약성을 평가하며 라이선스 정책 일치 여부를 확인하기 위해 SBOM을 점점 더 많이 요청하고 있다는 것이죠.

SBOM (Software Bill of Material) 형식

시간이 흐르면서 다양한 그룹에서 SBOM에 대한 다른 형식들을 만들었고 모두 각기 다른 장점과 단점을 가지고 있습니다. 가장 많이 쓰이는 SBOM 형식은 SPDX(Software Package Data Exchange) 그리고 사이클론DX(CycloneDX)입니다.

SPDX(Software Package Data Exchange)

SPDX는 리눅스 재단에서 운영하는 프로젝트로, 개발 당시에는 소프트웨어 패키지와 관련된 정보에 대해 공통 데이터 교환 포맷을 만드는 것이 목적이었습니다. 다른 주요 SBOM 포맷 중에서도 가장 많은 파일 형식을 지원하는데 RDFa, .xlsx, .spdx, .xml, .json, .yaml.가 포함됩니다.

국제 표준화 기구(ISO)의 인증 자격을 취득한 유일한 SBOM 포맷인 SPDX는 하위 버전인 SPDX 라이트(Lite) 프로파일을 제공하고 있습니다. 오픈소스 라이선스에 대한 지식이나 경험이 없는 사람들도 쉽게 사용할 수 있도록 하며 일부 산업에서 SPDX 표준과 실제 워크플로우 간의 균형을 유지할 수 있도록 하는 것이 목적입니다.

사이클론 DX(CycloneDX)

국제 웹 보안 표준 기구 (Open Web Application Security Project, OWASP)가 주도하는 사이클론 DX의 프로젝트 기능 중 하나가 SBOM 지원입니다. 자체적으로는 애플리케이션 보안 컨텍스트 및 공급망 구성 요소 분석에 사용하도록 설계된 경량 SBOM 표준이라고 정의하고 있습니다.

처음부터 BOM 형식으로 설계되었다는 것이 큰 특징으로, SaaS BOM(software-as-a-service BOM)을 포함한 다양한 사용 사례를 제공합니다.

SBOM (Software Bill of Material) 이점

리눅스 재단은 SBOM이 오픈소스 생태계 전반의 사이버 보안을 개선하는 데에 미치는 중요성에 대한 연부 보고를 발표했습니다. SBOM을 생성할 때 얻을 수 있는 주요 이점 세 가지에 대한 답변으로 애플리케이션 구성 요소 간 의존성(dependency)에 대한 쉽고 빠른 파악이 51%, 구성 요소의 취약점 모니터링 용이성이 49%, 라이선스 컴플라이언스 관리 용이성이 44%의 비율을 차지했습니다. SBOM을 사용함으로써 얻을 수 있는 주요 이점 세 가지는 무엇인가에 대한 질문에서는 컴플라이언스 및 보고 요구사항을 보다 효과적으로 지원(53%)한다는 점과 위험 기반 의사결정을 가능하게 하는 정보를 제공(53%)한다는 점이 가장 큰 이점이라고 답했으며, 라이선스 컴플라이언스 관리 용이(44%)와 취약점에 대한 신속한 파악(49%)이 뒤를 이었습니다.

이어서 리눅스 재단은 23년까지 88% 이상의 조직에서 SBOM을 생성 또는 사용할 것으로 예상하며, SBOM은 소프트웨어의 보안 취약점, 출처 및 계보, 라이선스 의무 등의 요구사항을 효과적으로 해결하기 때문에 대부분의 조직에서 SBOM을 적극적으로 활용하고 있다고 보고했습니다.

SBOM은 알려진 취약점 식별 및 취약점에 대한 완화 관리가 가능하며 보안 및 라이선스 규정 준수 요구사항을 식별하는 것이 용이합니다. 구체적으로, 주어진 구성 요소에서 결함이나 취약성이 발견되었을 때 SBOM을 사용해 취약한 구성 요소의 영향을 받는 소프트웨어를 신속히 확인할 수 있습니다. SBOM을 사용하면 취약성 관리 외에도 조달부터 운영까지 조직의 많은 부분에서 가시성을 확보할 수 있습니다. 새로운 정책 및 규정의 영향 검토, 라이선스 명확성과 같은 부분이 그 예입니다.

소프트웨어 공급망 보안에 대한 자동화 솔루션을 제공하는 대표 기업 Sonatype은 CycloneDX SBOM 사양 및 개발에 적극적으로 참여하고 있습니다. Sonatype Lifecycle은 CLI, API 및 UI를 사용하여 2019년부터 SBOM 스캐닝을 지원하기 시작하며, 모든 애플리케이션 스캔 보고서를 CycloneDX SBOM으로 내보낼 수 있습니다.

Sonatype은 세 단계로 애플리케이션 분석을 진행합니다. (1) 빌드하는 동안 애플리케이션에 들어가는 모든 구성 요소 분석 (2) 발견된 구성 요소의 ID 및 취약성 데이터 수집 (3) 해당 데이터를 거버넌스 정책과 비교해 보고서 생성

이때 발생할 수 있는 문제는 빌드 프로세스 중, 항상 분석을 수행할 수 없고 빌드 전 혹은 후에 애플리케이션을 스캔하고자 할 땐 불완전한 결과가 나올 수 있다는 것입니다. 이러한 문제를 Sonatype은 분석에 SBOM을 사용하거나 포함해 스캔 결과를 개선하면서 해결했습니다.

Sonatype은 애플리케이션을 구축할 때 패키징된 바이너리와 함께 SBOM을 생성 및 저장하여 최종 애플리케이션에 무엇이 포함되어 있는지 정확히 식별해야 하며, 배포 단계 전, 응용 프로그램을 분석해 심각한 취약성이 프로덕션 환경에 영향을 주지 않도록 해야 한다고 권고했습니다.

Sonatype에 대한 소개는 여기에서 살펴볼 수 있으며, 웨비나 영상을 통해 제품 소개 및 Demo를 확인하실 수 있습니다.