소프트웨어 자재 명세서(SBOM)란 무엇인가요?

A 소프트웨어 자재 명세서(SBOM)는 소프트웨어 프로젝트에 사용된 구성 요소와 종속성을 상세히 정리한 문서입니다. 또한 소프트웨어에서 사용하는 모든 라이브러리와 프레임워크 및 각각의 버전을 나열합니다. 오픈 소스 소프트웨어(OSS)의 경우 SBOM은 투명성, 보안 및 규정 준수를 보장하는 데 중요한 역할을 할 수 있습니다.

조직에서 SBOM을 사용해야 하는 이유

SBOM을 사용하면, 특히 OSS에서 조직이 구성 요소와 종속성을 파악하고 위험 관리를 개선하는 등 다양한 이점을 얻을 수 있습니다. 아래에서 이러한 이점을 자세히 살펴보겠습니다.

구성 요소 가시성

OSS에는 다양한 타사 구성 요소와 종속성이 포함되는 경우가 많습니다. SBOM을 사용하면 개발자와 사용자가 소프트웨어에 사용된 모든 구성 요소를 명확하게 파악할 수 있습니다. 여기에는 오픈 소스 라이브러리와 프레임워크 및 각각의 구체적인 버전이 포함됩니다. 이러한 가시성은 소프트웨어의 구성을 이해하고, 잠재적인 취약점을 식별하며, 오픈 소스 구성 요소와 관련된 라이선스 의무를 추적하는 데 도움이 됩니다.

취약점 관리

다른 소프트웨어와 마찬가지로 OSS도 보안 취약점에 노출될 수 있습니다. 조직은 SBOM을 통해 오픈 소스 구성 요소의 버전을 추적하고 해당 버전과 관련하여 알려진 취약점을 파악할 수 있습니다. 이를 바탕으로 패치나 업데이트를 신속하게 적용하여 보안 문제를 완화하고 보고하는 등 선제적으로 취약점을 관리할 수 있습니다(참조: RFC8615). 최신 SBOM을 유지하면 조직은 취약점의 영향을 평가하고 소프트웨어 보안을 위한 적절한 조치를 취할 수 있습니다.

공급망 보안

최근 몇 년간 소프트웨어 공급망 보안이 중요한 문제로 대두되었습니다. SBOM은 소프트웨어에 사용된 구성 요소와 그 출처를 투명하게 공개하여 공급망 보안을 강화하는 데 기여합니다. 또한 조직은 이를 통해 사용 중인 구성 요소의 신뢰성과 보안 수준을 평가할 수 있습니다. 조직은 SBOM을 활용하여 손상되거나 악의적인 구성 요소와 관련된 위험을 식별하고 완화함으로써 소프트웨어 공급망 공격의 가능성을 줄일 수 있습니다.

협업 및 패치 관리

OSS는 협업과 커뮤니티 참여를 장려합니다. SBOM은 다양한 기여자와 이해관계자가 소프트웨어 구성 요소를 공통으로 이해할 수 있도록 하여 효과적인 협업을 촉진합니다. 또한 업데이트나 수정이 필요한 구성 요소를 명확히 식별함으로써 패치 관리 작업을 조율하는 데 도움이 됩니다. 모든 참여자가 공유된 SBOM을 참조하여 보안 취약점과 기타 문제를 해결할 수 있으므로 오픈 소스 커뮤니티 내 협업이 더욱 효율적으로 이루어집니다.

규제 준수

일부 산업에서는 규제 체계에 따라 조직이 애플리케이션이나 시스템에 사용되는 소프트웨어 구성 요소에 대한 투명성과 통제력을 입증해야 합니다. SBOM은 이러한 규정 준수 요구 사항을 충족하는 데 필요한 문서를 제공합니다. 이를 통해 조직은 특히 OSS의 보안 및 라이선스 측면에서 실사, 추적 가능성 및 관련 규정 준수를 입증할 수 있습니다.

라이선스 규정 준수

