개요

작년 미국의 국가 사이버 보안 강화 지침(2021년 5월)이 배포된 이후, 소프트웨어 산업의 다양한 채널에서 SBOM과 관련한 자문이나 회의가 생기고 있는 상황입니다. 

최근의 보안 위협은 공급망, 구축도구, 구축환경, 레파지토리등을 공격하는 추세가 많아지고 있는데 이 지침에서는 미국 연방정부가 사용하는 소프트웨어 공급망의 보안과 무결성을 개선하기 위한 조치를 지시하고 있습니다.

지침이 배포된 이후 미국 정부의 요청으로 미국의 90여개 소프트웨어 기업, 오픈소스 커뮤니티가 자문에 참여하여 의견을 제시히고, CISA, NTIA 에서는 이를 정리하여 SBOM 과 관련한 가이드라인 및 FAQ를 공개하였습니다.

 

SOFTWARE BILL OF MATERIALS | National Telecommunications and Information Administration

A “Software Bill of Materials” (SBOM) is a nested inventory for software, a list of ingredients that make up software components. The following documents were drafted by stakeholders in an open and transparent process to address transparency around sof

www.ntia.gov

 

SBOM 이란?

SBOM 은 SOFTWARE BILL OF MATERIALS 의 약자로 소프트웨어의 구성 요소를 나타내는 메타데이터를 의미하는데 이를 보다 쉽게 설명하자면 우리가 흔히 볼 수 있는 다음과 같은 제품의 성분표기를 떠올리면 됩니다.

성분표기를 통해서 알러지가 있는 사람은 해당 식품을 피하기도 하고, 공급자는 제품의 우수성을 홍보하기도 하고, 크게 성분에 신경쓰지 않고 그냥 사용하는 사용자도 있을 수 있죠.

이와 유사하게, SBOM은 공급되는 소프트웨어의 구성 목록을 잘 표시해서 공급자와 사용자가 이를 기반으로 의사결정에 활용할 수 있는 환경을 조성하는 것을 목표로 하고 있습니다.

NTIA 에서 발표한 SBOM의 필수 구성요소는 다음과 같이 구성되어 있습니다.

 

  • Supplier name
  • Component name
  • Version of the component
  • Cryptograph hash of the component
  • Any other unique identifier
  • Dependency relationship
  • Author of the SBOM data

 

이를 기반으로 작성한다면 다음과 같은 개념도로 표시할 수 있습니다.

National Telecommunications and Information Administration (NTIA) 에서는 오픈소스 소프트웨어나 상용 소프트웨어로 구분하지 않고 모든 공급되는 소프트웨어를 대상으로 광범위하게 적용할 수 있는 SBOM 적용을 위해 산업계의 여러 기업과 커뮤니티에 의견을 청취하고 이를 토대로 SBOM의 이해를 돕는 자료와 적용방법에 대하여 다양한 문서를 배포하고 있으니 아래 문서들을 참고하시기 바랍니다.

 

SPDX, OpenChain

