SBOM이란? 소프트웨어 구성요소 명세서 이해하기

새 취약점과 우리 제품 사이의 빈칸

운영 중인 라이브러리에서 새 취약점이 공개되면 가장 먼저 나오는 질문은 ‘우리 제품에도 이 구성요소가 들어 있는가’입니다. 개발자는 저장소와 잠금 파일을 확인하고, 운영자는 배포된 버전을 찾으며, 구매 조직은 공급업체에 영향 여부를 묻습니다. 제품 하나가 수십 개의 직접 의존성과 더 많은 하위 의존성으로 만들어진 환경에서는 이 질문에 답하는 데 시간이 오래 걸립니다. 제품 이름과 설치 버전만 적은 자산 목록으로는 내부 구성요소까지 내려갈 수 없기 때문입니다.

소프트웨어 자재명세서(Software Bill of Materials, SBOM)는 이 빈칸을 줄이기 위한 기록입니다. NIST는 SBOM을 소프트웨어를 만드는 데 사용된 여러 구성요소의 세부정보와 공급망 관계를 담은 공식 기록으로 정의합니다. 완성된 프로그램을 하나의 포장 식품으로 본다면 SBOM은 재료명, 공급자, 버전과 재료 사이의 관계를 적은 성분표에 가깝습니다. 다만 사람만 읽는 문서가 아니라 자동 수집과 대조가 가능하도록 구조화된 데이터라는 점이 다릅니다.

SBOM이 기록하는 대상

SBOM의 한 줄은 보통 하나의 소프트웨어 구성요소를 가리킵니다. 직접 작성한 모듈, 공개된 오픈소스 패키지, 상용 라이브러리처럼 최종 제품을 이루는 부품이 대상이 됩니다. 단순한 파일 이름만 적으면 같은 이름을 가진 다른 구성요소나 다른 버전을 구별하기 어렵습니다. 그래서 구성요소의 이름과 버전뿐 아니라 공급자, 고유 식별자, 다른 구성요소와의 의존관계를 함께 기록합니다. SBOM 작성 주체와 생성 시각도 어느 제품 시점의 명세서인지 판별하는 데 쓰입니다.

최소 정보와 의존관계

미국 NTIA가 제시한 최소 요소의 데이터 필드는 공급자 이름, 구성요소 이름, 구성요소 버전, 그 밖의 고유 식별자, 의존관계, SBOM 데이터 작성자, 생성 시각으로 구성됩니다. 이 항목들이 함께 있어야 ‘어떤 공급자가 제공한 어느 부품의 어떤 버전인지’를 구분하고, 취약점 식별자와 자동으로 대조할 수 있습니다. 같은 라이브러리라도 버전이 다르면 취약점 영향 범위가 달라질 수 있으므로 버전을 비워 둔 목록은 대응 속도를 크게 떨어뜨립니다.

의존관계는 최종 제품과 구성요소 사이의 연결을 보여줍니다. 애플리케이션이 A 패키지를 직접 사용하고 A가 다시 B를 불러온다면, B는 개발자가 직접 추가하지 않았어도 제품 안에 포함될 수 있습니다. SBOM이 상위와 하위 관계를 표현하면 특정 구성요소가 어느 경로로 들어왔는지 추적할 수 있습니다. 패치할 패키지의 상위 의존성을 찾거나, 공급업체에 수정 버전 반영 여부를 물을 때 이 연결 정보가 기준이 됩니다.

고유 식별자는 이름 표기의 차이를 줄입니다. 조직마다 패키지 이름을 다르게 적거나 축약하면 동일 구성요소가 서로 다른 부품처럼 보일 수 있습니다. 패키지 URL 같은 표준 식별 방식을 함께 쓰면 생성 도구, 자산 저장소, 취약점 데이터 사이의 연결 정확도를 높일 수 있습니다. 운영팀은 식별자만 믿기보다 이름·버전·공급자와 함께 대조해 잘못된 매칭을 걸러야 합니다.

