SBOM

왜 배우는가: SBOM은 오픈소스 재사용이 늘면서 제품 안의 구성 요소와 취약점을 추적하는 기본 자료가 되었다. 공급망 보안과 라이선스 관리 요구가 커져 시험에서도 개념, 취약점 관리, 관리 방안 문항으로 반복해 나온다.

출제 이력: 제134회 3교시 3번, 제131회 1교시 13번

1. 한 줄 정의와 핵심 키워드

답안 첫 줄 정의: SBOM은 소프트웨어를 구성하는 컴포넌트의 목록, 버전, 출처, 라이선스 정보를 기계가 읽을 수 있는 형식으로 기술한 소프트웨어 구성명세서이다.

정의 문장을 먼저 쓰고, 이어서 공급망 보안과 취약점 연계를 한 문장으로 덧붙인다. 'SBOM'은 제조업의 자재명세서(BOM)에서 빌려 온 말이며, 답안에서는 영문 약어를 처음 한 번만 풀어 쓴다.

핵심 키워드

• 소프트웨어 구성명세서
• 오픈소스 컴포넌트
• 직접·간접 의존성
• 공급망 보안
• SPDX
• CycloneDX
• 라이선스 컴플라이언스
• CVE 연계

키워드는 본문 전체에서 같은 표기로 쓴다. 예를 들어 '의존성'과 '의존 관계'를 섞어 쓰지 않는다. 각 키워드는 아래 2절에서 한 번씩 풀이한다.

2. 개념 풀이

쉬운 말로 하면 SBOM은 완성 제품 뒤에 붙는 재료 목록이다. 식품 포장의 원재료 표시와 같은 역할을 한다. 원재료를 알아야 알레르기를 피할 수 있듯, 구성 요소를 알아야 취약점과 라이선스 위험을 피할 수 있다.

정식 정의는 다음과 같다. SBOM은 소프트웨어 제품을 구성하는 오픈소스, 상용, 자체 개발 컴포넌트의 식별자, 버전, 공급자, 의존 관계, 라이선스 정보를 표준 형식으로 정리한 문서 또는 데이터이다.

핵심 용어를 풀이한다.

• 컴포넌트: 제품에 포함되는 라이브러리, 패키지, 프레임워크 같은 단위다. 개발자가 직접 작성한 코드와 외부에서 가져온 코드를 모두 포함한다.
• 직접·간접 의존성: 제품이 직접 호출하는 패키지가 직접 의존성이다. 그 패키지가 다시 끌어오는 패키지가 간접 의존성(전이 의존성)이며, 개발자가 눈으로 확인하기 어려운 부분이다.
• 공급망 보안: 소프트웨어를 만들고 배포하는 전 과정에서 외부 구성 요소로 들어오는 위험을 관리하는 보안 활동이다.
• 라이선스 컴플라이언스: 구성 요소마다 붙은 라이선스의 의무와 금지 조항을 지키는 것이다. 공개 의무가 있는 라이선스를 상용 제품에 잘못 넣으면 법적 문제가 된다.

SBOM을 기록하는 형식은 여러 가지다. SPDX는 Linux 재단 중심으로 시작된 데이터 교환 형식이며 라이선스 준수에 초점이 있다. CycloneDX는 OWASP가 시작한 형식으로 취약점 식별과 보안 맥락 구축에 초점이 있다. 두 형식 모두 기계가 읽을 수 있어 도구 간 자동 처리가 가능하다.

SBOM과 자주 함께 거론되는 문서가 암호 자재명세서(CBOM, Cryptographic Bill of Materials)다. SBOM이 OpenSSL 같은 라이브러리의 포함 여부를 기록한다면, CBOM은 그 라이브러리가 사용하는 알고리즘, 키, 인증서 설정을 기록한다. 두 문서를 함께 쓰면 공급망 투명성과 암호 투명성을 모두 확보할 수 있다.

SBOM 자체는 취약점을 없애지 않는다. 취약점이 어느 제품, 어느 버전에 있는지 찾아 조치하는 근거를 줄 뿐이다. 이 점을 답안에서 분명히 쓰면 감점을 줄일 수 있다.

3. 등장 배경과 필요성

SBOM은 시스템에 쓰인 개방형 소프트웨어 구성 요소의 라이선스 데이터를 집계하는 방식으로 시작되었다. 이 개념의 역사에 대한 단일한 공식 출처는 없다. 대신 형식 표준화가 진행된 연혁은 비교적 분명하다.

오픈소스 재사용이 늘면서 직접 작성하지 않은 코드가 제품의 대부분을 차지하게 되었다. 직접 작성하지 않은 코드가 제품 대부분을 차지하므로 구성 요소 목록이 필요하다. 개발팀도 자신이 쓰는 패키지의 전체 목록을 알지 못하는 경우가 많다. 취약점이 공지되면 영향 범위를 찾는 데 시간이 오래 걸린다.