지난 몇 년 동안 사람들은 소프트웨어에 오픈 소스 구성 요소를 사용할 때 내재된 위험에 대해 점점 더 인식하게 되었습니다. 대부분의 소프트웨어가 오픈 소스와 독점 로직이 혼합되어 있다는 점을 고려할 때, 최종 소프트웨어 제품의 적절한 위험 관리를 위해서는 어떤 구성 요소가 외부에서 직접 또는 일시적으로 수입되었는지 아는 것이 필수적입니다. 복잡한 스프레드시트를 사용하여 재료를 추적하던 시대는 지났고 부팅이 비참할 정도로 비효율적이었으므로 이러한 추적을 수행하는 주요 방법은 소프트웨어 BOM(Bill of Materials)을 활용하는 것입니다. 다른 자재 명세서와 마찬가지로 이는 본질적으로 어떤 구성 요소가 서로 종속되어 있는지에 특별히 초점을 맞춘 다양한 구성 요소 간의 관계를 추가하여 소프트웨어를 구성하는 소프트웨어 구성 요소 목록입니다.
오늘날 시장에는 SPDX와 CycloneDX라는 두 가지 주요 SBOM 형식이 사용됩니다.
소프트웨어 패키지 데이터 교환(SPDX) Linux 재단의 기계 판독 가능한 오픈 소스 SBOM 프로젝트입니다. SPDX의 최신 버전은 NTIA의 표준에 맞춰 설계되었습니다.소프트웨어 BOM의 최소 요소.' 여기에는 소프트웨어의 구성 요소, 저작권, 라이센스 및 보안 참조가 나열됩니다.
사이클론DX(CDX) 또한 OWASP(Open Web Application Security Project) 커뮤니티에서 개발한 오픈 소스 및 기계 판독 가능한 SBOM 형식입니다. BOM 형식인 CycloneDX에는 소프트웨어 BOM 준비 이상의 다른 응용 프로그램이 있습니다. 또한 하드웨어 및 클라우드 시스템의 구성요소, 취약점, 서비스를 컴파일하는 데에도 사용할 수 있습니다.
SBOM이 왜 중요한가요?
SBOM은 소프트웨어 개발 팀, 구매 조직 및 최종 사용자에게 매우 유용합니다. 이를 사용하면 오픈 소스 및 타사 구성 요소를 최신 상태로 유지하는 데 도움이 될 수 있으며 소프트웨어에서 악용될 수 있는 알려진 취약점이 있는 프로젝트 종속성에 대한 가시성을 제공할 수 있습니다. 반면, 소프트웨어 구매자는 SBOM을 활용하여 취약성 평가를 통해 제품에 내재된 위험을 분석할 수 있습니다.
조직은 공급업체와 협력하여 시스템 및/또는 제품에 구현되는 프로젝트 구성 요소에 대한 올바른 최신 정보에 액세스할 수 있도록 하면 더 나은 서비스를 받을 수 있습니다. 또한 SBOM을 정기적으로 평가하여 오픈 소스 및 타사 구성 요소 활용에 따른 위험을 최소화해야 합니다.
SBOM 샘플
사용하는 SBOM 형식에 따라 SBOM 구성 요소에 차이가 있을 수 있습니다. 프로젝트의 크기와 복잡성에 따라 SBOM JSON 파일은 수천 줄 이상이 될 수 있습니다. 1000줄짜리 파일을 보는 것은 그다지 유익하지 않으므로 기존의 더 간단한 예를 사용하여 각 SBOM 형식에 무엇이 포함되어 있는지 살펴보겠습니다. 현재 시장에 나와 있는 두 가지 주요 형식의 샘플을 자세히 살펴보겠습니다.
SPDX
우리가 따라갈 SPDX SBOM 샘플을 찾을 수 있습니다. LINK.
JSON은 파일 자체에 대한 일반 정보인 메타데이터로 시작됩니다.
그런 다음 검사 중인 소프트웨어에 대한 메타데이터를 얻습니다.
체크섬과 그 값을 확인하세요. SBOM의 각 섹션에는 문제가 되는 부분의 암호화 및 결과가 포함되어 있어 파일을 검토하는 사람들이 언급된 소프트웨어 또는 구성 요소가 현재 보고 있는 것과 동일하다는 것을 확인할 수 있습니다.
이러한 보증이 없으면 동일한 이름의 구성 요소 또는 소프트웨어를 가진 여러 복사본을 쉽게 찾을 수 있으며 이러한 버전 중 어느 버전이 소프트웨어 또는 이를 설명하는 SBOM에 확인되었거나 포함되었는지 알 수 없습니다.
검사된 소프트웨어에 대한 설명에 따라 구성 요소를 볼 수 있습니다.
구성 요소의 라이센스, 홈페이지, 버전, 전체 이름 등을 설명하기 위해 포함된 여러 필드를 볼 수 있습니다.
SPDX 형식에서 찾을 수 있는 또 다른 사항은 주석입니다. 나중에 섹션에 추가하고 더 많은 정보를 포함하며 때로는 무료 텍스트도 포함합니다.
이 형식과 해당 기능에 대해 자세히 알아보려면 다음을 방문하세요. SPDX 페이지 리눅스 재단의.
사이클론DX
CycloneDX SBOM 형식은 JSON 파일, XML 파일 또는 프로토콜 버퍼에서 설명될 수 있습니다. 일을 균일하고 단순하게 유지하기 위해 단순화된 CycloneDX JSON 예제를 따르겠습니다. 설명된 예를 찾을 수 있습니다. LINK.
JSON은 파일에 대한 일반 메타데이터 정보로 시작됩니다.
그런 다음 소프트웨어의 메타데이터를 조사했습니다.
그 후 소프트웨어 구성 요소 및 해당 종속성은 다음과 같습니다.
이는 단순화된 예이며 형식에 다른 많은 정보가 포함될 수 있다는 점을 명심하세요. 다양한 사용 사례를 보다 포괄적으로 살펴보려면 OWASP CyclonDX 사용 사례 페이지를 확인하세요. LINK.
다음은 종속성 목록 빌드를 보여주는 해당 페이지의 예입니다.
다음은 OWASP에서 가져온 이 형식의 다양한 구성 요소에 대한 보다 포괄적인 설명입니다. BOM 기능 페이지 :
SBOM을 사용하는 방법
여기에 표시된 파일 예제를 따라갈 수 없더라도 걱정하지 마세요. JSON 파일은 사람이 쉽게 읽을 수 있지만 특수 제작된 소프트웨어가 정보를 수집하고 분석이 제공하는 결과를 내보낼 수 있도록 기계가 읽을 수 있는 것이 훨씬 더 적합합니다.
소프트웨어 구성 요소 목록을 사용하여 원치 않는 오픈 소스 라이선스(GPL3.0 또는 MPL1.1 라인)가 포함되어 있지 않은지 확인할 수 있습니다. 종속성 목록을 정기적으로 확인하여 사용 가능한 업데이트가 있는지 확인하거나, 취약성 데이터베이스와 패키지 이름을 비교하여 소프트웨어에 어떤 문제가 있는 종속성이 포함되어 있는지 확인할 수 있습니다.
SBOM을 수집하고 모든 정보를 다시 가져오는 것이 복잡해 보일 수 있지만 모든 작업을 직접 수행할 필요는 없다는 점을 기억하세요. Scribe Security 플랫폼과 같은 서비스는 많은 골칫거리를 제거하고 훨씬 더 많은 이점을 제공할 수 있습니다. 우리의 플랫폼을 확인하고 개발 수명주기 및 최종 제품에 대한 지속적인 모니터링 시스템을 사용하여 위험을 관리할 수 있는 다른 방법을 알아보세요.