생성 시점과 릴리스 연결

SBOM은 소스 저장소를 한 번 훑어 만든 목록보다 실제 릴리스 산출물과 연결될 때 가치가 커집니다. 개발 소스에는 시험용 패키지와 빌드 도구가 들어 있을 수 있고, 조건부 빌드나 패키징 과정에서 최종 제품의 구성은 달라질 수 있습니다. 반대로 빌드 이후 설치 프로그램이나 컨테이너 이미지에 추가된 파일은 소스 단계 목록에서 빠질 수 있습니다. 따라서 어느 빌드와 어느 산출물에서 생성했는지 기록하고, 제품 버전·이미지 해시·릴리스 번호 같은 내부 배포 식별자와 연결해야 합니다.

생성 주기는 제품의 릴리스 주기와 맞추는 편이 자연스럽습니다. 새 라이브러리를 추가하거나 버전을 올렸다면 SBOM도 바뀌어야 합니다. 같은 제품 이름 아래 여러 버전이 운영된다면 각 릴리스의 SBOM을 별도로 보관해야 과거 버전과 최신 버전의 영향을 섞지 않을 수 있습니다. 공급업체에서 받은 SBOM도 수령일만 기록하지 말고 어떤 납품 파일·펌웨어·이미지와 짝을 이루는지 남겨야 합니다.

NIST는 사후에 생성한 SBOM이 빌드 당시 사용한 의존성 목록을 그대로 재현하지 못할 수 있다고 안내합니다. 운영 중인 바이너리나 설치 패키지를 뒤늦게 분석해 목록을 만들 수는 있지만, 빌드 환경에서만 존재했던 정보와 조건은 복원되지 않을 수 있습니다. 새 제품은 빌드 과정에서 자동 생성하고, 기존 제품은 생성 방식과 탐지 범위를 함께 기록해 신뢰 수준을 구분하는 방식이 필요합니다.

취약점 공개 뒤의 대조 과정

새 취약점이 공개되면 취약한 구성요소 이름과 영향 버전을 SBOM 저장소에 대조합니다. 일치 항목이 나오면 해당 구성요소를 포함한 제품과 릴리스를 찾고, 의존관계를 따라 직접 사용인지 하위 의존성인지 확인합니다. 그다음 실제 기능 사용 여부, 빌드 옵션, 배포 위치와 노출 조건을 검토해 조치 우선순위를 정합니다. SBOM은 첫 번째 질문인 ‘어디에 들어 있는가’를 빠르게 좁히지만, 취약점이 실제 환경에서 동작하는지까지 자동으로 확정하는 판정서는 아닙니다.

예를 들어 취약점이 라이브러리 2.x 계열에만 영향을 준다면 제품명으로 전체 시스템을 검색할 필요 없이 해당 이름과 버전 범위를 가진 SBOM 레코드를 찾을 수 있습니다. 결과에는 제품 소유자, 서비스 등급, 외부 노출 여부 같은 운영 정보를 붙여야 대응 순서를 정할 수 있습니다. 취약점이 조치된 뒤에는 실제 배포된 버전을 다시 확인하고, 수정 릴리스의 SBOM을 새로 보관해야 다음 대조에서 이전 상태가 남지 않습니다.

운영 자료로 쓰기 위한 점검

1. 대상 산출물 일치: SBOM이 실제 배포한 설치 파일·컨테이너 이미지·펌웨어 릴리스와 같은 버전을 가리키는지 확인합니다.
2. 버전 완전성: 구성요소 이름은 있지만 버전이나 식별자가 비어 있는 레코드를 찾아 생성 설정과 원본 데이터를 보완합니다.
3. 의존관계 연결: 최종 제품에서 직접 의존성과 하위 의존성까지 추적되는지 표본 구성요소로 검증합니다.
4. 취약점 대조: 구성요소와 영향 버전의 일치 결과를 실제 기능 사용 여부·배포 위치·노출 조건과 함께 검토합니다.
5. 담당·조치 상태: 영향 제품의 소유자, 조치 기한, 수정 릴리스, 재배포 결과를 기록하고 새 SBOM으로 상태를 갱신합니다.

