SBOM(소프트웨어 자재명세서)이란? EU CRA 의무화·악성 패키지 급증으로 본 2026 소프트웨어 공급망 보안 완전 가이드

SBOM(소프트웨어 자재명세서)이란 무엇이고 왜 2026년 기업 보안의 필수 조건이 되었나요?

소프트웨어 공급망 보안(Software Supply Chain Security)의 출발점은 우리 시스템에 어떤 부품이 들어 있는지 목록으로 아는 것, 즉 SBOM(Software Bill of Materials, 소프트웨어 자재명세서)입니다. 2025년 한 해에만 45만 4,600개의 신규 악성 오픈소스 패키지가 적발됐고 그중 99% 이상이 npm에 집중됐는데요. EU 사이버복원력법(CRA)은 2026년 9월부터 악용 취약점의 24시간 내 신고를 의무화했고, 2027년 12월부터는 SBOM 작성이 사실상 강제됩니다. 침해 사고의 30%가 제3자 경유로 발생하는 지금, SBOM 기반 공급망 관리 체계를 갖추는 것이 기업 사이버 보안 전략의 첫 단추입니다.

라이브러리 하나가 뚫리던 날, 우리 팀이 겪은 일
SBOM이란 무엇인가요: 소프트웨어의 성분표
2026년 소프트웨어 공급망 공격, 숫자로 보면
EU CRA와 국내 SW 공급망 보안 제도, 무엇이 달라지나
SBOM 도입 실전 가이드 4단계
FAQ
같이 읽으면 좋은 것들

라이브러리 하나가 뚫리던 날, 우리 팀이 겪은 일

2026년 3월 31일 아침, 자바스크립트 개발자라면 모를 수 없는 HTTP 라이브러리 axios의 메인테이너 계정이 탈취돼 악성 버전이 배포됐다는 소식이 퍼졌습니다. 취재차 만난 한 국내 커머스 기업의 보안 담당자는 그날을 이렇게 회상했는데요. "슬랙에 첫 공유가 뜬 게 오전 9시 40분이었어요. 첫 질문은 단순했습니다. 우리 서비스 중에 axios 쓰는 게 몇 개냐. 그런데 그 단순한 질문에 아무도 바로 답을 못 했습니다."

이 회사는 마이크로서비스 60여 개를 운영하고 있었습니다. 저장소마다 package-lock.json을 grep으로 뒤지는 수작업이 시작됐고, 전수 확인까지 꼬박 이틀이 걸렸습니다. 직접 의존성만 확인해서 될 일도 아니었는데요. axios를 직접 설치하지 않았어도 다른 패키지가 내부적으로 끌어다 쓰는 간접 의존성이 훨씬 많았기 때문입니다. 결과적으로 영향받는 버전은 없었지만, 담당자는 "없다는 걸 확인하는 데 이틀이 걸렸다는 사실 자체가 사고였다"고 말했습니다.

이 경험이 소프트웨어 공급망 보안의 본질을 보여줍니다. 문제는 취약점 자체가 아니라, 내가 무엇을 쓰고 있는지 모른다는 것입니다. SBOM이 있었다면 같은 질문의 답을 쿼리 한 번으로, 몇 분 안에 얻을 수 있었을 텐데요. 이 회사는 사고 후 전사 SBOM 자동 생성 파이프라인을 구축했고, 지금은 신규 취약점 공개 시 영향 범위 확인에 10분이 걸리지 않는다고 합니다.

SBOM이란 무엇인가요: 소프트웨어의 성분표

한 줄로 요약하면 SBOM은 소프트웨어를 구성하는 모든 컴포넌트와 버전, 라이선스, 의존 관계를 기계가 읽을 수 있는 형식으로 정리한 명세서입니다. 가공식품 뒷면의 성분표와 같은 역할을 하는데요. 소비자가 알레르기 성분을 확인하듯, 기업은 SBOM으로 특정 취악점이 포함된 컴포넌트가 어디에 들어 있는지 즉시 확인할 수 있습니다.

현대 소프트웨어는 조립품입니다

