앱에도 성분표가 필요할까? 소프트웨어 공급망 보안의 뜻
내가 쓰는 프로그램 안에는 사실 다른 개발자가 만든 부품도 잔뜩 들어 있어요. 어떤 부품과 버전을 쓰는지 알아야, 취약점이 터졌을 때 바로 대응할 수 있어요.
2026. 09. 27 2020년 SolarWinds 사건에서 악성 업데이트를 설치한 고객사 수를 '1만8,000곳이 넘었다'에서 '최대 1만8,000곳으로 추산됐다'로 고쳤습니다.
3줄 요약
- 9월 17일 보안 전시회 관련 보도에서 소프트웨어 구성요소 명세서인 SBOM이 다뤄졌어요.
- SBOM은 프로그램 안에 무엇이 들어 있는지 기록하는 목록으로, 안전을 자동 보증하는 인증서는 아니에요.
- 부품 목록을 만들고 갱신하며 취약점과 연결해 대응하는 과정이 함께 필요해요.

01무슨 일인가
늘 쓰던 앱의 보안 업데이트 안내를 보면, 왜 멀쩡히 잘 돌아가는 프로그램을 또 고치나 싶죠. 화면이 잘 뜨는 것과 안쪽 구성요소에 보안 문제가 없는 것은 완전히 다른 일이거든요. 프로그램은 직접 짠 코드뿐 아니라 외부에서 가져온 구성요소까지 함께 쓰는데, 그 안의 부품을 낱낱이 파악하는 일이 바로 소프트웨어 공급망 보안의 출발점이에요.
9월 17일 국내 보안업계의 해외 전시회 참가 소식에서도 코드 검사와 SBOM을 함께 다루는 기술이 소개됐어요. SBOM, 소프트웨어 구성요소 명세서는 프로그램에 포함된 부품을 목록으로 정리한 자료고요. 식품 성분표가 재료를 알려주듯, 프로그램 안에서 어떤 구성요소와 버전을 썼는지 확인하는 용도로 쓰여요.
한국인터넷진흥원도 올해 공급망 보안 모델 구축 지원사업에서 SBOM의 생성·관리·분석과 위협 모니터링을 지원 대상으로 삼았어요. 공고에 편성된 지원 예산은 총 28억 원인데, 이건 사업 규모일 뿐 보안 사고로 발생한 피해액이나 모든 기업이 받는 지원금은 아니에요.

