무기체계 소프트웨어 통합 형상관리 가시성 확보를 위한 개선방안

서론

현대 무기체계에서 소프트웨어가 차지하는 비중과 역할은 날로 커지고 있다. 소프트웨어의 규모가 방대해짐에 따라 단일 개발기관이 모든 코드를 자체 작성하는 것은 사실상 불가능해졌으며, 제3자 소프트웨어(공개·상용 SW) 활용과 기규격 소프트웨어의 재사용은 이미 보편적인 개발 방식으로 자리 잡았다.

이러한 흐름 속에서 '소프트웨어 공급망 보안'의 중요성은 국제적으로도 큰 주목을 받고 있다. 미국은 2021년 국가 사이버 보안 개선에 관한 행정명령(EO 14028)을 통해 연방정부 조달 소프트웨어에 대한 SBOM(소프트웨어 자재명세서) 제출을 의무화했다. 국방 영역에서도 미 육군이 2024년 8월 신규 소프트웨어 계약에 SBOM 제출을 의무화하는 정책을 발령하는 등 공급망 관리의 제도화가 빠르게 진행 중이다. 우리나라도 2024년 과기정통부와 국정원 등 관계 부처 합동으로 'SW 공급망 보안 가이드라인'을 발표하며 적극적인 대응에 나섰다. 이제 소프트웨어 공급망 전반에 대한 가시성 확보와 체계적인 형상관리는 선택이 아닌 필수 과제다.

본 기고에서는 논의에 앞서 편의를 위해 소프트웨어를 [그림 1]과 같이 실제 임무 수행을 위한 ’임무SW(자체개발 소스코드, 기규격 재사용 소스코드, 공개·상용 라이브러리)’와 운용환경을 구성하는 ‘운용환경SW(OS·DBMS·MW 등)’로 구분하였다.

현재 국방 분야의 소프트웨어 형상관리는 무기체계별 CSCI(Computer Software Configuration Item, 소프트웨어 형상항목) 단위의 문서 중심으로 분산 관리되고 있다. 운용환경SW의 경우 「무기체계 소프트웨어 개발 지원에 관한 규정」 제 5조 무기체계 소프트웨어 현황조사에 따라 ‘무기체계 소프트웨어 적용현황’ 조사를 통해 통합관리가 이루어지고 있으나, 이는 주로 국산화율 파악에 초점이 맞춰져 있어 형상관리 측면에서의 구조적 한계가 뚜렷하다. 임무SW의 형상관리 한계는 더욱 두드러진다. 체계적인 형상관리 시스템이 미흡할 뿐만 아니라, 관련 정보가 각 체계의 산출물 문서에 분산 기록되어 있어 소프트웨어 공급망 전반의 가시성 확보가 제한된다.

이에 본 기고에서는 현행 국방 소프트웨어 통합 형상관리 체계의 구조적 문제점을 파악하고, 소프트웨어 공급망 관리를 위한 실질적인 개선방안을 제안하고자 한다.

현행 SW 형상관리의 한계점

현행 국방 소프트웨어 형상관리는 크게 두 가지 측면에서 한계를 드러내고 있다. 첫째, 임무SW에 대한 통합 형상관리 체계가 근본적으로 미흡하며, 둘째, 운용환경SW의 적용현황 조사 방식 역시 구조적인 문제점을 내포하고 있다. 아래에서는 이러한 한계로 인해 실무적으로 파생되는 구체적인 문제점들을 살펴본다.

[임무SW] 비정형 문서 관리에 따른 구성요소 추적성 확보의 한계 ([그림 2] 참조)

무기체계 소프트웨어 개발 시 개발 효율성을 높이기 위해 기규격SW의 재사용이 널리 활용되고 있다. 그러나 현행 CSCI 단위의 문서 기반 관리 체계에서는 재사용 사실이 이를 가져다 쓴 체계 B의 SPS(Software Product Specification, 소프트웨어 산출물명세서)에만 단편적으로 기록될 뿐, 원본인 체계 A의 SPS에는 이러한 의존 관계가 반영되지 않는다. 그 결과 특정 기규격SW가 타 체계에서 얼마나 재사용되고 있는지 전체 현황을 파악하기 위해서는 담당자가 전 체계의 SPS 문서를 일일이 열람해야 하는 구조적 한계에 부딪힌다.

공개·상용 SW 라이브러리의 상황도 마찬가지다. 임무SW 내부에 포함된 라이브러리 정보는 체계별 SPS 등에 HWP·엑셀과 같은 비정형 문서 형태로 분산 기록되어 있을 뿐, 이를 범체계적으로 통합 관리하는 시스템이 존재하지 않는다. 이로 인해 특정 라이브러리에 CVE(Common Vulnerabilities and Exposure, 공통 취약점 및 노출) 등 보안 취약점이 발견되거나 라이선스 만료·단종이 발생하더라도, 영향을 받는 무기체계를 즉각적으로 식별하기 어렵다.