오늘날 상용 소프트웨어의 대부분은 직접 작성한 코드보다 오픈소스 컴포넌트의 비중이 큽니다. 하나의 웹 애플리케이션이 수백에서 수천 개의 패키지에 의존하는 것이 보통이고, 그 의존성의 의존성까지 내려가면 개발자 본인도 전체 목록을 파악하기 어렵습니다. 조립품의 시대에 부품 목록 없이 리콜을 하겠다는 것은 애초에 성립하지 않는 이야기인데요. SBOM은 이 조립 구조를 투명하게 만드는 최소한의 장치입니다.

표준 포맷: SPDX와 CycloneDX

SBOM은 손으로 쓰는 문서가 아니라 빌드 과정에서 자동 생성되는 데이터입니다. 국제적으로 통용되는 포맷은 크게 두 가지입니다.

구분	SPDX	CycloneDX
주관	리눅스 재단 (ISO/IEC 5962 표준)	OWASP
강점	라이선스 관리·법적 컴플라이언스	보안 취약점 연계·경량 구조
형식	JSON, YAML, RDF 등	JSON, XML
활용	대규모 조직의 자산·라이선스 관리	DevSecOps 파이프라인 통합

여기에 VEX(Vulnerability Exploitability eXchange)라는 보조 문서가 함께 쓰입니다. SBOM이 "이 컴포넌트가 들어 있다"를 말한다면, VEX는 "그 취약점이 실제로 악용 가능한 상태인지"를 말해 주는데요. 취약점이 포함돼 있어도 해당 코드 경로가 호출되지 않으면 위험이 없을 수 있기 때문에, 두 문서를 함께 써야 불필요한 패치 소동을 줄일 수 있습니다.

2026년 소프트웨어 공급망 공격, 숫자로 보면

핵심은 공급망 공격이 더 이상 예외적 사건이 아니라 통계적 상수가 됐다는 점입니다. 소나타입(Sonatype)의 2026년 소프트웨어 공급망 현황 보고서에 따르면 2025년 한 해 동안 새로 적발된 악성 오픈소스 패키지는 45만 4,600개로 전년 대비 75% 늘었고, 누적 차단 건수는 123만 개를 넘어섰습니다. 리버싱랩스(ReversingLabs)도 같은 기간 악성 패키지 탐지가 73% 증가했다고 발표했는데요. 두 조사 모두에서 npm 생태계가 전체 오픈소스 악성코드의 99% 이상을 차지했습니다.

공격은 더 정교해지고 있습니다

Shai-Hulud 웜(2025년 9월): 최초의 자기복제형 npm 악성코드입니다. 탈취한 npm 인증 토큰으로 메인테이너의 다른 패키지에 스스로를 심는 방식으로 며칠 만에 500개 이상 패키지를 감염시켰습니다.
IndonesianFoods 캠페인: 7초마다 자기복제하며 16만 9,538개의 패키지를 쏟아내 탐지 체계를 마비시키려 했습니다.
국가 배후 공격: 북한 라자루스(Lazarus) 그룹 연계 패키지만 800개 이상 확인됐고, 이 중 77%는 정보 탈취와 백도어 등 2개 이상의 위협 기능을 함께 담고 있었습니다.

유입 경로는 생각보다 평범합니다

거창한 해킹만 있는 것이 아닙니다. 가장 흔한 수법은 인기 패키지와 이름이 한 글자 다른 가짜를 올려 두는 타이포스쿼팅인데요. 개발자가 오타 한 번으로 악성 패키지를 설치하게 만드는 방식입니다. 여기에 관리가 소홀해진 프로젝트의 메인테이너 권한을 넘겨받아 정상 패키지를 오염시키는 방식, 빌드 서버의 인증 토큰을 훔쳐 배포 채널 자체를 장악하는 방식이 더해집니다. 공통점은 개발자의 신뢰를 그대로 악용한다는 점입니다. 어제까지 안전하던 패키지가 오늘 위험해질 수 있기 때문에, 설치 시점의 일회성 검사만으로는 방어가 되지 않습니다. 지속적으로 목록을 갱신하고 대조하는 체계, 즉 SBOM 기반 운영이 필요한 이유가 여기에 있는데요. 도입할때 이 지점을 놓치면 SBOM이 서랍 속 문서로 전락하기 쉽습니다.

피해 비용도 최고 수준입니다

