공급망 보안 8개 과제 추진, SBOM을 만들면 기업 위험이 바로 줄어들까?

한국인터넷진흥원은 2026년 공급망 보안 모델 구축 지원사업의 8개 과제를 통해 소프트웨어 자재명세서(SBOM)와 글로벌 규제 대응 사례를 실제 기업 환경에 적용하고 연말까지 추진상황을 점검할 계획입니다. 그러나 SBOM 파일을 한 번 생성하는 것만으로 취약점 대응, 협력사 관리와 고객 통지가 자동으로 해결되지는 않습니다. 공급망 보안의 실효성은 부품 목록의 존재보다 새 취약점이 발견됐을 때 영향제품을 찾고 담당자가 정해진 시간 안에 조치할 수 있는 운영체계에서 결정됩니다.

한국인터넷진흥원과 과학기술정보통신부는 2026년 7월 10일 ‘2026년 공급망 보안 인사이트 데이’를 열고 지원사업 참여기업의 구축 방향을 공유했습니다. 행사에는 8개 과제 수행기업의 최고정보보호책임자와 경영진 등 약 40명이 참석했으며, 전년도 미국·유럽 규제 대응 사례와 SBOM 기반 우수사례, 올해 과제 추진방향이 소개됐습니다.

SBOM은 제품의 재료표에 가깝다

SBOM은 소프트웨어에 포함된 오픈소스, 상용 구성요소, 버전과 관계를 목록화한 자료입니다. 같은 라이브러리라도 버전과 빌드옵션, 사용위치에 따라 위험이 다를 수 있습니다. 단순히 파일명을 모은 목록보다 어떤 제품의 어느 버전에 포함됐는지 추적할 수 있어야 합니다.

고객이 SBOM 제출을 요구한다고 급하게 도구를 돌리면 개발자가 직접 넣은 코드, 외주 모듈, 컨테이너 이미지와 펌웨어 구성요소가 누락될 수 있습니다. 생성도구의 탐지범위와 실제 빌드체계를 비교해야 합니다.

취약점이 있다고 모두 같은 위험은 아니다

공개 취약점 데이터베이스에 특정 라이브러리의 문제가 등록돼도 회사 제품에서 취약 기능을 사용하지 않거나 외부 접근이 차단돼 있을 수 있습니다. 반대로 점수가 낮더라도 핵심 권한과 연결돼 있으면 위험이 커질 수 있습니다. 따라서 버전 일치 확인, 실행 가능성, 노출경로, 보완통제와 고객환경을 함께 평가해야 합니다.

판단 근거를 기록하지 않으면 같은 취약점 문의가 들어올 때마다 처음부터 분석하게 됩니다. ‘영향 있음’, ‘영향 없음’, ‘추가 조사’로 상태를 나누고 근거와 검토자를 남겨야 고객과 규제기관의 질문에 일관되게 답할 수 있습니다.

해외 규제 대응은 문서 형식만의 문제가 아니다

미국과 유럽 등에서 공급망 보안과 제품 사이버보안 요구가 강화되면 제조사와 소프트웨어 공급자는 구성요소 관리, 취약점 신고, 업데이트 제공과 책임자를 증명해야 할 수 있습니다. 국가·산업·계약마다 요구 형식과 보관기간이 다르므로 한 종류의 SBOM을 모든 고객에게 그대로 제출하기보다 필요한 항목과 공개범위를 확인해야 합니다.

영업비밀이 포함될 수 있다는 이유로 아무 정보도 제공하지 않으면 거래가 어려워질 수 있고, 반대로 내부 저장소 주소와 민감한 구성정보를 과도하게 공개하면 보안위험이 생깁니다. 고객용, 규제대응용, 내부 분석용 자료를 구분하고 접근권한을 설정하는 방식이 필요합니다.

협력사 계약에서 먼저 정할 항목

자사 코드만 관리해도 제품에 포함된 외주 개발물과 제3자 모듈이 빠지면 공급망 전체를 볼 수 없습니다. 신규 계약에는 구성요소 목록 제공, 취약점 통지 기한, 보안업데이트 기간, 개발 종료 후 지원, 재위탁 공개와 사고 협조 의무를 넣는 방안을 검토해야 합니다.

기존 협력사에는 일괄적으로 복잡한 문서를 요구하기보다 제품 중요도와 접근권한을 기준으로 우선순위를 정할 수 있습니다. 핵심 시스템에 들어가는 모듈, 관리자 권한을 가진 솔루션, 인터넷에 노출되는 제품부터 확인하는 것이 현실적입니다.

경영진이 봐야 할 성과지표

지원사업은 연말까지 현장실사와 중간·최종 평가를 통해 과제별 성과를 점검할 예정입니다. 기업 내부 성과도 SBOM 생성 개수보다 대응시간과 품질로 측정하는 편이 좋습니다.

• 주요 제품의 구성요소 식별률

• 취약점 발견부터 영향판단까지 걸린 시간

• 심각한 취약점의 패치·완화 완료율

• 협력사 통지 지연 건수

• 지원 종료 제품의 고객 공지 여부

• SBOM과 실제 출시 버전의 일치율

• 보안문의에 대한 증빙 제공시간

관련 Q&A

오픈소스를 쓰지 않으면 SBOM이 필요 없나요?

상용 라이브러리, 운영체제 패키지, 펌웨어와 외부 SDK도 공급망 구성요소가 될 수 있습니다. 직접 오픈소스를 설치하지 않았더라도 납품받은 모듈에 포함될 가능성이 있습니다. 고객·규제 요구와 제품 구조를 확인해 관리범위를 정해야 합니다.

SBOM을 고객에게 모두 공개해야 하나요?

제공 의무와 범위는 계약, 규제, 조달조건에 따라 달라집니다. 내부 분석용 전체 목록과 고객 제공용 정보를 구분할 수 있으며, 민감정보의 보호방식도 협의해야 합니다. 다만 영업비밀이라는 이유로 필수 요구를 무시하기보다 비밀유지, 안전한 전송과 열람권한을 함께 설계하는 편이 좋습니다.

공급망 보안은 도구 도입 프로젝트가 아니라 개발·구매·법무·고객지원이 함께 움직이는 운영체계입니다. 8개 지원과제의 성과도 실제 현장에서 취약점 대응시간과 협력사 관리가 어떻게 달라졌는지를 중심으로 봐야 합니다.