소프트웨어 자재 명세서(SBOM)란?

소프트웨어 자재 명세서(SBOM)는 소프트웨어 프로젝트에 사용되는 구성 요소와 종속성에 대한 세부적인 목록을 제공하는 문서로, 소프트웨어 내에서 사용되는 모든 라이브러리, 프레임워크 및 해당 버전을 나열합니다. 오픈 소스 소프트웨어(OSS)와 관련하여 SBOM은 투명성, 보안 및 규정 준수 보장에 중요한 역할을 할 수 있습니다.

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

특히 OSS에서 SBOM을 사용하면 조직은 구성 요소와 종속성에 대한 가시성을 확보하고 위험 관리 등을 개선할 수 있습니다. 아래에서 이러한 이점에 대해 간략하게 설명합니다.

구성 요소 가시성

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년 Food and Drug Administration 규정을 준수하기 위해 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은 조직이 정보에 기반한 결정을 내리고 위험을 관리하며 소프트웨어 프로젝트의 무결성과 보안을 보장할 수 있도록 지원합니다.