베라이즌 2025 데이터 침해 조사 보고서(DBIR)는 전체 침해 사고의 30%에 제3자가 개입됐다고 집계했습니다. 전년 15%에서 두 배로 뛴 수치인데요. IBM의 2025년 데이터 침해 비용 보고서는 공급망 침해의 평균 피해액을 491만 달러, 식별부터 억제까지 걸리는 기간을 267일로 산정했습니다. 조사 대상 침해 유형 가운데 가장 긴 잠복기입니다. 공격자는 하나의 패키지를 뚫어 수천 개 조직에 동시에 들어가는데, 방어자는 자기 시스템에 그 패키지가 있는지조차 모르는 비대칭이 이 숫자의 배경입니다.

EU CRA와 국내 SW 공급망 보안 제도, 무엇이 달라지나

결론부터 말하면 SBOM은 권장 사항에서 법적 의무로 넘어가는 중입니다. EU 사이버복원력법(Cyber Resilience Act, Regulation (EU) 2024/2847)은 디지털 요소를 포함한 제품 전반에 보안 요구사항을 부과하는 최초의 수평적 규제인데요. EU 시장에 하드웨어나 소프트웨어를 판매하는 기업이라면 소재지와 무관하게 적용받습니다. 한국 기업도 예외가 아닙니다.

시점	의무 사항
2026년 9월	악용되는 취약점·중대 침해사고를 ENISA에 24시간 내 신고
2027년 12월	전면 시행: SBOM 작성, 수명주기 보안 관리, 기술문서 10년 보존

CRA가 요구하는 SBOM은 기계 판독 가능한 통용 포맷으로 최소한 최상위 의존성을 포함해야 하고, 관련 문서는 제품 출시 후 10년간 보존해야 합니다. 위반 시 과징금 규모가 크기 때문에 유럽 수출 비중이 있는 제조·소프트웨어 기업은 지금부터 준비해야 2027년 일정을 맞출 수 있습니다.

준비 항목은 명확한 편입니다. 우선 자사 제품이 CRA의 적용 대상인 디지털 요소 포함 제품에 해당하는지 분류하고, 제품별로 SBOM 생성 체계와 취약점 처리 절차, 보안 업데이트 제공 계획을 문서화해야 합니다. 신고 의무는 전면 시행보다 1년 이상 앞선 2026년 9월에 먼저 시작된다는 점도 놓치기 쉬운 부분인데요. 이미 시장에 나가 있는 제품도 신고 대상에 포함되므로, 출시된 제품의 취약점 모니터링 체계를 먼저 점검하는 것이 순서입니다.

국내도 움직이고 있습니다. 국가정보원·디지털플랫폼정부위원회·과학기술정보통신부·KISA가 2024년 5월 공동 발표한 SW 공급망 보안 가이드라인은 SW 구성요소 식별, 오픈소스 사용 현황 관리, 단계별 변경 이력 추적, 취약점 영향 분석 체계를 요구합니다. 2026년 4월에는 과기정통부와 KISA가 SBOM 기반 공급망 보안 모델 구축 사례집을 발간해 산업별 적용 사례를 공개했고, 정부는 공급망 보안을 단계적으로 제도화하는 로드맵도 예고한 상태인데요. 공공 조달에 SBOM 제출이 요구되는 흐름은 미국 행정명령 14028 이후 글로벌 표준 궤도에 올라 있습니다.

SBOM 도입 실전 가이드 4단계

한 줄 요약: 도구 도입보다 범위 설정이 먼저입니다. 처음부터 전사 적용을 노리기보다 핵심 서비스 한두 개로 시작해 파이프라인을 검증하고 확장하는 편이 실패 확률이 낮습니다.

1단계: 자산 파악과 파일럿 범위 선정

가장 중요한 서비스, 혹은 외부 노출이 큰 서비스를 파일럿으로 정합니다. 해당 저장소의 언어·패키지 매니저(npm, pip, Maven 등)를 정리하면 필요한 도구가 자연스럽게 좁혀지는데요. 이 단계에서 조달·계약 부서와 함께 외부 공급 소프트웨어의 SBOM 제출 요구 여부도 검토해야할 부분입니다.

