국방에 기여하는 국방기술품질원의 이야기
기술로 품질로


무기체계 소프트웨어 공급망 관리 발전 방향
글 지능SW팀 김종규·조한별 연구원
소프트웨어 공급망(Software Supply Chain)
소프트웨어 공급망은 소프트웨어 제품 및 서비스를 개발, 제공, 배포, 유지 관리하는 과정에서 관여되는 모든 개인, 조직, 자원, 활동 및 기술을 포함하는 네트워크를 의미한다. 기존의 하드웨어 공급망과 달리 △소프트웨어 취약점 △소프트웨어 버전·라이선스 △개발·배포 과정의 보안과 같은 항목들에 대한 집중적인 관리가 필요하다. 특히 오픈소스 및 외부 라이브러리의 사용이 일반화됨에 따라 공급망 전반에 걸친 가시성, 투명성과 신뢰성 확보가 중요한 과제로 떠오르고 있다. 최근에는 하나의 소프트웨어가 수십 개의 외부 컴포넌트에 의존하는 사례가 증가하면서 공급망 내 특정 컴포넌트의 취약점이 전체 시스템에 미치는 연쇄적 보안 위협(Cascading risk)으로 이어질 수 있다는 우려도 커지고 있다.
소프트웨어 공급망 공격 주요 사례
소프트웨어 공급망이 복잡해지면서 공격자는 특정 시스템 자체가 아닌 공급망의 취약한 고리를 노리는 방식으로 전략을 전환하고 있다. 이러한 공격은 한 번의 침투로도 다수 시스템에 악성코드를 전파할 수 있어 파급력 측면에서 매우 위협적이다. 대표적으로 2020년 SolarWinds Orion 사건에서는 업데이트 파일에 삽입된 악성코드가 약 18,000개 고객사에 영향을 미쳤다. 또한, 2021년 발생한 Log4Shell 취약점은 오픈소스 컴포넌트 하나의 결함이 얼마나 광범위하게 확산될 수 있는지를 보여주었다. 이 외에도 북한의 Kimsuky 조직이 수행한 Gomir 및 MoonPeak 공격 사례처럼 악성 프로그램을 정상으로 위장하여 대한민국을 포함한 특정 기관을 겨냥한 정황도 확인되고 있다.

출처 : 소프트웨어 공급망 보안 가이드라인 1.0 (한국인터넷진흥원)

출처 : 소프트웨어 공급망 보안 가이드라인 1.0 (한국인터넷진흥원)
소프트웨어 공급망 보안 강화와 SBOM
소프트웨어 공급망 보안 위협이 현실화되면서 주요국들은 관련 정책을 수립하고 대응에 나서고 있다. 특히 소프트웨어의 구성요소 투명성을 확보하고 보안 취약점을 사전에 파악할 수 있는 방안으로 SBOM 제출 요구 움직임이 확산되고 있다.

국방 분야와 비슷한 국가전략산업 중 의료기기 분야와 자동차 분야 또한 산업 특성을 고려하여 소프트웨어 공급망 보안 강화를 위한 제도적 기반을 마련, SBOM 제출을 현실화하고 있다.
소프트웨어 자재명세서, SBOM(Software Bill of Material)
SBOM(Software Bill of Materials, 소프트웨어 자재명세서)은 특정 소프트웨어에 포함된 모든 구성요소(라이브러리, 모듈, 의존성 등)를 명시한 문서이다. 이는 하드웨어 제품에서 사용되는 자재명세서(BOM) 개념을 소프트웨어에 적용한 것으로 소프트웨어에 어떤 구성요소가 포함되었는지를 파악하고 그 구성요소의 보안 상태를 분석할 수 있게 해준다. SBOM을 통해 개발자, 사용자 모두가 소프트웨어의 구조를 명확히 파악하여 투명성을 확보할 수 있으며 취약점의 조기 식별과 신속한 보안 대응의 기반을 제공해준다.
아래는 SBOM 적용 여부에 따른 소프트웨어 구성요소의 추적성을 비교한 개념도이다. SBOM이 적용되지 않은 경우는 최종 소프트웨어에 포함된 컴포넌트에 대해 사용자는 구조를 파악하기 어렵고 취약점이 존재하더라도 그 영향을 신속하게 식별하기 어렵다. 반면 SBOM이 적용된 경우는 각 계층의 구성요소가 체계적으로 기록·연결되어 있어 구성요소 간의 의존 관계 파악 및 취약점 대응이 가능하며 보안 취약점 관리와 유지보수 측면에서 높은 효율성을 제공한다.

