2023.04.27 11:30 (수정 : 2023.04.28 13:20)
|
|
[2023-04] 디지털서비스 이슈리포트 03 SBOM 구현을 위한 개방형 표준 | |
---|---|
03 SBOM 구현을 위한 개방형 표준 │윤대균 아주대학교 교수 1. SBOM 개요 SBOM(Software Bill Of Materials)은 최종 배포/활용되는 소프트웨어를 구성하는 모든 컴포넌트 명세서를 말한다. 최종 “소프트웨어”의 사용자가 누구냐에 따라 그 규모와 활용 형태는 천차만별이다. 수억 명 이상이 쓰는 서비스, 기업용으로 SaaS 형태의 서비스, 개별 장치에 직접 설치해 쓰는 수많은 애플리케이션이 여기에 포함된다. 사용자가 “개발자”일 경우, 최종 제품 개발을 위해 활용하는 제3자가 제공하는 라이브러리나 프레임워크 등도 “소프트웨어” 범주에 포함된다. 이러한 각 “소프트웨어”를 구성하는 또 다른 모든 “소프트웨어”의 목록 및 이력을 기록한 것이 SBOM이다. 최종 제품으로서 소프트웨어가 일반 제품처럼 다양한 부품으로 이루어져 있는 것과 같은 개념으로 소프트웨어 공급망 관리(Software SCM)의 일환으로 다뤄지기도 한다. 전체 소프트웨어를 구성하는 수많은 제3의 소프트웨어 중 하나만 해킹당해도 전체 소프트웨어의 보안에 구멍이 뚫리기 때문에 모든 구성 소프트웨어의 무결성이 매우 중요하다. 반대로 해커는 이렇게 겉으로 드러나지 않는 제3의 소프트웨어를 해킹함으로써 이를 활용하는 수많은 소프트웨어를 동시에 공격할 수 있다. 이에, 사이버 보안 분야에서 SBOM이 큰 주목을 받고 있다. 특히 클라우드 컴퓨팅이 일반화되며 데브옵스(DevOps), 마이크로서비스, 컨테이너와 같은 클라우드에 최적화된 개발 방식에서 소프트웨어 SCM은 더욱 중요하게 여겨지고 있다. 관련 내용은 이전 리포트에서 다룬 바 있다. 앞으로 대부분 상용 애플리케이션 및 서비스 도입 시 SBOM은 필수 요구사항으로 제시될 것으로 전망되며, 이미 활용 중인 애플리케이션에 대해서도 SBOM을 생성하여 이 안에 포함된 각 모듈을 상시 모니터하는 것은 사이버 보안에서의 중요한 한 축이 될 것이다. 따라서 사용자든 공급자든 SBOM에 대한 준비가 필요하다. SBOM은 미국 정부의 사이버 보안 개선을 위해 매우 중요한 요소로 여겨지고 있으며 정보통신국(NTIA)을 통해 상세히 소개하고 있다. NTIAsms SBOM 표준 관련 상세한 조사연구 자료를 발간하기도 했다. 2. SBOM 표준 포맷 SBOM에 들어가는 정보는 소프트웨어 라이프사이클의 각 단계에서 사용되는 프로세스와 도구를 통해 생성할 수 있다(그림16). 여기서 말하는 라이프사이클은 일반적인 소프트웨어 개발 사이클뿐만 아니라 관련 구매/조달, 인증/승인 과정, 그리고 소프트웨어를 공급받은 사용자의 운영도 포함하고 있다. 지식재산권 검토, 조달 검토 및 라이선스 관리 워크플로우 도구, 소프트웨어 공급망 위험 관리, 코드 스캐너, 전처리기, 코드 생성기, 소스 코드 관리 시스템, 바이너리 코드 분석 도구, 버전 관리 시스템, 컴파일러/빌드 도구, 지속적 통합/패키징, 규정 준수 테스트, 패키지 배포, 그리고 앱 스토어 등록 등 전 과정에서 SBOM에 수록될 정보를 생성하거나 수정할 수 있다. 그림 1 소프트웨어 라이프사이클 각 단계에서의 코드 변경 및 이에 따른 SBOM 업데이트 [ 출처: NTIA 서베이 보고서] 위 그림에서 소프트웨어 패키지 결과물은 “+”로 표시된 부분, 그리고 생성되는 메타 정보는 “>”로 표시한 부분이다. “>”로 표시한 메타 정보가 이 라이프사이클을 통해 만들어지는 SBOM을 구성하는 정보이다. 추가로 제3의 패키지 혹은 라이브러리가 빌드/통합 과정에서 사용되면 해당 제3의 소프트웨어에 대한 명세서(BOM)도 필요하다. 이 경우 “→”로 표시한 레퍼런스 정보를 생성한다. 단계별 생성되는 메타 정보의 성격도 다양한데, 예를 들어 빌드 단계에서는 컴파일러에 대한 레퍼런스 정보, 테스트 단계에서는 각종 인증 정보가 생성되며, 최종 배포 또는 사용자 설치 단계에서는 공급자 정보, 제품명, 버전, 적용 라이선스, 고유 아이디, 디지털 서명 등을 생성한다. 설치 운영 중 유지보수 단계에서는 소프트웨어의 잠재 혹은 이미 확인한 위험 요소에 대해 기록할 수도 있다. 예를 들면 “CVE-nnnn” 형태의 공통 취약점 노출 정보(Common Vulnerabilities and Exposure)를 기록함으로써 추후 전체 시스템을 안전하게 관리하는 데 도움을 줄 수 있다. 가장 널리 알려진 세 가지의 대표적인 SBOM 포맷은 SPDX(Software Package Data Exchange), CycloneDX, 그리고 SWID(Software Identification)이다. 2.1 SPDX(Software Package Data Exchange) SPDX는 SBOM을 교환하기 위한 개방형 표준으로 소프트웨어 개발, 보안, 소프트웨어 SCM 커뮤니티의 업계 전문가들이 협력하는 SPDX 오픈소스 프로젝트이다. 리눅스 파운데이션에 지원하는 가장 오랫동안 발전해온 SBOM 형식이며 다양한 도구와 소프트웨어 개발 환경을 지원하는 국제 개방형 표준이다(ISO/IEC 5962:2021). 마이크로소프트, 인텔, 구글, SAP 등 주요 기업들이 지원하고 있다. 그림 2 SPDX 서포터 [그림 출처: spdx.dev] SPDX 정보는 최종 소프트웨어 제품, 컴포넌트, 혹은 여러 컴포넌트의 집합, 개별 파일, 심지어 코드 스니펫과도 연관될 수 있다. 즉, 활용할 수 있는 가능한 형태의 모든 소프트웨어에 대해 SBOM 정보를 생성해 서로 교환할 수 있게 한 것이다. 파일 형식도, XML, RDF, XLSX, JSON, YAML 등 여러 타입을 활용할 수 있다. SPDX 사양의 특징은 사람이 읽을 수 있으면서 기계도 판독할 수 있다는 것이다. 2023년 4월 현재 SPDX 버전 2.3까지 나와 있으며 다른 어떤 표준보다도 소프트웨어와 연관된 매우 포괄적인 정보를 담은 사양을 정의하고 있다. SPDX 문서는 다음과 같은 정보로 구성된다.
새로운 유즈케이스가 계속 나오면서 SPDX는 진화를 거듭하고 있다. 위에서 살펴본 바와 같이 매우 포괄적이며 가능한 많은 경우를 수용할 수 있도록 설계했다. 또한, 생성 및 분석 자동화가 가능하도록 다양한 표현 언어를 지원한다. SPDX의 강점인 포괄성과 유연성이 한편으로는 이를 신속하게 도입하는 데에는 걸림돌이 되기도 한다. 이에 좀 더 보안 및 규정 준수(compliance)에 초점을 맞춰 설계된 CycloneDX가 등장했다. 2.2 CycloneDX CycloneDX는 사이버 보안을 위한 소프트웨어 공급망 구성 요소 분석에 사용하도록 설계한 SBOM 사양이다. 소프트웨어를 구성하는 컴포넌트 인벤토리 정보, 외부 서비스, 그리고 이들 간의 관계를 명시함으로써, “풀-스택(Full-Stack)” SBOM을 지향한다. 소프트웨어 보안, 특히 웹 애플리케이션 보안 강화를 위해 설립된 OWASP(Open Web Application Security Project)의 오픈소스 프로젝트이다. 이 사양은 다음과 같은 유즈케이스를 지원한다.
소프트웨어 보안을 주목적으로 설계되었기 때문에 SPDX보다 상대적으로 가볍고 유즈케이스가 매우 명확한 편이다. 이에 많은 기업과 프로젝트가 CycloneDX의 프로젝트를 지원하고 있다. SPDX를 지원하는 대부분 주요 기업이 CycloneDX를 지원하고 있으며, 깃랩, 깃헙, 레드햇, CNCF(Cloud Natvie Computing Foundation) 등 오픈소스 진영의 전폭적인 지지를 받고 있다. (그림18) 그림 3 CycloneDX 서포터 [그림 출처: cyclonedx.org] CycloneDX BOM은 다음과 같은 정보로 구성된다.
CycloneDX 오브젝트 모델은 JSON, XML, 프로토콜 버퍼로 정의하고 있다. 따라서 CycloneDX 생성 또는 분석하려는 조직에서는 이 셋 중 자신들에게 가장 적합한 형식을 활용하면 된다. JSON이나 XML과 같이 널리 사용되는 기술에 기반하기 때문에, 관련 도구도 매우 풍부하다. 2023년 4월 현재 CycloneDX 공식 사이트에 191개의 도구가 소개되어 있다. 2.3 SWID(Software Identification) SWID는 OASIS(Organization for the Advancement of Structured Information Standards)의 ISO/IEC (19770-2:2015) 표준으로 정의한 소프트웨어 식별정보이다. 소프트웨어 컴포넌트의 라이프사이클에 따라 네 가지 타입의 SWID 태그를 정의하고 있다.
SWID 태그 활용은 SBOM에서 소프트웨어 구성 정보 및 이력 관리를 위해 매우 중요하다. CycloneDX의 컴포넌트 정보에도 SWID 태그는 필수 정보로 포함되는 이유이다. 3. SBOM 표준 선택 기준 SPDX, CycloneDX, SWID는 모두 소프트웨어 자재 명세서(SBOM) 정보 교환을 위한 개방형 표준이다. 모두 고유한 장단점이 있으므로 원론적으로는 특정 요구사항에 따라 가장 적합한 표준을 선택해야 한다. 몇 가지 기준으로 이들을 비교 나열한다면 다음과 같다. 물론 이는 필자의 개인적인 의견이다.
그렇다면 “새로 SBOM을 구현하려 하는데 세 가지 표준 중 무엇을 사용하는 것이 좋겠는가?”라는 질문의 가장 바람직한 답은 무엇일까? 누구나 원론적으로 내릴 수 있는 답인 “요구사항을 명확하게 정의하고 이에 맞는 표준을 사용해야 한다.” 말고 좀 더 현실적인 제안은 할 수 없을까? 만일 한 기업이 SBOM 도입을 적극적으로 검토하고 있다면 필자의 생각엔 아마도 90% 이상 소프트웨어 보안 강화를 목적으로 할 것이다. 따라서 이 경우라면 우선 CycloneDX를 검토해 보는 것이 현실적이다. CycloneDX의 오브젝트 모델은 앞서 설명한 것처럼 가장 많이 쓰는 기술(JSON, XML) 기반으로 만들어져 있으며, 따라서 활용할 수 있는 도구의 선택폭도 넓다. 상용 도구를 사용하는 경우 비용 지출이 있을 수 있으나 결과물인 SBOM 자체는 개방형 표준이기 때문에, 이를 어떻게 활용하든 제약이 거의 없다는 것도 주요 장점이다. 다수의 보안 전문 회사 중 선택해야 한다면 이들 회사에서 지원하는 SBOM 사양을 상세하게 검토하여 가능한 개방형 표준 범위에서 충분히 지원 가능한가를 살펴보는 것이 중요하다. 솔루션/서비스 벤더가 내세우는 차별화 포인트가 개방형 표준을 조금이라도 벗어난다면 이런 차별화 포인트가 회사의 요구사항 충족을 위한 핵심 요건인지 아닌지를 잘 따져보고 결정해야 한다. 가능한 특정 솔루션에 종속되지 않도록 개방형 표준에 기반을 둔 SBOM 호환성을 최우선 요구 조건으로 하는 전략이 중장기적으로는 바람직하다. 참고문헌 1) 디지털서비스 이슈리포트, “클라우드 네이티브 보안을 위한 SBOM”, 2023년 2월 2) https://ntia.gov/page/software-bill-materials 3) NTIA, “Survey of Existing SBOM Formats and Standards”, 2021년 4) https://spdx.dev/ 5) https://cyclonedx.org/tool-center/
이슈리포트 2023-04호.pdf (2 MB)
|