소프트웨어 자재 목록(SBOM)이란?

소프트웨어 자재 목록(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을 구현하고 SPDX(Software Package Data Exchange) , OWASP , SBOM 생성 도구의 오픈 소스화 와 같은 프로젝트에 기여하여 선두를 달리고 있습니다.
  • 자동차 – FordGeneral 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은 소프트웨어 구성 요소, 버전, 관련 라이선스 정보에 대한 자세한 인벤토리를 제공함으로써 조직이 정보에 입각한 의사 결정을 내리고, 위험을 관리하고, 소프트웨어 프로젝트의 무결성과 보안을 보장할 수 있도록 지원합니다.