이러한 소프트웨어 구성 목록을 기반으로 공급망의 투명성을 확보해야 한다는 필요성은 오픈소스 커뮤니티에서 10여년 전부터 논의되어 왔으며, 이를 해결하기 위해 실제 산업에서 SPDX와 OpenChain 이 많이 사용되고 있습니다.

  • SPDX는 라이선스 컴플라이언스, 보안 등과 같은 문제를 다루면서 진화해서 현재는 시장에서 가장 성숙한 SBOM으로 자리잡고 있습니다. (https://www.linuxfoundation.org/blog/what-is-an-sbom/)
  • 또한 오픈소스 라이선스 준수를 위한 ISO 국제표준(https://www.iso.org/standard/81039.html) 으로 오픈체인이 있으며, 이는 소프트웨어 공급망의 투명성을 강화하기 위하여 오픈소스 커뮤니티에서 고민하던 결과물입니다.

SBOM이 소프트웨어 보안의 모든 문제를 해결할 수는 없지만 보다 안전한 소프트웨어 사용에 필요한 기본을 제공하는 것은 분명히 필요한 일이며, 다양한 산업계의 의견을 토대로 만들어진 SBOM을 기반으로 소프트웨어 공급망의 투명성을 강화할 수 있는 미국의 이번 정책은 향후 IT 산업과 디지털 인프라의 소프트웨어 관리에 있어서 매우 중요하다고 생각됩니다.

'IT/비즈니스 컨설팅' 카테고리의 다른 글

제로트러스트  (0) 2023.07.12
미래교육을 위한 에듀테크 플랫폼  (0) 2019.10.30
4차산업혁명과 오픈소스거버넌스  (0) 2017.03.18
애자일 이야기  (0) 2016.09.25
IT 기획 전문가 학습로드맵  (2) 2013.11.16
BOM (봄; Byte Order Mark)은 '바이트 순서 표시'입니다.

유니코드가, little-endian 인지 big-endian 인지 아니면 UTF-8 인지 쉽게 알 수 있도록, 유니코드 파일이 시작되는 첫부분에 보이지 않게, 2~3바이트의 문자열을 추가하는데 이것을 BOM이라고 합니다. 텍스트 에디터 화면에서는 보이지 않고, 헥사 에디터(Hex Editor)*로 열었을 때만 보입니다.



little-endian 의 BOM:
FF FE

big-endian 의 BOM:
FE FF

UTF-8 의 BOM:
EF BB BF



UTF-8에는 BOM이 없는 것이 보통인데, 오래된 프로그램은 BOM이 있는 UTF-8 파일에 오작동할 수 있습니다.

그렇지만 한국어 편집에서는 BOM이 있는 UTF-8이 더 좋습니다. 만약 'BOM이 없는 UTF-8 파일'에 영문과 숫자만 있고 한글이 없다면, 편집기가 그 파일을 유니코드가 아닌 일반 아스키 파일로 오인하기 때문입니다.

그런데 인터넷에 올릴 HTML/CSS/XML 파일을 UTF-8로 작성할 때에는 BOM이 있으면 문제가 생길 수 있습니다.


* 울트라에디트의 헥사 모드(Ctrl+H)로 UTF-8 파일을 보면, 16비트 유니코드처럼 보이고 BOM이 있든 없든 항상 FF FE 라는 엉뚱한 BOM이 나타납니다. 이것은 울트라에디터가 유니코드를 편집할 때, 내부적으로 '16비트 little-endian 유니코드 (UTF-16LE)'로 변환하여 편집하기 때문입니다. 진짜 헥사 에디터로 보아야만 UTF-8의 BOM인 EF BB BF 가 제대로 보이게 됩니다. 물론 BOM이 없는 UTF-8이라면 BOM이 없는 것으로 나옵니다.

BOM 사용시 문제가 생기는 이유는 프로그램이 BOM을 처리하지 않기 때문입니다. 이는 프로그램이 유니코드를 지원하지 않거나, 지원하더라도 제대로 구현되지 않았다는 뜻입니다.
특히 웹에서 이러한 일이 많이 생기는 이유는 웹 프로그램들이 텍스트 파일을 로드해 붙여쓰는 경우가 많은데, 이 때, 파일의 처음에 BOM이 있을 수 있다는 가능성을 무시하고 제작된 프로그램이 많습니다. 그래서 붙여진 텍스트에는 텍스트 중간에 BOM이 존재할 수 있고, BOM의 특성상 제어문자로 오인되는 경우가 많아 처리과정에서 오류가 생겨 비정상으로 작동합니다.

정리하면:
BOM을 제대로 처리하지 못하면 유니코드를 제대로 지원하지 못하는 것입니다. 이상적으로는 제대로 된 프로그램만 사용하는 것이 가장 좋겠으나, 현실적으로는 그러기 힘들고 최대 호환성을 위해 BOM을 제거하는 것이죠.

+ Recent posts