OSS에는 일반적으로 소프트웨어의 사용, 수정 및 배포 방식을 규정하는 특정 라이선스가 적용됩니다. SBOM은 모든 오픈 소스 구성 요소와 해당 라이선스에 대한 포괄적인 정보를 제공합니다. 이를 통해 조직은 사용 중인 OSS의 라이선스 조건을 준수할 수 있습니다. 조직은 라이선스 의무를 파악함으로써 법적 문제나 규정 준수 문제를 방지하면서 소프트웨어의 배포 및 사용에 대해 합리적인 결정을 내릴 수 있습니다.

규제가 엄격한 산업의 SBOM 요구사항

은행 및 의료와 같이 규제가 엄격한 산업의 여러 정부와 조직은 SBOM 사용을 장려하거나, 내부적으로 또는 공급업체에 SBOM 사용을 의무화하는 방안을 검토하고 있습니다.

SBOM을 사용하는 산업 분야의 예

공공 부문 – 미국, 유럽연합, 영국, 그리고 일본은 SBOM을 활용하거나, 사용을 규제 또는 권고하는 여러 국가 중 일부입니다.
기술 – Google, Microsoft, IBM과 같은 대형 기술 기업들은 자체 소프트웨어 개발 프로세스에 SBOM을 도입하고, Software Package Data Exchange(SPDX), OWASP, 그리고 SBOM 생성 도구의 오픈 소스화와 같은 프로젝트에 기여하며 업계를 선도하고 있습니다.
자동차 – 다음과 같은 여러 주요 자동차 기업은 Ford와 General Motors SBOM을 도입하고 있으며, 공급업체에도 자동차 시스템에 사용되는 부품과 소프트웨어에 대한 SBOM을 제공하도록 권장하고 있습니다.
의료 – 미국 시장의 의료기기 제조업체들은 이제 2022년 미국 식품의약국 규정을 준수하기 위해 SBOM을 사용하고 있습니다.

SBOM 팀은 누구로 구성되나요?

SBOM을 구축하려면 소프트웨어 공급망 전반의 다양한 이해관계자가 참여하고 협력해야 합니다. 조직은 이러한 이해관계자의 참여와 상호 협력을 촉진함으로써 소프트웨어 구성 요소에 관한 필수 정보를 담고, 공급망 보안을 강화하며, 위험 관리 및 규정 준수 활동을 지원하는 견고하고 신뢰할 수 있는 SBOM을 구축할 수 있습니다.

이 프로세스에 참여해야 하는 주요 담당자 또는 역할은 다음과 같습니다:

개발팀 – 소프트웨어 엔지니어와 개발자를 포함한 개발팀은 프로젝트에 사용되는 소프트웨어 구성 요소를 식별하고 문서화하는 데 중요한 역할을 합니다. 또한 사용하는 소프트웨어 구성 요소의 종속성, 버전 및 출처에 관한 정확한 정보를 제공할 책임이 있습니다.
프로젝트 관리자 – 프로젝트 관리자는 전반적인 소프트웨어 개발 프로세스를 감독하며 SBOM 구축에 참여해야 합니다. 이들은 개발팀과 협력하여 필요한 정보가 수집되고 SBOM에 문서화되도록 할 수 있습니다. 또한 프로젝트 관리자는 SBOM 요구 사항을 준수하고 이를 프로젝트 워크플로에 통합하는 데 중요한 역할을 합니다.
보안 팀 – 보안 분석가와 전문가를 포함한 보안 팀은 소프트웨어 구성 요소와 관련된 보안 위험을 평가하고 관리하는 데 핵심적인 역할을 합니다. 보안 팀은 SBOM에 나열된 구성 요소와 관련된 취약점 및 알려진 보안 문제에 대한 인사이트를 제공할 수 있습니다. 이들의 전문 지식은 잠재적인 보안 위험을 식별하고 해결 작업의 우선순위를 정하는 데 도움이 됩니다.
조달 팀 – 조달 팀 또는 소프트웨어 구성 요소의 조달을 담당하는 사람은 SBOM을 구축하는 데 중요한 역할을 합니다. 이들은 외부 소스에서 확보한 구성 요소의 출처와 라이선스 세부 정보를 제공할 수 있습니다. 조달 팀과 협력하면 공급망 내 소프트웨어 구성 요소를 정확하게 추적하고 검증할 수 있습니다.
운영 팀 – 운영 팀은 일반적으로 소프트웨어의 배포 및 유지 관리를 담당합니다. SBOM을 작성할 때 운영 팀은 런타임 환경, 배포 구성, 운영 단계에서 추가된 소프트웨어 구성 요소에 관한 유용한 정보를 제공할 수 있습니다. 운영 팀의 전문 지식은 포괄적이고 최신 상태로 유지되는 SBOM을 만드는 데 도움이 됩니다.
법률 및 규정 준수 전문가 – 법률 및 규정 준수 전문가는 특히 라이선스 및 지식 재산권과 관련하여 SBOM을 구축하는 데 필수적인 이해관계자입니다. 이들은 라이선스 규정 준수에 관한 지침을 제공하고 SBOM이 소프트웨어 구성 요소와 관련된 모든 법적 요구 사항이나 제한 사항을 준수하도록 지원할 수 있습니다.
외부 공급업체 및 파트너 – 소프트웨어 프로젝트에 외부 공급업체나 파트너의 구성 요소 또는 서비스가 포함되는 경우, 이들을 SBOM 프로세스에 참여시키는 것이 매우 중요합니다. 이들은 종속성, 버전, 취약점을 비롯해 자사 제품 및 서비스에 관한 필수 정보를 제공할 수 있습니다. 외부 이해관계자와 협력하면 포괄적이고 정확한 SBOM을 작성하는 데 도움이 됩니다.