이러한 통합관리 체계의 부재는 결함 조치 시 더욱 심각한 문제로 이어진다. 체계 A에 적용된 공용 컴포넌트에 결함이 발견되더라도 체계 A의 산출물에는 해당 컴포넌트를 재사용하는 타 체계의 식별 정보가 없기 때문에 결함 조치가 체계 A에만 국한될 가능성이 높다. 구성요소 간 연계 및 의존 정보가 시스템적으로 관리되지 않는 한 동일한 잠재적 결함이 타 체계에 잔존하는 문제는 구조적으로 반복될 수밖에 없다.

[운용환경SW] 소프트웨어 적용현황 조사 방식의 문제점

CSCI 단위 조사에 따른 운용환경SW 중복 집계 ([그림 3] 참조)

현행 ‘무기체계 소프트웨어 적용현황’ 조사는 CSCI 단위로 수행된다. CSCI는 사업 특성과 개발기관의 관리 방식에 따라 그 구분 기준이 상이할 수 있어 하나의 하드웨어에 복수의 CSCI가 탑재되는 경우가 드물지 않다. 실제 무기체계 개발 현장에서는 전시처리 CSCI, 통신 CSCI 등 기능별로 CSCI를 세분화하는 것이 일반적이어서, 단일 하드웨어에 3개 이상의 CSCI가 탑재되는 사례도 빈번하다. 이는 형상관리 측면에서 자연스러운 구조이나, 운용환경SW 조사를 CSCI 단위로 수행함에 따라 중복 집계 문제가 발생한다.

예를 들어 단일 하드웨어에 A CSCI와 B CSCI가 함께 탑재된 경우를 가정하자. 현행 조사 방식에서는 A CSCI의 운용에 필요한 OS·DBMS 등 운용환경SW를 한 차례 식별하고, 이어서 B CSCI의 운용환경SW를 별도로 다시 식별하게 된다. 그 결과 실제로는 하나의 하드웨어에 Windows가 단 한 개 설치되어 있음에도 불구하고, 적용현황 조사에서는 동일한 OS가 두 개 활용되는 것으로 집계되는 문제가 발생한다. 이는 소프트웨어 적용현황의 정확성을 저해하고, 국산화율 산출 등 조사 목적 달성에도 왜곡을 초래한다.

후속사업·형상변경에 따른 적용현황 최신화 누락 ([그림 4] 참조)

현행 적용현황 조사는 전년도 규격화가 완료된 신규 제정 CSCI를 대상으로 매년 수행된다. 이러한 조사 방식은 최초 규격화 시점의 운용환경SW를 식별하는 데는 유효하나, 이후 발생하는 변경사항을 지속적으로 반영하지 못하는 구조적 한계를 내포하고 있다.

실제로 무기체계는 최초 전력화 이후에도 부품 단종·대체, 성능개량 사업, 후속 양산 기술변경 등을 거치며 운용환경SW가 변경되는 경우가 빈번하다. 예를 들어 2010년에 Windows 7 기반으로 규격화된 CSCI가 이후 사업을 통해 Windows 10 환경으로 전환되었더라도, 해당 변경이 신규 규격 제정을 수반하지 않는 경우에는 적용현황 조사 대상에 포함되지 않아 갱신이 이루어지지 않는다. 그 결과 적용현황 데이터에는 실제 운용 환경과 괴리된 정보가 그대로 유지되며, 이는 현황 데이터의 신뢰성을 근본적으로 저해하는 요인으로 작용한다.

개선 방안: SBOM 기반 소프트웨어 적용현황 조사 체계 구축

앞서 살펴본 바와 같이, 현행 무기체계 소프트웨어 형상관리는 CSCI 단위의 비정형 문서 기반 관리로 인해 임무SW 구성요소의 추적성 확보가 어렵고, 운용환경SW 조사에서도 중복 집계 및 최신화 누락이라는 구조적 한계를 내포하고 있다. 이러한 문제를 근본적으로 해소하기 위해서는 조사 단위와 형상관리 방식 전반에 대한 개선이 필요하다. 이와 관련하여 해외에서는 소프트웨어 구성요소의 투명한 관리 수단으로 SBOM이 주목받고 있으며, 미국 등 주요국에서는 이미 사이버보안 및 공급망 관리의 핵심 도구로 제도화되고 있다.

SBOM이란 소프트웨어를 구성하는 컴포넌트의 버전·출처·의존 관계 등을 체계적으로 목록화한 명세서로, 식품의 성분표에 비유할 수 있다. 어떤 소프트웨어가 어떤 구성요소로 이루어져 있는지를 한눈에 파악할 수 있어, 보안 취약점 식별이나 라이선스 관리에 효과적으로 활용된다. 그렇기에 앞서 설명한 현행 SW 형상관리의 한계점 보완을 위하여 하드웨어 단위의 SBOM 도입을 제안한다. 다만 기존 SBOM이 임무SW의 구성요소 식별에 초점을 맞추고 있는 것과 달리, 본 기고에서 제안하는 방식은 운용환경SW까지 포함하는 확장형 SBOM 개념을 무기체계에 적용하는 것이다.
구체적인 개선 방향은 다음과 같다.