2단계: 빌드 파이프라인에 자동 생성 통합

Syft, Trivy, CycloneDX 생성기 같은 오픈소스 도구를 CI/CD에 붙이면 빌드마다 SBOM이 자동으로 만들어 집니다. 핵심은 일회성 스냅샷이 아니라 릴리스마다 갱신되는 체계를 만드는 것입니다. 수동 작성은 유지가 안 되기 때문에 사실상 의미가 없습니다.

3단계: 취약점 매칭과 VEX 운영

생성된 SBOM을 취약점 데이터베이스와 상시 대조해, 새 CVE가 공개되면 영향받는 서비스가 자동으로 식별되게 합니다. 이때 VEX로 실제 악용 가능성을 판정하는 절차를 붙이면 대응 우선순위를 정할수 있습니다. 모든 취약점을 다 고치는 것이 아니라 악용 가능한 것부터 고치는 것이 현실적인 운영인데요. 앞서 소개한 커머스 기업처럼 영향 범위 확인 시간을 이틀에서 10분으로 줄이는 것이 이 단계의 목표입니다.

4단계: 공급망 전체로 확장

내부 개발물을 넘어 외부 벤더 소프트웨어, 컨테이너 이미지, AI 모델 의존성까지 SBOM 관리 대상을 넓힙니다. 계약서에 SBOM 제출 조항을 넣고, 신고 의무가 있는 규제(CRA 등) 대응 절차와 연결하면 공급망 보안이 일회성 프로젝트가 아닌 상시 운영 체계로 자리잡습니다.

FAQ

SBOM 도입이 어렵지 않나요? 전담 인력이 필요한가요?

생성 자체는 어렵지 않습니다. Syft나 Trivy 같은 무료 도구를 CI에 한 줄 추가하는 수준으로 시작할 수 있고, 파일럿 구축은 소규모 팀 기준 몇 주면 충분합니다. 어려운 부분은 생성이 아니라 취약점 매칭·대응 프로세스 운영이므로, 기존 보안 담당자의 업무 흐름에 통합하는 설계가 더 중요합니다.

SBOM만 만들면 공급망 공격을 막을 수 있나요?

아닙니다. SBOM은 탐지와 대응 속도를 높이는 가시성 도구이지 차단 도구가 아닙니다. 악성 패키지 유입을 막으려면 레지스트리 프록시, 패키지 평판 검사, 의존성 고정(lockfile) 같은 예방 통제와 함께 써야 합니다. 다만 사고 발생 시 영향 범위를 며칠이 아니라 몇 분 만에 확인하게 해 준다는 점에서 비용 대비 효과가 가장 확실한 기반 투자입니다.

우리는 EU에 수출하지 않는데 CRA를 신경 써야 하나요?

직접 적용은 없더라도 준비할 가치가 있습니다. 글로벌 고객사가 계약 조건으로 SBOM을 요구하는 사례가 늘고 있고, 국내도 SW 공급망 보안 가이드라인과 제도화 로드맵으로 같은 방향으로 가고 있습니다. 공공 조달이나 대기업 협력사 요건에 SBOM이 포함되는 시점에 급하게 시작하면 비용이 훨씬 커집니다.

기존 취약점 점검(SCA 도구)과 SBOM은 무엇이 다른가요?

SCA(소프트웨어 구성 분석)가 스캔 시점의 진단이라면, SBOM은 릴리스마다 남는 공식 기록입니다. SCA 도구 상당수가 SBOM을 생성·소비하는 방향으로 진화하고 있어 둘은 대체가 아니라 결합 관계인데요. 규제 대응 관점에서는 기계 판독 가능한 표준 포맷(SPDX·CycloneDX)으로 명세를 보존하는 SBOM 쪽이 필수 요건입니다.

AI 코딩 도구가 만든 코드도 SBOM으로 관리되나요?

AI가 제안한 코드가 끌어오는 패키지도 빌드에 포함되면 SBOM에 잡힙니다. 오히려 AI 도구가 존재하지 않는 패키지명을 제안하는 것을 노린 슬롭스쿼팅(slopsquatting) 공격이 등장하면서, 의존성 목록을 자동으로 검증하는 SBOM 파이프라인의 중요성이 더 커졌습니다.