SBOM 구축 방법

조직은 소프트웨어 구성 요소와 그 출처, 종속성 및 관련 보안 정보를 포괄적으로 파악할 수 있는 SBOM을 구축하는 것을 목표로 해야 합니다. 이를 통해 소프트웨어 공급망 위험을 더욱 효과적으로 관리하고 전반적인 소프트웨어 보안을 강화할 수 있습니다.

SBOM을 구축할 때의 주요 단계는 다음과 같습니다:

구성 요소 식별 및 목록화: 독점 구성 요소와 오픈 소스 구성 요소를 포함하여 프로젝트에 사용되는 모든 소프트웨어 구성 요소를 먼저 식별합니다. 각 구성 요소의 이름, 버전, 출처 등의 정보가 포함된 목록을 작성합니다.
구성 요소의 출처 확인: 각 구성 요소가 독점 소프트웨어인지, 오픈 소스인지 또는 두 가지가 결합된 형태인지 출처를 확인합니다. 이 단계는 구성 요소별로 발생할 수 있는 잠재적인 보안 취약점을 평가하는 데 도움이 됩니다.
종속성 문서화: 사용되는 모든 라이브러리나 프레임워크를 포함하여 구성 요소 간의 종속성을 문서화합니다. 이를 통해 서로 다른 구성 요소 간의 관계를 파악하고 모든 종속성이 빠짐없이 반영되도록 할 수 있습니다.
메타데이터 수집: 라이선스 정보, 알려진 취약점, 릴리스 날짜 등 각 구성 요소의 메타데이터를 수집합니다. 이 정보는 소프트웨어 구성 요소의 보안 및 규정 준수 측면을 추적하는 데 매우 중요합니다.
SBOM 생성 자동화: 프로세스를 간소화하려면 전문 도구를 사용하여 SBOM 생성을 자동화하는 방안을 고려하세요. 이러한 도구는 소프트웨어 프로젝트를 스캔하고 구성 요소를 식별하여 필요한 정보를 자동으로 수집할 수 있습니다.
SBOM을 최신 상태로 유지하세요: 소프트웨어 프로젝트가 발전함에 따라 SBOM을 최신 상태로 유지하는 것이 중요합니다. 변경 사항이 발생할 때마다 인벤토리, 구성 요소 출처, 종속성 및 메타데이터를 정기적으로 검토하고 업데이트하세요.
SBOM 공유 및 활용: 공급업체, 고객, 감사자 등 소프트웨어 공급망의 관련 이해관계자와 SBOM을 공유하세요. 이를 통해 투명성을 높이고, 위험을 더 정확하게 평가하며, 취약점을 식별하고 해결하는 데 도움이 됩니다.
취약점 모니터링 및 관리: SBOM에 포함된 구성 요소와 관련된 새로운 취약점 및 보안 업데이트를 지속적으로 모니터링하세요. 최신 보안 패치 정보를 파악하고 취약점에 신속하게 대응하여 소프트웨어의 보안을 유지하세요.

