소프트웨어를 도입하고 운영하는 것만으로는 충분하지 않은 시대다. 기업이 사용하는 시스템 안에 어떤 구성 요소가 포함되어 있고, 그 요소가 어디에서 왔으며, 보안 취약점이 발견되었을 때 어떤 업무 시스템에 영향을 미치는지까지 파악해야 한다. 이제 소프트웨어의 구성 성분을 관리하는 역량은 정보보호를 넘어 기업 IT 운영과 공급망 관리의 핵심 과제가 되고 있다.
1. 왜 지금 소프트웨어의 구성 성분을 관리해야 하는가
기업의 소프트웨어 환경은 과거보다 훨씬 복잡해졌다. ERP와 그룹웨어 같은 상용 솔루션을 도입하는 것은 물론, 웹 포털과 업무 시스템을 자체 개발하고, 외부 개발사의 프로그램을 연계하며, 오픈소스 라이브러리와 클라우드 서비스를 함께 사용한다.
이 과정에서 기업이 직접 개발하지 않은 수많은 소프트웨어 구성 요소가 업무 시스템에 포함된다. 개발자는 화면을 구성하기 위한 라이브러리를 사용하고, 외주 개발사는 공통 모듈과 외부 패키지를 활용한다. 상용 솔루션 역시 다양한 내부 구성 요소와 외부 기술에 의존할 수 있다.
문제는 기업이 완성된 소프트웨어를 도입했다는 사실은 알고 있어도, 그 안에 어떤 구성 요소가 포함되어 있는지 정확히 파악하지 못하는 경우가 있다는 점이다.
예를 들어 사내 업무 포털에서 사용하는 오픈소스 라이브러리에 심각한 취약점이 발견되었다고 가정해 보자. 해당 라이브러리가 실제로 사용되고 있는지, 어느 버전이 설치되어 있는지, 어떤 시스템이 영향을 받는지 파악할 수 없다면 담당자는 여러 개발사와 운영 조직에 일일이 확인해야 한다.
이 과정이 길어질수록 취약점 대응은 늦어지고, 업무 중단이나 정보 유출 위험에 노출되는 시간도 늘어날 수 있다.
따라서 기업은 단순히 소프트웨어의 이름과 계약 정보를 관리하는 수준을 넘어, 소프트웨어를 구성하는 개별 요소까지 추적할 수 있어야 한다. 이러한 요구를 충족하기 위한 핵심 개념 중 하나가 SBOM이다.
2. SBOM이란 무엇인가
SBOM(Software Bill of Materials)은 소프트웨어를 구성하는 구성 요소와 관련 정보를 정리한 명세서다. 쉽게 말해 완성된 소프트웨어의 재료 목록이라고 이해할 수 있다.
식품에 원재료와 함량, 제조 정보가 표시되어 있다면 소비자는 제품의 구성과 주의사항을 확인할 수 있다. SBOM도 비슷한 역할을 한다. 소프트웨어에 어떤 라이브러리와 패키지가 포함되어 있는지, 각 구성 요소의 버전과 공급자 정보는 무엇인지 등을 구조화해 관리하도록 돕는다.
SBOM은 단순한 문서 목록과 다르다. 제대로 생성된 SBOM은 도구가 읽고 분석할 수 있는 형식으로 제공되어 취약점 정보와 연결하거나 여러 시스템의 구성 요소를 비교하는 데 활용할 수 있다.
SBOM에서 확인할 수 있는 주요 정보
- 소프트웨어와 구성 요소의 이름
- 구성 요소의 버전과 식별 정보
- 개발자 또는 공급자 관련 정보
- 구성 요소 간 의존 관계
- SBOM 작성 및 생성 도구에 관한 정보
- 구성 요소의 무결성 확인에 활용할 수 있는 해시값 등 관련 정보
실제 포함 항목은 적용하는 표준과 SBOM의 목적에 따라 달라질 수 있다. 대표적으로 SPDX와 CycloneDX 같은 기계 판독형 형식이 활용된다.
2026년 7월 CISA와 NSA 등 미국 정부 기관 및 국제 파트너가 발표한 SBOM 최소 구성 요소 지침은 기존 지침을 업데이트하면서 구성 요소 해시, SBOM 버전, 작성자 서명 등과 관련된 정보를 강화했다. 또한 오픈소스뿐 아니라 AI 소프트웨어와 SaaS를 포함한 다양한 소프트웨어 유형을 고려하도록 범위를 명확히 했다.
이러한 변화는 SBOM이 개발 단계의 참고 자료를 넘어, 소프트웨어 공급망을 투명하게 파악하고 보안 위험을 판단하는 운영 기반으로 발전하고 있음을 보여준다.
3. 소프트웨어 공급망 보안은 왜 중요한가
기업의 보안 관리가 내부 네트워크와 사용자 계정, 서버 접근 통제만으로 완성되던 시대는 지났다. 외부에서 공급받는 소프트웨어와 개발 과정에서 사용하는 구성 요소 역시 보안 위험을 발생시키는 경로가 될 수 있다.
첫째, 직접 개발하지 않은 코드도 기업의 위험이 된다
오픈소스는 개발 생산성을 높이고 기술 활용 범위를 넓히는 중요한 수단이다. 그러나 널리 사용되는 구성 요소라도 취약점이 발견될 수 있으며, 유지보수가 중단되거나 업데이트가 늦어질 가능성도 있다.
기업이 해당 구성 요소의 존재와 버전을 모른다면 취약점이 공개된 이후에도 영향을 받는 시스템을 빠르게 식별하기 어렵다. 반대로 구성 요소 목록이 최신 상태로 관리되고 있다면 관련 시스템을 좁혀 조사하고, 우선순위를 정해 조치할 수 있다.
둘째, 외주 개발사의 관리 범위까지 확인해야 한다
많은 기업이 업무 시스템의 개발과 유지보수를 외부 전문 업체에 맡긴다. 이때 계약상 산출물과 기능 테스트 결과만 확인하고, 실제 사용된 라이브러리나 구성 요소의 정보를 받지 않는다면 운영 조직은 시스템 내부의 기술적 의존성을 충분히 파악하지 못할 수 있다.
유지보수 업체가 변경되거나 계약이 종료될 때도 문제가 발생한다. 기존 개발사가 사용한 라이브러리와 빌드 환경, 구성 요소 간 관계를 제대로 인계하지 않았다면 신규 업체가 시스템을 분석하는 데 상당한 시간이 필요할 수 있다.
따라서 외주 개발 계약에는 소스 코드와 기술 문서뿐 아니라, 필요한 범위의 SBOM 제공과 갱신, 취약점 통보, 구성 요소 변경 이력 관리 등을 포함하는 방안을 검토할 필요가 있다.
셋째, 공급망 위험은 개별 시스템에만 머물지 않는다
기업은 하나의 시스템을 운영하더라도 인증 서비스, 데이터베이스, 외부 API, 공통 라이브러리, 클라우드 플랫폼 등 여러 구성 요소에 의존한다. 이 중 하나에 문제가 발생하면 연계된 서비스에도 영향이 전파될 수 있다.
유럽연합의 ICT 공급망 보안 툴박스도 중요 공급자에 대한 위험 평가, 공급망 위험 완화, 고위험 공급자에 대한 의존도 관리 등 폭넓은 대응 방안을 다루고 있다. SBOM이 소프트웨어 내부의 구성 요소를 파악하는 수단이라면, 공급망 보안 관리는 공급자와 기술 의존성까지 포함해 위험을 관리하는 더 큰 체계라고 볼 수 있다.
4. 기업 IT 운영에서 SBOM은 어떻게 활용되는가
SBOM을 도입하는 목적은 목록을 만들어 보관하는 데 있지 않다. 실제 운영 과정에서 취약점 대응 시간을 줄이고, 시스템 변경에 따른 위험을 파악하며, 공급업체 관리의 투명성을 높이는 데 의미가 있다.
활용 사례 1. 취약점 발생 시 영향 시스템을 신속하게 파악
특정 오픈소스 라이브러리에서 새로운 취약점이 공개되었다면, IT 운영 조직은 먼저 해당 구성 요소를 사용하는 시스템이 있는지 확인해야 한다.
SBOM과 취약점 정보를 연계하면 구성 요소 이름과 버전을 기준으로 영향 가능성이 있는 시스템을 찾아낼 수 있다. 이후 실제 사용 여부와 노출 조건, 시스템 중요도 등을 추가로 검토해 대응 우선순위를 결정한다.
다만 SBOM에 구성 요소가 포함되어 있다는 사실만으로 실제 공격에 노출되어 있다고 단정할 수는 없다. 해당 기능이 실행되는지, 취약한 코드 경로가 사용되는지, 외부에서 접근 가능한지 등을 함께 확인해야 한다.
활용 사례 2. 외주 개발 산출물의 품질과 보안 검증
신규 업무 시스템을 구축하거나 대규모 기능 개선 프로젝트를 진행할 때, 납품받은 소프트웨어의 구성 요소 정보를 확인하면 운영 단계의 관리 기반을 확보할 수 있다.
예를 들어 다음과 같은 항목을 검수 기준에 포함할 수 있다.
- 합의된 형식의 SBOM이 제출되었는가
- 주요 구성 요소와 버전 정보가 확인되는가
- 알려진 취약점과 라이선스 관련 위험을 검토했는가
- 실제 납품 버전과 SBOM이 일치하는가
- 운영 중 구성 요소가 변경될 때 갱신할 절차가 있는가
이러한 기준은 외주 개발사를 불필요하게 통제하기 위한 것이 아니다. 기업이 비용을 지불하고 인수한 시스템을 장기적으로 운영할 수 있도록 필요한 정보를 확보하는 것이다.
활용 사례 3. 시스템 변경과 장애 대응의 정확도 향상
공통 라이브러리나 기반 프레임워크를 변경할 때는 해당 요소에 의존하는 시스템을 확인하는 작업이 중요하다. 구성 요소와 시스템 간 관계가 관리되어 있다면 변경 영향 분석에 필요한 정보를 더 빠르게 확보할 수 있다.
이는 보안 사고뿐 아니라 일반적인 유지보수와 장애 분석에도 도움이 된다. 다만 SBOM만으로 모든 런타임 의존성이나 실제 운영 구성을 파악할 수 있는 것은 아니므로, 자산 관리 데이터와 배포 정보, 애플리케이션 아키텍처 자료 등을 함께 활용하는 것이 바람직하다.
5. SAP ERP와 사내 업무 시스템에도 적용할 수 있을까
SBOM을 개발 조직만의 과제로 생각하기 쉽지만, 실제로는 전사 IT 운영 조직과 정보보호 조직이 함께 접근해야 효과를 높일 수 있다. 특히 SAP ERP와 회계·자산·인사 시스템, 사내 포털처럼 업무 연계가 복잡한 환경에서는 시스템별 책임과 구성 정보가 명확해야 한다.
SAP ERP와 상용 솔루션
상용 ERP는 제품 공급자가 제공하는 구성 정보와 보안 권고, 패치 정책, 지원 범위를 기준으로 관리하는 것이 기본이다. 상용 솔루션의 모든 내부 구성 요소를 고객사가 직접 SBOM으로 생성하거나 수정할 수 있는 것은 아니다.
따라서 기업은 공급자가 제공하는 보안 문서와 구성 정보, 패치 및 취약점 공지, 지원 종료 일정을 확보하고 계약상 제공 가능한 SBOM이나 관련 정보를 확인하는 방식으로 접근해야 한다. ERP와 연계되는 별도 웹 애플리케이션이나 커스텀 개발 모듈은 기술 구조에 맞춰 별도의 구성 요소 관리 체계를 마련할 수 있다.
사내 포털과 자체 개발 시스템
웹 포털, 인사 시스템, 전자결재, 업무 자동화 프로그램 등 자체 개발하거나 외주 개발한 애플리케이션은 SBOM 적용의 출발점으로 삼기 좋다. 소스 코드와 빌드 환경에 접근할 수 있다면 개발 도구를 활용해 구성 요소 목록을 생성하고, 버전 관리와 취약점 점검을 연결할 수 있다.
운영 조직은 시스템별 담당 개발사, 운영 책임자, 서비스 중요도, 사용 기술, 배포 버전, 외부 연계 현황을 함께 관리하는 것이 좋다. 그래야 취약점이 발생했을 때 기술적인 목록을 실제 업무 서비스와 연결할 수 있다.
ITO 및 유지보수 업체 관리
외부 운영 인력과 개발 인력이 다수 참여하는 ITO 환경에서는 구성 요소 관리의 책임과 범위를 사전에 정의해야 한다. 누가 SBOM을 생성하는지, 누가 내용을 검증하는지, 취약점이 발견되면 누가 영향도를 분석하는지, 수정 배포 후 누가 목록을 갱신하는지를 구분해야 한다.
중요한 것은 SBOM 제출 여부만 확인하는 형식적인 절차가 아니라, 운영 중인 실제 버전과 일치하는지 확인하고 보안 조치까지 추적할 수 있는 운영 프로세스를 만드는 것이다.
6. SBOM 도입을 위한 단계별 실행 전략
모든 시스템을 대상으로 한 번에 완벽한 SBOM 체계를 구축하려고 하면 비용과 업무 부담이 커질 수 있다. 기업의 시스템 규모와 개발 환경, 보안 성숙도에 맞춰 단계적으로 적용하는 것이 현실적이다.
1단계. 관리 대상과 우선순위 선정
먼저 모든 시스템의 현황을 파악하고 중요도에 따라 대상을 분류한다. 고객 정보와 재무 데이터, 개인정보를 처리하는 시스템, 외부에 공개된 웹 서비스, 핵심 업무와 직접 연결된 시스템 등을 우선 검토할 수 있다.
기존 IT 자산 목록과 애플리케이션 목록을 활용하면 관리 대상 선정에 필요한 기초 자료를 확보할 수 있다. 단, IT 자산 목록에 소프트웨어 이름만 등록되어 있다고 해서 구성 요소까지 파악한 것은 아니다.
2단계. 개발 및 공급 형태별 수집 방식 정의
자체 개발 소프트웨어, 외주 개발 시스템, 상용 패키지, SaaS 등은 확보할 수 있는 정보가 서로 다르다. 각 유형에 맞춰 SBOM 생성, 공급자 자료 요청, 보안 공지 수집 등 적절한 방식을 정의해야 한다.
자체 개발 환경에서는 소스 코드 저장소와 빌드 파이프라인에 자동 생성 절차를 연결하는 방안을 검토할 수 있다. 외주 개발 시스템은 계약과 검수 기준에 관련 요구사항을 반영하고, 상용 솔루션은 공급자가 제공하는 정보와 보안 지원 정책을 중심으로 관리한다.
3단계. 취약점 분석과 운영 프로세스 연계
SBOM을 확보한 뒤에는 알려진 취약점 정보와 연결하고, 영향 시스템 식별과 조치 추적을 위한 절차를 마련해야 한다. 소프트웨어 구성 분석 도구인 SCA(Software Composition Analysis)를 활용하면 구성 요소 식별과 취약점 점검을 자동화하는 데 도움이 된다.
다만 도구가 표시하는 취약점 목록을 그대로 조치 순서로 사용해서는 안 된다. 취약점의 심각도와 실제 노출 가능성, 업무 중요도, 공급자의 권고 사항, 대체 버전의 안정성 등을 종합적으로 검토해야 한다.
4단계. 변경 관리와 정기 점검 체계 구축
SBOM은 한 번 생성하고 끝나는 문서가 아니다. 신규 버전 배포, 라이브러리 업데이트, 기능 개선, 개발사 변경 등 구성 요소에 영향을 주는 변경이 발생하면 관련 정보를 갱신해야 한다.
정기 점검에서는 SBOM이 실제 배포된 소프트웨어와 일치하는지, 취약점 조치가 완료되었는지, 공급자 보안 공지가 적절히 반영되었는지 확인한다. 중요한 변경은 승인 절차와 연결하고, 변경 전후 정보를 추적할 수 있도록 관리한다.
5단계. 성과를 측정하고 관리 범위를 확대
도입 성과는 SBOM 파일을 몇 개 만들었는지만으로 평가하기 어렵다. 실제 운영 위험을 얼마나 빠르게 파악하고 해결했는지, 관리 대상 시스템의 정보가 얼마나 정확한지 등을 함께 살펴야 한다.
- 중요 시스템의 SBOM 확보율
- SBOM 최신성 및 실제 배포 버전과의 일치율
- 취약점 영향 시스템 식별에 걸리는 시간
- 위험 수준별 취약점 조치 완료율
- 외주 개발 산출물의 구성 정보 제출 및 검증률
- 반복적으로 발생하는 구성 요소 관련 위험의 감소 추이
이러한 지표를 운영 회의와 보안 점검, IT 서비스 관리 프로세스에 연결하면 SBOM은 문서 관리에서 실질적인 위험 관리 수단으로 발전할 수 있다.
7. 도입 시 반드시 고려해야 할 한계와 주의사항
SBOM은 소프트웨어 공급망의 투명성을 높이는 데 유용하지만, 이것만으로 모든 보안 문제가 해결되는 것은 아니다. 효과적으로 활용하려면 몇 가지 한계를 함께 이해해야 한다.
SBOM의 정확성과 최신성
구성 요소 목록이 오래되었거나 실제 배포 버전과 다르면 분석 결과의 신뢰도가 낮아진다. 따라서 생성 시점과 대상 버전, 생성 도구, 갱신 절차를 관리하고 필요한 경우 무결성 검증을 수행해야 한다.
취약점이 있다는 사실과 실제 위험은 다르다
취약한 버전이 포함되어 있더라도 해당 기능이 비활성화되어 있거나 공격 조건이 충족되지 않을 수 있다. 반대로 취약점 목록에 나타나지 않는다고 해서 안전하다고 단정할 수도 없다. SBOM 분석 결과를 실제 시스템 구성과 운영 환경, 보안 권고에 따라 검증해야 한다.
상용 제품과 SaaS의 정보 제공 범위
공급자가 내부 구성 요소 정보를 공개하지 않거나 고객사가 직접 확인할 수 없는 경우도 있다. 이때는 공급자의 정보 제공 범위와 보안 공지 절차, 취약점 통보 및 조치 정책, 서비스 지원 조건 등을 확인해야 한다. 모든 제품에 동일한 방식으로 SBOM을 요구하기보다 제품 특성과 계약 조건에 맞춰 접근하는 것이 현실적이다.
도구 도입보다 운영 책임이 중요하다
SBOM 생성 도구를 설치하더라도 누가 결과를 검토하고, 누가 조치 결정을 내리며, 누가 완료 여부를 확인하는지 정해져 있지 않으면 실질적인 효과를 기대하기 어렵다. 정보보호, 개발, IT 운영, 구매, 외주 관리 조직의 역할과 책임을 명확히 구분해야 한다.
이번 이슈에서 얻을 수 있는 인사이트
SBOM이 주는 핵심적인 시사점은 기업의 소프트웨어 관리 범위가 완성된 제품에서 그 내부 구성 요소와 공급망으로 확대되고 있다는 것이다.
과거에는 시스템을 도입하고 정상적으로 운영하는 것이 주요 과제였다. 그러나 오늘날에는 시스템이 어떤 기술과 구성 요소에 의존하는지, 그 요소가 안전하게 유지되고 있는지, 문제가 발생했을 때 어디까지 영향을 미치는지를 함께 파악해야 한다.
특히 제조업과 대규모 기업의 IT 조직은 SAP ERP와 같은 핵심 업무 시스템뿐 아니라 사내 포털, 연계 애플리케이션, 외주 개발 프로그램, 클라우드 서비스까지 하나의 운영 생태계로 바라볼 필요가 있다. 모든 시스템의 내부 구성 요소를 동일한 수준으로 통제하기는 어렵지만, 중요도에 따라 관리 수준을 차등화하고 정보가 부족한 영역부터 개선할 수 있다.
실무적으로는 다음 세 가지 방향이 중요하다.
- IT 자산 관리의 확장: 시스템명과 서버 정보뿐 아니라 소프트웨어 구성 요소, 버전, 공급자, 의존 관계를 연결해 관리한다.
- 외주 및 공급자 관리의 고도화: 계약과 검수 단계에서 구성 정보 제공, 취약점 통보, 변경 이력 및 유지보수 책임을 명확히 한다.
- 보안과 운영의 통합: SBOM을 취약점 관리, 변경 관리, 장애 대응, IT 거버넌스와 연계해 실제 의사결정에 활용한다.
결국 중요한 것은 SBOM이라는 문서를 확보하는 데 그치지 않고, 그 정보를 활용해 위험을 빠르게 발견하고 합리적으로 대응할 수 있는 체계를 만드는 것이다. 이러한 역량은 정보보호 수준을 높이는 동시에 유지보수 효율과 시스템 운영의 예측 가능성을 높이는 기반이 될 수 있다.
마무리
소프트웨어 공급망 보안은 특정 보안 제품을 도입한다고 완성되는 과제가 아니다. 기업이 사용하는 소프트웨어의 구성과 공급 경로를 이해하고, 관련 위험을 식별하며, 변경과 취약점에 지속적으로 대응하는 운영 체계가 필요하다.
SBOM은 이러한 체계를 구축하기 위한 중요한 출발점이다. 기업은 핵심 업무 시스템과 외주 개발 애플리케이션부터 단계적으로 적용하고, 확보한 정보를 자산 관리와 취약점 대응 프로세스에 연결하는 방식으로 실효성을 높일 수 있다.
앞으로의 IT 운영 경쟁력은 단순히 많은 시스템을 안정적으로 운영하는 데서 끝나지 않을 것이다. 시스템을 구성하는 요소와 공급망의 위험을 얼마나 투명하게 파악하고, 문제가 발생했을 때 얼마나 빠르고 정확하게 대응하는지가 중요한 경쟁력이 될 것이다.
#pperi #페리 #페리솔루션 #SBOM #소프트웨어공급망보안 #오픈소스보안 #소프트웨어취약점 #SCA #소프트웨어자재명세서 #정보보호 #IT운영 #IT거버넌스 #ERP보안 #외주개발관리 #디지털전환
'Trend' 카테고리의 다른 글
| 기업의 IT 자산 관리는 왜 비용 절감을 넘어 보안과 운영 혁신의 핵심인가 (1) | 2026.10.30 |
|---|---|
| 기업의 IT 자산 관리는 왜 비용 절감을 넘어 보안과 운영 혁신의 핵심인가 (0) | 2026.10.29 |
| 기업의 데이터 백업은 왜 재해 복구 전략으로 다시 설계되어야 하는가 (0) | 2026.10.28 |
| AI 서비스가 확산되면 기업의 IT 인프라는 어떻게 달라져야 하는가 (0) | 2026.10.27 |
| AI 에이전트가 기업 업무를 실행할 때, 권한과 책임은 누가 관리해야 하는가 (0) | 2026.10.26 |