기계가 읽을 수 있는 형식

SBOM은 PDF나 스프레드시트처럼 사람이 읽는 목록으로도 표현할 수 있지만, 여러 제품과 새 취약점을 반복 대조하려면 기계 가독성이 필요합니다. NIST는 표준 형식의 예로 SPDX, CycloneDX, SWID를 제시합니다. 중요한 점은 특정 확장자를 선택하는 데 그치지 않고, 조직의 저장소와 취약점 관리 절차가 해당 형식을 안정적으로 읽고 필수 필드를 유지하는지 확인하는 것입니다. 형식 변환 과정에서 버전, 식별자, 의존관계가 빠지면 자동화된 대조 결과도 불완전해집니다.

자동화 지원은 대규모 운영에서 반복성을 확보합니다. 빌드마다 같은 규칙으로 SBOM을 생성하고, 산출물과 함께 저장하며, 새 취약점 정보가 들어오면 영향을 받는 레코드를 다시 찾는 흐름을 만들 수 있습니다. 생성 도구의 성공 여부만 확인하지 말고 구성요소 수의 급격한 감소, 버전 누락률, 의존관계 단절, 이전 릴리스와의 예상 밖 차이를 품질 지표로 보는 편이 좋습니다.

SBOM이 대신하지 않는 판단

SBOM은 소프트웨어 내부의 투명성을 높이는 기초 데이터이지, 그 자체로 제품의 안전성을 보증하는 인증서가 아닙니다. 취약한 구성요소가 목록에 있다고 해서 모든 배포 환경에서 같은 공격 조건이 성립하는 것은 아니며, 목록에 알려진 취약점이 없다고 해서 제품 전체가 안전하다는 뜻도 아닙니다. 자체 작성 코드의 결함, 잘못된 설정, 노출된 관리 기능처럼 구성요소 명세만으로 판단하기 어려운 위험이 남습니다.

NIST는 SBOM이 기존의 공급망 위험관리, 취약점 관리, 공급업체 평가를 대체하지 않고 보완한다고 설명합니다. SBOM을 받아 저장만 하고 분석하거나 조치하지 않으면 운영 상태는 달라지지 않습니다. 최신 릴리스와 연결된 정확한 데이터, 반복 가능한 취약점 대조, 담당자와 수정 상태까지 이어지는 절차가 함께 있어야 명세서가 실제 대응 자료로 기능합니다.

국내에서도 KISA는 SW 공급망 보안 체계 진단 서비스에서 SBOM을 생성·분석해 취약점이 있는 오픈소스 구성요소를 식별하고 조치 컨설팅으로 연결하고 있습니다. 2026년 공개된 KISA 사례집도 개발·공급 조직과 도입·운영 조직의 환경에서 SBOM 기반 관리체계를 적용한 흐름을 다룹니다. 조직이 처음 시작한다면 모든 제품을 한꺼번에 등록하기보다 외부에 노출되고 업데이트 영향이 큰 제품 하나를 골라 생성, 검증, 대조, 조치, 재발행의 한 주기를 끝까지 수행하는 편이 운영 기준을 잡기 쉽습니다.

정리

SBOM은 소프트웨어 제품을 이루는 구성요소와 그 관계를 구조화해 기록한 명세서입니다. 공급자·구성요소·버전·식별자·의존관계·작성자·생성 시각을 갖추고, 실제 릴리스 산출물과 연결해야 합니다. 새 취약점이 공개되면 SBOM으로 영향 후보를 좁힌 뒤 환경 조건과 소유자를 확인하고, 수정 릴리스의 명세서로 갱신합니다. 정확성, 최신성, 기계 가독성과 조치 절차가 함께 유지될 때 제품 내부를 찾는 시간이 줄어듭니다.