장일수 한국오픈소스협회장(스패로우 대표)
소프트웨어 자재명세서(SBOM)를 처음 접한 사람들 반응은 대개 비슷하다. “납품 시 SBOM 문서를 제출하면 되는 것 아니냐”는 것이다. 그런 생각으로는 공급망 보안 위협에 제대로 대응하기 어렵다.
SBOM은 소프트웨어(SW) 제품을 구성하는 모든 컴포넌트, 오픈소스 라이브러리, 버전, 라이선스, 의존관계를 체계적으로 정리한 명세서다. 건물 자재 목록처럼 SW 안에 어떤 부품이 들어있는지 기록하는 개념으로 이해하면 된다.
2021년 미국 바이든 행정부가 행정명령 14028호로 연방정부 납품 SW에 SBOM 제출을 의무화하면서 글로벌 의제로 떠올랐다. 미국 식품의약국(FDA)이 의료기기 SW부터 요구하기 시작했고, 유럽연합(EU) 사이버복원력법(CRA)은 올해 보안 요구사항 적용에 이어 내년부터 SBOM 제출 의무를 전면 시행한다.
왜 이렇게 됐는지는 2020년 솔라윈즈(SolarWinds) 사건이 잘 설명해 준다. 미국 공공기관들이 광범위하게 쓰던 네트워크 관리 SW인 솔라윈즈 안에 취약한 오픈소스가 들어있었고, 해커는 그 취약점을 파고들었다. 미국 전역에서 수백 곳 공공기관이 연쇄 침해를 당했다. 정부기관이나 대기업이 보안을 강화했지만 해킹에 뚫리는 많은 이유가 이와 비슷하다.
해커는 정면을 공략하지 않는다. 보안 역량이 부족한 협력업체, 그 협력업체가 아무 생각 없이 갖다 쓴 오픈소스의 취약점을 뚫고 들어온다. 공급망에서는 이렇듯 가장 약한 고리가 문제다.
국내도 공급망 위협 문제를 인지하고 보안 강화에 나서고 있다. 과학기술정보통신부, 국가정보원, 한국인터넷진흥원(KISA)이 2024년 5월 ‘SW 공급망 보안 가이드라인 1.0’을 내놨다. 올해 6월에는 범정부 ‘SW 공급망 보안 로드맵’도 발표됐다. KISA는 매년 수십억원을 SBOM 도입·운영 기업 지원에 쏟아붓고 있다. 외형은 갖춰지는 중이다. 그런데도 국내 SBOM 정착이 더디다는 이야기가 끊이질 않는다.
SBOM을 주고받는다는 개념은 단순해 보이지만 구현은 전혀 단순하지 않다. 대형 수요기업은 거래하는 SW 납품 기업이 수천 곳 수준이고, 거래 기업마다 제각각 여러 협력사를 두고 있다. 이들이 각 단계에서 SBOM을 생성·전달·검증하려면 공통 규약과 자동화 플랫폼이 있어야 한다. 사람 손으로 감당할 수 있는 규모가 아니다.
처음에는 ‘메일로 주고받으면 되겠지’ 싶어도, SW 버전이 바뀔 때마다 업데이트 SBOM이 다시 날아올 것이다. 한 회사에서 수백 건 거래한다고 치면 담당자가 열 명이어도 모자랄 것이다.
오픈소스 활용이 보편화되고 AI 코드 자동 생성이 일반화되면서 관리해야 할 SW 부품의 양은 폭발적으로 늘었다. SW의 80% 이상이 오픈소스로 구성되는 것으로 알려진 상황에서, AI가 생성한 코드 안에 취약한 오픈소스가 섞여드는 경우도 생긴다. 그런 SW 구성을 모르면, 취약점이 공개됐을 때 어느 제품이 영향받는지 파악하는 데만 일주일이 넘게 걸린다.
반대로 SBOM 관리 체계를 갖춘 기업은 같은 상황에서 이틀 만에 확인하고 조치를 끝낸 사례도 있다. 차이는 기술력보다 준비 여부에서 나온다.
남은 과제는 분명하다. 문서 제출 자체가 목적이 되는 규제는 형식적 체크로 끝난다. SBOM과 SW 무결성을 디지털 서명으로 연계하고, 문제가 생겼을 때 책임 소재를 명확히 묻는 구조가 있어야 기업이 진지하게 대응한다.
개발 프로세스 자동화도 빠질 수 없다. SBOM 생성과 관리가 CI/CD 파이프라인에 자동으로 연동되지 않으면, 개발자 누군가가 임의로 건드리는 순간 무결성이 깨진다.
아울러 개발 환경이 체계화되지 않은 중소 SW 개발 기업까지 포용하는 단계적 지원이 뒷받침될 필요가 있다. 이런 조치가 사회 전반에 정착되고 제대로 돌아갈 때 비로소 SBOM 정책이 실효성을 확보할 수 있을 것이다.
본 기고문은 2026년 7월 14일에 뉴스웍스에 게재된 기고이며, 전문은 아래 링크에서도 확인 가능합니다.
개인정보 침해신고센터: (국번없이)118 (privacy.kisa.or.kr)