첫째, 조사 단위를 CSCI에서 SW 탑재 하드웨어 단위로 전환한다. 현행 CSCI 단위 조사에서 발생하는 운용환경SW 중복 집계 문제는 조사 기준을 실제 하드웨어 단위로 변경함으로써 해소할 수 있다. 하나의 하드웨어에 복수의 CSCI가 탑재되더라도 운용환경SW는 해당 하드웨어에 대해 한 차례만 식별하므로, 중복 없는 정확한 현황 파악이 가능해진다. 이는 국산화율 산출 등 기존 조사 목적의 정확성도 함께 높이는 효과를 가져온다.

둘째, 임무SW는 SBOM 방식으로 구성요소를 통합 식별한다. 자체개발 소스코드, 기규격 재사용 소스코드, 공개·상용 라이브러리를 포함한 임무SW 전반을 체계 단위로 목록화함으로써, 현행 비정형 문서 기반 관리의 한계를 극복하고 구성요소 간 재사용·의존 관계를 추적할 수 있는 기반을 마련한다. 이를 통해 특정 라이브러리에 CVE가 발생하거나 기규격 컴포넌트에 결함이 식별되었을 때, 영향을 받는 체계를 즉각적으로 조회하고 조치 범위를 특정하는 것이 가능해진다.

셋째, 운용환경SW는 SW 유형·제품명·버전 수준으로 기록한다. 예를 들어 운영체제의 경우 ‘Windows 10’, 데이터베이스의 경우 ‘MS SQL 2019’와 같이 기록하는 방식이다. 이를 통해 조사의 복잡성을 줄이면서도 체계별 운용환경SW 현황을 명확하게 파악할 수 있다. 특히 버전 정보까지 기록함으로써 지원 종료(EoL) 소프트웨어나 보안 패치가 필요한 버전을 신속하게 식별하는 것도 가능해진다.

넷째, 정기 갱신 및 수시 갱신을 제도화한다. 현행 매년 신규 제정 CSCI 중심의 조사 방식에서 벗어나, 주기적 정기 갱신과 부품 단종·대체, 성능개량 등 형상변경 발생 시 수시 갱신을 병행하는 방식으로 전환함으로써 최신화 누락 문제를 구조적으로 해소할 수 있다. 갱신 이력을 데이터로 누적 관리함으로써 향후 무기체계별 소프트웨어 변경 이력 추적과 감사 기반 마련에도 기여할 수 있다.

위의 개선 방향을 실무에 적용하기 위한 첫걸음으로 [그림 5]와 같이 SBOM 개념을 적용한 새로운 소프트웨어 적용현황 조사 양식을 제안한다. 현 시점에서 완전한 자동화 도구 도입이 어렵더라도, 구조화된 양식만으로도 현행 비정형 문서 관리의 한계를 상당 부분 극복할 수 있을 것으로 기대하며, 궁극적으로는 이러한 데이터 구조를 기반으로 한 DB 기반 통합 형상관리 시스템으로 발전시켜 나가는 것이 바람직하다.

결론

현행 국방 소프트웨어 형상관리 체계는 CSCI 단위의 비정형 문서 기반 관리에 머물러 있어, 임무SW 구성요소의 추적성 확보와 운용환경SW의 정확한 현황 파악 모두에서 구조적 한계를 드러내고 있다. 제3자 소프트웨어 활용과 기규격 소프트웨어 재사용이 보편화되는 환경에서, 소프트웨어 공급망 전반에 대한 가시성 확보는 무기체계 신뢰성 및 형상관리 측면에서 더 이상 미룰 수 없는 과제다.

본 기고에서는 이러한 한계를 극복하기 위한 방안으로 하드웨어 단위의 확장형 SBOM 도입을 제안하였다. 조사 단위를 하드웨어 단위로 전환하고, 임무SW는 SBOM 방식으로 구성요소를 통합 식별하며, 운용환경SW는 SW 유형·제품명·버전 수준에서 간결하게 기록하되 정기 갱신 및 수시 갱신을 제도화하는 것이 그 핵심이다. 이를 통해 중복 집계, 최신화 누락, 구성요소 추적 불가 등의 문제를 구조적으로 해소할 수 있을 것으로 본다.

미국 등 주요국이 SBOM을 소프트웨어 공급망 관리의 핵심 수단으로 제도화하는 흐름에 발맞추어, 국방 분야에서도 데이터 기반의 통합 형상관리 체계를 구축해 나갈 필요가 있다. 국내에서도 2024년 관계 부처 합동으로 SW 공급망 보안 가이드라인이 발표되는 등 제도적 기반이 마련되고 있는 만큼, 국방 소프트웨어 분야에서도 이러한 흐름에 선제적으로 대응할 필요가 있다. 본 기고에서 제안한 하드웨어 단위 확장형 SBOM이 향후 국방 소프트웨어 관리 체계 발전을 위한 실질적인 논의의 출발점이 되기를 바란다.​​​​​​​​​​​​​​​​