02왜 이렇게 됐나
소프트웨어 공급망이란 프로그램을 개발하고, 전달하고, 실제로 사용하는 과정에 얽힌 구성요소와 주체들을 통틀어 부르는 말이에요. 오픈소스, 공개된 소스코드를 정해진 조건에 따라 활용하는 소프트웨어 같은 외부 부품을 쓰면 그 부품의 관리 상태까지 제품 보안에 그대로 얽혀 들어와요. 제품 이름만 봐서는 안쪽에서 어떤 부품이 쓰이는지 전혀 드러나지 않고요.
같은 이름의 부품이라도 버전, 수정·배포된 판이 다르면 적용되는 취약점 정보부터 달라져요. 취약점은 공격에 악용될 수 있는 약점을 뜻하고요. 구성요소의 이름과 버전, 서로 의존하는 관계까지 기록돼 있으면 새 취약점 정보가 나왔을 때 내 제품에 관련 부품이 있는지 곧바로 대조해볼 수 있어요. 그러면 제품 전체를 막연히 의심하는 대신, 영향을 받을 부분을 콕 짚어낼 단서가 생기는 셈이죠.
다만 목록을 만든다고 취약점이 저절로 사라지지는 않아요. SBOM은 구성 정보를 알려주는 자료일 뿐, 실제 위험 분석과 수정은 별도 작업이거든요. 프로그램이 바뀌면 목록도 그때마다 갱신돼야 하고, 오래된 목록으로 최신 제품을 확인하면 이미 교체된 부품이나 새로 추가된 부품을 놓치게 돼요.
| 구분 | 답하는 질문 | 그 자체로 하지 않는 일 |
|---|---|---|
| SBOM | 어떤 부품과 버전이 들어 있나 | 모든 위험의 자동 제거 |
| 취약점 분석 | 알려진 약점과 관련이 있나 | 수정 완료의 보증 |
| 수정·관리 | 무엇을 바꾸고 계속 추적하나 | 처음 만든 목록의 영구 유효화 |
03이 문제는 얼마나 큰가
SBOM이 왜 필요한지는 과거 사고의 규모를 보면 더 잘 드러나요. 2021년 발견된 Log4Shell 취약점은 전 세계 디지털 자산의 약 10%에 영향을 미친 것으로 추정됐고, 공격이 절정에 달했을 때는 전 세계 기업 네트워크의 40% 이상이 공격 시도를 받았어요. 위험도를 매기는 CVSS 점수로도 최고점인 10점을 받은 취약점이었고요.
문제는 이 부품(log4j)이 워낙 널리 쓰이는 오픈소스라서, 정작 많은 조직이 자기 시스템 어디에 이 부품이 들어 있는지조차 몰랐다는 점이에요. SBOM처럼 구성요소 목록이 미리 갖춰져 있었다면, 취약점이 공개된 순간 바로 대조해 확인할 수 있었을 부분이 이렇게 뒤늦게 드러난 거예요.
이런 배경과 견주면 올해 KISA의 지원 예산 28억원은 결코 큰 액수가 아니에요. 다만 이 사업의 목적은 사고 피해를 직접 보상하는 게 아니라, Log4Shell 같은 사태가 터졌을 때 개별 기업이 자기 제품 안의 부품을 스스로 대조해볼 수 있는 관리체계를 갖추도록 돕는 데 있어요.
04지난번엔 어떻게 됐나
소프트웨어 공급망 공격이 실제로 얼마나 위험한지 보여준 대표 사례가 2020년 솔라윈즈(SolarWinds) 사건이에요. 공격자는 이 회사의 네트워크 관리 프로그램 '오리온'에 악성코드를 심어 정상 업데이트처럼 배포했는데, 이 업데이트를 설치한 고객사는 최대 1만8,000곳으로 추산됐어요.
더 심각했던 건 이 공격이 약 9개월 동안이나 발견되지 않았다는 점이에요. 그사이 미국 재무부·국무부·국토안보부 같은 정부 기관과 마이크로소프트·시스코 등 주요 기업까지 피해를 입었고, 미국 포춘500대 기업 가운데 425곳이 이 회사의 고객이었던 것으로 확인됐어요.
이 사건 이후 각국 정부와 기업들이 SBOM 같은 부품 목록 관리를 의무화하거나 권고하기 시작했어요. 공격이 어디까지 퍼졌는지 파악하는 데만 몇 달이 걸렸던 경험이, 내 제품 안에 무엇이 들어 있는지 미리 알아둬야 한다는 지금의 흐름으로 이어진 셈이에요. 이번 KISA 지원사업도 이런 국제적 흐름 위에 놓여 있는 정책이에요.
05나한테 뭐가 달라지나
일반 이용자가 모든 앱의 부품 목록을 직접 읽어야 한다는 뜻은 아니에요. 개발사와 서비스 운영 조직이 어떤 부품을 쓰는지 파악하고, 위험이 발견되면 곧바로 대응하는 관리 과정을 갖췄는지가 중요하다는 뜻이죠. 보안 설명에 'SBOM이 있다'는 말과 '취약점을 수정했다'는 말은 서로 다른 내용을 알려주고요.
업무용 프로그램을 도입하는 조직이라면 목록이 있는지뿐 아니라 관리 범위와 갱신, 대응 체계까지 나눠서 봐야 해요. 한국인터넷진흥원의 지원사업도 개발·공급 기업의 관리체계와 도입·운영 기업의 모니터링 체계를 따로 다루고요. 만들 때 한 번 확인하는 일과, 쓰는 동안 새로 나오는 위험을 계속 추적하는 일 둘 다 필요하기 때문이에요. 안전은 한 번 받은 명세서가 아니라, 그 정보를 계속 관리하고 조치하는 과정에 달려 있어요.
이것만 기억하세요
- 앱의 이름과 내부 구성요소 정보는 서로 달라요.
- SBOM 보유가 무조건 안전하다는 인증은 아니에요.
- 목록의 갱신, 위협 분석, 대응 절차, 이 세 가지가 함께 필요해요.




