SBOM 개요

SBOM이란 무엇인가

소프트웨어 자재 명세서(Software Bill of Materials, SBOM)는 한 소프트웨어 제품을 구성하는 모든 구성요소와 라이브러리, 그리고 그것들 사이의 의존 관계를 기계가 읽을 수 있는 형태로 나열한 목록입니다. 제조업의 부품표(Bill of Materials)를 소프트웨어로 옮긴 개념입니다. 완성차 한 대에 어떤 부품이 어느 공급사에서 들어왔는지 적은 명세서가 있듯, SBOM은 애플리케이션 하나에 어떤 오픈소스와 상용 구성요소가 어떤 버전으로 들어갔는지를 기록합니다.

현대 소프트웨어는 대부분 직접 작성한 코드보다 외부에서 가져온 구성요소로 채워집니다. 그 외부 구성요소에는 취약점이 있을 수 있고, 라이선스 의무가 따라붙으며, 또 그 구성요소가 다시 다른 구성요소에 의존합니다. SBOM은 이 의존성의 사슬을 가시화해, 보안과 라이선스 관리와 자산 관리가 공통으로 참조할 데이터 계층을 제공합니다.

왜 필요한가: 공급망 신뢰의 붕괴

SBOM을 정책 의제로 끌어올린 계기는 두 건의 공급망 사건이었습니다. 2020년 12월 드러난 솔라윈즈(SolarWinds) 사건에서 공격자는 오리온(Orion) 소프트웨어의 정상 업데이트 경로 자체를 오염시켰습니다. 그 업데이트를 신뢰하고 설치한 수많은 조직에 백도어가 함께 퍼졌습니다. 공급망 상류 한 곳의 침해가 하류 전체로 번지는 구조였습니다.

1년 뒤인 2021년 12월에는 자바 로깅 라이브러리 Log4j의 원격 코드 실행 취약점(CVE-2021-44228, 통칭 Log4Shell)이 공개되었습니다. 이 사건이 드러낸 문제는 침해 자체가 아니라 가시성의 부재였습니다. Log4j는 무수한 제품에 간접 의존성으로 깊숙이 박혀 있었던 탓에, 정작 “우리 제품 어디에 이 라이브러리가 들어 있는가"라는 질문에 즉답할 수 있는 조직이 드물었습니다. 모든 소프트웨어가 구성요소 목록을 기계가 읽을 수 있는 형태로 미리 갖추고 있었다면, 영향 범위 파악은 질의 한 번으로 끝났을 것입니다. 이 경험이 SBOM 의제에 직접적인 동력을 주었습니다.

이후 SBOM은 권고를 넘어 제도로 들어왔습니다. 미국은 2021년 행정명령 14028로 연방 납품 소프트웨어에 SBOM을 요구하는 길을 열었고, 유럽연합은 사이버 복원력법(Cyber Resilience Act, CRA)으로 SBOM 작성을 법적 의무로 규정했습니다. 자세한 규제 지형은 3. 규제 동향에서 다룹니다.

SBOM이 주는 이점

SBOM의 가치는 보안 한 가지에 그치지 않습니다. 구성요소 목록이라는 같은 데이터를 여러 용도가 함께 활용합니다.

• 취약점 관리와 사고 대응: 새 취약점이 공개되면 영향받는 구성요소를 즉시 조회해 대응 우선순위를 정할 수 있습니다.
• 공급망 위험 관리: 외부 구성요소의 출처와 신뢰도를 평가해 조달과 공급사 관리에 반영합니다.
• 라이선스 컴플라이언스: 각 구성요소의 라이선스를 추적해 의무 위반과 충돌을 미리 방지합니다.
• 규제 준수: 투명성 요건을 충족하고, 규제 보고와 감사에 필요한 증빙을 제공합니다.
• 자산 관리와 운영 효율: 무엇을 쓰고 있는지 정확히 알게 되어 수명주기 관리가 쉬워집니다.

누가 만들고 누가 쓰는가

SBOM의 가치는 한 조직이 홀로 만드는 데서 나오지 않고 공급망을 따라 흐를 때 실현됩니다. CISA의 Framing Software Component Transparency 3판은 SBOM을 둘러싼 행위자를 세 관점으로 정리합니다. 소프트웨어를 만드는 생산자(Produce), 어떤 소프트웨어를 쓸지 고르는 선택자(Choose), 그것을 운영하는 운영자(Operate)입니다. 한 조직이 세 역할을 겸하는 일이 흔합니다. 자사 제품을 개발하면서 외부 라이브러리를 도입하고 인프라를 운영하는 기업이 그렇습니다.

이 구도의 핵심은 공급자와 소비자 관계의 연쇄입니다. 상류의 생산자가 SBOM을 만들어 하류로 전달하면, 하류의 선택자는 그 SBOM으로 도입 전 위험을 평가하고, 운영자는 새 취약점이 공개되었을 때 영향 범위를 즉시 조회합니다. Log4Shell이 보여준 것은 바로 이 연쇄의 단절이었습니다. 생산자가 구성요소 목록을 넘기지 않았기에 운영자가 자신의 자산에 어떤 라이브러리가 들었는지 알 수 없었습니다.

행위자별로 이해는 미묘하게 어긋납니다. 소비자는 더 깊고 완전한 SBOM을 원하고, 생산자는 영업 비밀과 공격 표면 노출을 우려해 공개 범위를 줄이려 합니다. 규제가 의무의 최저선을 어디에 두는지, 공개 범위를 어떻게 조정하는지는 이 긴장을 푸는 장치입니다. 공유와 공개 범위 문제는 7. 공유와 거버넌스에서 다룹니다.

다음 절에서는 SBOM이 담는 정보의 깊이에 따른 수준과 분류를 살펴봅니다.

출처

이 절의 사실 근거는 본 가이드의 배경 조사 자료에 정리돼 있습니다. 행정명령 14028(86 FR 26633, 2021-05-12), CVE-2021-44228(NVD), CISA Framing Software Component Transparency 3판(2024-09-03)을 1차 출처로 삼았습니다. 전체 출처는 3. 규제 동향과 각 절 하단을 참고하십시오.