SBOM이 제 역할을 하지 못하는 7가지 경우

SBOM이 실패하거나 본래의 목적을 충분히 달성하지 못하는 데에는 여러 가지 원인이 있습니다. 이러한 문제를 해결하고 SBOM의 정확성, 완전성 및 최신성을 보장하면 실패 위험을 줄이는 데 도움이 될 수 있습니다.

다음은 SBOM 구축 모범 사례와 맞닿아 있는 몇 가지 일반적인 실패 원인입니다:

불완전하거나 부정확한 인벤토리: SBOM에 프로젝트에서 사용되는 모든 소프트웨어 구성 요소가 정확하게 포함되지 않거나 정보가 불완전하면 소프트웨어 공급망을 파악하는 데 사각지대와 공백이 생길 수 있습니다. 인벤토리가 누락되거나 부정확하면 취약점이나 종속성을 간과하게 되어 SBOM의 효과가 저하될 수 있습니다.
구성 요소 가시성 부족: SBOM이 소프트웨어 구성 요소의 출처, 버전 및 종속성을 명확하게 보여주지 못하면 관련 위험을 효과적으로 평가하고 관리하기가 어려워집니다. 포괄적인 가시성이 없으면 취약점을 추적하고, 패치 업데이트를 파악하며, 라이선스 요구 사항 준수 여부를 확인하기가 어려워집니다.
수동 및 노후화된 프로세스: 수동 프로세스에 의존하여 SBOM을 생성하고 유지 관리하면 비효율성과 오류가 발생할 수 있습니다. 소프트웨어 프로젝트의 변경 사항을 반영하도록 SBOM을 정기적으로 업데이트하지 않으면 빠르게 노후화되어 보안 및 규정 준수를 위한 신뢰할 수 있는 참조 자료로서의 가치를 잃게 됩니다.
불충분한 메타데이터 및 컨텍스트: SBOM은 단순한 소프트웨어 구성 요소 목록을 넘어 라이선스 정보, 알려진 취약점, 릴리스 날짜와 같은 관련 메타데이터를 포함해야 합니다. 이러한 추가 컨텍스트가 누락되거나 불완전하면 위험을 정확하게 평가하고 정보에 입각한 결정을 내리기 어려워집니다.
이해관계자 간 협업 부족: SBOM을 효과적으로 활용하려면 소프트웨어 공급망의 이해관계자 간 협업과 정보 공유가 필수적입니다. 협력이 부족하거나 SBOM 정보 공유를 꺼리면 취약점을 공동으로 식별하고 해결하기 어려워져 소프트웨어의 전반적인 보안이 저해됩니다.
제한적인 도구 및 자동화: SBOM을 수동으로 생성하고 유지 관리하려면 많은 시간이 소요되며 오류가 발생하기 쉽습니다. 적절한 도구와 자동화가 없으면 SBOM을 효율적으로 생성, 업데이트 및 관리하기가 어렵습니다. 또한 자동화가 부족하면 새로운 취약점이나 종속성을 식별하는 작업이 지연될 수 있습니다.
미흡한 취약점 모니터링: SBOM은 강력한 취약점 모니터링 프로세스로 보완되어야 합니다. 소프트웨어 구성 요소와 관련된 새로운 취약점 및 보안 업데이트를 정기적으로 모니터링하지 않으면 잠재적 위험을 발견하지 못해 소프트웨어가 알려진 취약점에 노출될 수 있습니다.

요약

전반적으로 SBOM은 오픈 소스 소프트웨어(OSS)의 복잡성을 관리하는 데 유용한 도구입니다. SBOM은 오픈 소스 생태계 내에서 투명성, 보안, 규정 준수 및 협업을 촉진합니다. 소프트웨어 구성 요소와 해당 버전, 관련 라이선스 정보에 대한 상세한 목록을 제공함으로써 조직이 정보에 기반한 의사 결정을 내리고 위험을 관리하며 소프트웨어 프로젝트의 무결성과 보안을 보장할 수 있도록 지원합니다.