SBOM
라이언의 꿀팁백과
1 정의[편집 | 원본 편집]
A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product. It is analogous to a list of ingredients on food packaging: where you might consult a label to avoid foods that may cause an allergies, SBOMs can help organizations or persons avoid consumption of software that could harm them. (링크 : 위키피디아)
SBOM은 소프트웨어 재료명세서(BOM ; Bill of Materials) 혹은 소프트웨어 재료표(Software Bill of Materials)의 약칭이다. BOM은 제조 부문에서 유래된 개념으로, 특정 장치의 제작에 사용된 구성요소와 재료를 낱낱이 파악하는 데 중요한 역할을 한다. 가령, 기차의 엔진에 사용된 부품이 일정 수준의 진동에 적합한 등급을 못한 경우, 특정 선로를 달리기가 부적합할 수 있다. BOM은 이 같은 상황에서 진가를 발휘하며 SBOM 또한 마찬가지다. SBOM을 통해 특정 소프트웨어에 사용된 전용, 오픈소스 그리고 라이선스 요소에 만료되거나 불안정한 요소가 없는지 검토할 수 있다. (링크 : CIO)
SBOM은 소프트웨어를 구성하는 여러 구성요소의 목록을 일목요연하게 정리하는 것으로, 소프트웨어 구매자와 공급자 간에 제품의 최신 내역 정보를 공유함으로써 완성된 솔루션을 원활히 관리하게 해준다. 소프트웨어의 구성요소를 파악하기 쉽게 함으로써 문제 발생 시 취약점을 손쉽게 파악하고, 관리 위험을 줄이게 해준다.
2 고려사항[편집 | 원본 편집]
오늘날에는 애플리케이션을 배포하기 전 취약점을 검사하는 것이 관행이다. 하지만 이런 검사만으로 충분하지 않다. 앱 구성 요소를 점검하고 취약점을 감지하는 활동은 앱 사용 중에도 정기적으로 실행해야 하는 것이지 한 번으로 끝낼 수 있는 것이 아니다. 모든 앱 점검 결과는 반드시 기록 및 분석해야 한다. 일시적인 점검을 연속 시스템으로 전환하기 위해서는 툴링(tooling)과 자동화가 중요하다.
3 해외사례[편집 | 원본 편집]
2021년 5월, 미국 사이버보안 개선에 관한 행정 명령에 따르면, 소프트웨어 서비스 업체는 미국 연방 기관에 판매하거나 제공하는 소프트웨어에 대한 SBOM을 제출해야 한다. (링크 : CIO)
4 관련 표준[편집 | 원본 편집]
The Software Package Data Exchange (SPDX) 라는 게 있는데 ISO/IEC 5962:2021 표준이다.
SPDX is an open standard for communicating software bill of material information, including provenance, license, security, and other related information. SPDX reduces redundant work by providing common formats for organizations and communities to share important data, thereby streamlining and improving compliance, security, and dependability. The SPDX specification is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.
5 관련 기사[편집 | 원본 편집]
[주말판] 소프트웨어 물자표(SBOM), 공급망 공격 안전장치로 주목 (보안뉴스, 링크)
SBOM에는 여러 가지 정보가 포함되어 있다. 라이브러리, 코드 패키지, 서드파티 구성 요소 등 한 소프트웨어에 들어가 있는 모든 것들이 명시되어야 제 기능을 발휘할 수 있는 것도 사실이고 말이다. 주로 다음과 같은 정보들이 있다고 볼 수 있다.
- 각 구성 요소의 라이선스 유형(공유, 오픈소스, 상업용 등)
- 각 구성 요소의 버전 정보
- 패치 상태
- 각 구성 요소들 간 디펜던시 관계
SBOM은 보안의 관점에서만 중요한 것이 아니다. 데이터 프라이버시라는 측면에서도, 그리고 그 데이터 프라이버시를 보호하기 위한 규정을 준수한다는 면에 있어서도 중요하다. 그렇기 때문에 미국에서의 경우 여러 연방 정부 기관과 심지어 백악관까지 나서서 바로 이 SBOM에 대한 이야기를 자꾸만 꺼내는 것이다. 통신정보관리청의 경우 SBOM 생성에 있어 세 가지 형태 중 하나를 지켜달라고 권장하고 있다.
1) 소프트웨어 패키지 데이터 익스체인지(SPDX) : SBOM 생성을 위한 개방형 표준이다. 소프트웨어 구성 요소들과 각각의 라이선스 정보, 저작권 정보, 보안 참조 사항들을 포함하도록 되어 있다.2) OWASP 사이클론DX(OWASP CycloneDX) : 조금 더 가벼운 형태의 SBOM 표준으로, 리스크 분석에 필요한 소프트웨어 구성 요소들을 전부 망라하도록 되어 있다. 구성 요소들의 유형(애플리케이션, 컨테이너, 라이브러리, 파일, 펌웨어, 프레임워크, OS 등)을 분류하도록 되어 있는 것이 특징이다.
3) 소프트웨어 식별 표준(SWID) : 국제표준화기구(ISO)와 국제전기표준회의(IEC)에서 개발한 것으로 최종적으로는 XML 파일 형태로 SBOM이 제작된다. 소프트웨어 구성 요소들과 라이선스 정보, 패치 상태, 설치 번들 정보 등이 포함된다.
SBOM, 어떻게 만드나?
SBOM을 만드는 방법은 여러 가지다. 개개인이 수동으로 작성할 수도 있고, 자동화 기술을 활용할 수도 있다. 하지만 현대 소프트웨어 애플리케이션들의 복잡한 구조를 생각했을 때 수기 작성법은 그리 권장되지 않는다. 하지만 덩치가 작은 프로젝트를 진행하고, 구성 요소의 수가 적다면 자동화 기술을 도입하는 것보다는 손으로 직접 목록을 작성하는 게 나을 수 있다. 이것은 상황에 따라 각 조직이나 개발자가 정해야 한다.
SBOM 작성에 도움이 되는 자동화 기술들은 시장에 이미 여러 개 나와 있다. 디펜던시를 전부 스캔하게 해 주는 제품들도 있고 오픈소스 리스크를 총체적으로 관리하게 해 주는 블랙덕(Black Duck) 같은 솔루션들도 인기가 높다. 블랙덕의 경우 최근 소프트웨어 개발 및 출시의 중요한 덕목인 CI / CD와도 궁합이 좋다. 자동으로 소프트웨어 구성 요소들을 스캔하고, 상업 요소들과 오픈소스 요소들을 구분해 내며, 데브옵스에도 부드럽게 통합된다.
SBOM은 여러 가지 측면에서 도움이 될 제도이자 장치가 될 것으로 예상된다. 우리가 사용하고 있는 소프트웨어들은 매우 복잡하게 구성되어 있고 점점 더 복잡해져 가는데, 언제까지 아무 것도 모른 채 사용할 수는 없는 노릇이다. SBOM이 아니더라도 언젠가는 비슷한 것이 나와 소프트웨어 생태계에 대한 가시성 확보의 중요성이 강조될 것이다. SBOM은 찬성과 반대의 주제로 접근할 것이 아니라, 어떻게 해야 더 효과적으로 구현할 것인지를 논해야 할 주제다.