SBOM의 최소 요소
미국 정보통신청(NTIA, National Telecommunications and Information Administration)은 SBOM을 효과적으로 활용하기 위해 다음과 같은 세 가지 최소 구성요소(Minimum Elements)를 제시하고 있다.
1. 데이터 필드 (Data Fields): 소프트웨어 공급망 전반에서 추적 및 관리되어야 하는 각 구성요소에 대해 아래의 7가지 기본 데이터 필드(정보)를 포함해야 한다.
데이터 필드명 | 내용 |
---|---|
공급자명 (Supplier Name) |
컴포넌트를 생성, 정의, 식별한 개체 이름 |
컴포넌트명 (Component Name) |
원 공급자에 의해 정의된 소프트웨어 단위에 부여된 명칭 |
버전 (Version of the Component) |
원래 버전에서 변경을 특정하기 위해 공급자에 의해 사용되는 식별자 |
식별자 (Other Unique Identifier) |
컴포넌트를 식별하거나, DB에서 검색 Key로 활용될 고유 식별자 |
의존관계 (Dependency Relationship) |
상위 SW에 대한 포함관계를 나타내는 설명 |
작성자 (Author of SBOM Data) |
SBOM 작성자 |
작성시점 (Timestamp) |
SBOM이 작성된 날짜와 시간 |
2. 자동화 지원 (Automation Support): SBOM은 기계 판독이 가능한 형식으로 생성되어야 하며, 자동 분석 및 대응이 가능하도록 해야 한다. 이를 위해 사용되는 대표적인 표준으로는 SPDX, CycloneDX, SWID tags가 있으며, 각 표준의 상세 내용은 아래와 같다.
표준명 | 내용 |
---|---|
|
|
|
|
![]() |
|
3. 지침과 절차 (Practices and Processes): SBOM의 요청, 생성, 배포, 업데이트 등 운영 전반에 대한 절차가 정의되어야 한다. 예를 들어 구성요소 분석 깊이, 생성 빈도, 오류 허용 기준, 접근 제어, 배포 방식 등이 포함된다.
무기체계 소프트웨어 공급망 관리 현황
오늘날 전장 환경 변화로 무기체계 내 소프트웨어 비중 역시 지속적으로 증가하고 있으며, 이에 따라 효율적인 개발을 위하여 기개발 소프트웨어의 재사용과 상용·공개 소프트웨어의 활용도 확대되고 있다. 그러나 이 과정에서 소프트웨어 결함으로 인한 무기체계의 오작동, 기술변경 사례 역시 증가하고 있다. 그렇기에 소프트웨어의 각 구성요소를 체계적으로 식별하고 관리하기 위한 무기체계 소프트웨어 공급망 관리의 필요성이 높아지고 있는 상황이다.
무기체계 소프트웨어는 방위사업청 [무기체계 소프트웨어 개발 및 관리 매뉴얼]에 따라 소프트웨어 형상품목(CSCI, Computer Software Configuration Item) 단위로 관리되고 있다. 매뉴얼에서는 CSCI 단위로 사용하는 제3자 소프트웨어를 식별하고 이를 소프트웨어 기술문서에 기록하도록 하고 있지만, 해당 정보들은 체계·CSCI 단위 문서로 파편화되어 관리되고 있어 특정 컴포넌트에 결함이 식별되더라도 타 체계·CSCI로 환류가 어렵고 취약점이 존재하는 제3자 소프트웨어를 사용 중인 경우에도 이를 인지하기 어려운 한계를 가지고 있다.
발전 방향
현재 공급망 관리의 어려움을 보완하기 위해서는 무기체계 소프트웨어 구성요소에 대한 통합관리체계 구축이 필요하다. 특히 각 체계에서 사용되는 제3자 소프트웨어를 표준화된 방식을 식별·기록할 수 있는 체계가 마련되어야 하며 이를 통해 유사 구성요소 간 정보 연계 및 결함 환류가 가능한 구조를 구축할 수 있다. 통합관리를 위한 핵심 수단 중 하나로 SBOM 도입을 생각할 수 있으며, 원활한 도입을 위해 다음과 같은 요소들이 고려되어야 한다.
1. 정책
SBOM을 국방 소프트웨어 분야에 도입하기 위해서는 제도적 기반 마련이 선행되어야 한다. 이를 위해 국방 규격에 SBOM 관련 기준을 반영하고, 소프트웨어 획득 및 유지보수 지침에 SBOM 생성·제출·검증 절차를 포함해야 한다. 또한, 제3자 소프트웨어(오픈소스, 상용 SW 등)의 사용 시 SBOM 제출을 계약 요건에 명시하고, 적용표준(예: SPDX, CycloneDX 등) 및 범위에 대한 기준을 제시해야 한다.
2. 인프라
SBOM을 효과적으로 활용하기 위해선 SBOM 저장, 조회, 분석이 가능한 전용 플랫폼이 필요하다. 이 플랫폼은 무기체계별, 사업단계별 소프트웨어 구성 정보를 중앙에서 통합관리할 수 있어야 하며 보안성도 확보되어야 한다. 이를 위해 폐쇄망 환경에서도 작동 가능한 온프레미스(On-premise) 기반의 SBOM 관리 솔루션 도입이 필요하다.
3. 국방 분야 SBOM 관리 표준
국방 분야 SBOM의 원활한 활용을 위해서는 기존 표준인 SPDX, CycloneDX를 그대로 사용하기에는 한계가 존재한다. 해당 표준은 민간의 상용 소프트웨어 환경을 기반으로 설계되어 있어, 무기체계의 고유한 운용 환경과 소프트웨어 생명주기, 폐쇄망 기반의 개발·운영 프로세스 등을 충분히 반영하기 어렵다.
따라서, 국방 소프트웨어 특성에 부합하는 독자적인 SBOM 관리체계 마련이 필요하다. 이는 단순히 기존 표준을 채택하는 수준을 넘어, 국방 요구에 맞춘 확장 규격 또는 별도 관리지침 수립이 필요하며, 국방 분야 맞춤형 SBOM 관리체계 구축을 위해 타 산업 분야의 사례 연구, 시범사업을 통한 프로세스 고도화도 함께 필요할 것으로 사료된다.
4. 통합관리 및 환류 프로세스
SBOM을 단순 기록 용도가 아니라 실제 품질·보안·공급망 리스크 관리에 활용하려면, 아래와 같은 통합 관리체계가 필요하다.
- 구성요소별 취약점 발생 시 SBOM 기반의 영향 범위 분석 프로세스 구축
- 유사 소프트웨어 간 결함·취약점 정보 공유 및 자동화된 환류 프로세스
- 체계개발, 시험, 운영, 정비 각 단계에서의 SBOM 업데이트 주기와 책임·관리 기관 명확화
국방 분야에서도 SBOM의 작성과 활용 방안을 단계적으로 마련하고, 소프트웨어 공급망 관리를 위한 정책·기술·프로세스 기반을 체계화한다면, SBOM 기반 명세와 변경 이력을 체계적으로 기록할 수 있게 된다. 이를 통해 ▲잠재적인 보안 취약점에 대한 선제적 대응 ▲구성요소의 재사용 효율성 향상 ▲기술 변경에 따른 영향 분석 등 무기체계 소프트웨어의 품질과 신뢰성 확보에 크게 기여할 것으로 기대된다.