SBOM이 15개월 후 의무화됩니다. 당신의 SBOM은 아마 잘못되어 있을 것입니다.

2026-09-09

Ingo Kegel 작성

2027년 12월 11일부터 EU 사이버 복원력법(Cyber Resilience Act)의 SBOM 의무 사항이 적용됩니다. 즉, EU에서 소프트웨어를 배포하려면 곧 SBOM이 필요해집니다. EU만의 현상이 아니라, 이러한 선언적 접근 방식으로 공급망 보안을 강제하는 것은 전 세계적인 추세입니다. 미국은 2021년부터 연방 소프트웨어 공급업체에 SBOM을 요구해 왔고, CISA/NSA/FBI는 올해 7월 업데이트된 SBOM 최소 요소를 발표했습니다.

SBOM을 정확하게 작성하는 일은 쉽지 않으며, 소프트웨어와 함께 인스톨러를 배포하는 경우에는 한층 더 어려워집니다. 이제 어떻게 해야 할까요? 함께 살펴보겠습니다.

SBOM이란 대체 무엇일까요?

SBOM은 소프트웨어가 어떤 컴포넌트로 구성되어 있는지를 기계가 읽을 수 있는 형태로 나열한 목록입니다. 형식은 두 가지가 있습니다. 2017년에 시작되어 2024년에 Ecma 표준이 된 OWASP 프로젝트인 CycloneDX와, 2021년부터 ISO 표준인 Linux Foundation의 SPDX입니다. 규제 당국은 어느 쪽이든 받아들입니다.

SBOM 안에는 크게 세 가지 정보가 담겨 있습니다:

Package URL로 표현되는 컴포넌트 식별자, 예: pkg:maven/org.apache.commons/[email protected]
해시와 라이선스
어떤 컴포넌트가 어느 컴포넌트에 의존하는지를 보여 주는 의존성 그래프

SBOM을 손으로 직접 작성하는 것은 사실상 무리이며, SBOM은 도구가 생성하는 결과물입니다. 전형적인 Spring Boot 앱은 이미 100개가 넘는 전이 의존성을 끌어들입니다. 빌드 도구는 이미 전체 전이 의존성 그래프를 알고 있으므로, SBOM은 보통 플러그인이 생성합니다. JVM에서는 주로 Gradle용 cyclonedx-gradle-plugin과 Maven용 cyclonedx-maven-plugin이 사용됩니다.

왜 하필 지금일까요?

공급망에 대한 공격은 갈수록 늘어나고 있습니다. 특히 심각했던 사례들로는 2024년 3월 거의 모든 사람이 배포하는 라이브러리인 xz-utils의 백도어가 있습니다. 2025년 9월에는 npm에서 chalk/debug 유지보수자 피싱이 있었고, 단 일주일 뒤에는 Shai-Hulud, 즉 Maven Central으로까지 번진 최초의 자기 복제 npm 웜이 나타났습니다.

Sonatype은 2025년 한 해에만 거의 50만 개에 달하는 신규 악성 패키지를 기록했습니다. LLM의 사이버 공격 능력이 높아지면 이러한 상황은 더욱 악화될 것이므로, 지금 당장 대응책을 강화해야 합니다.

SBOM은 만능 해결책은 아니지만, 소프트웨어가 어떤 의존성을 실어 배포하는지 즉시 확인할 수 있게 해 주므로 외부 위협에 최소한의 지연으로 대응할 수 있습니다.

그렇다면 왜 어려울까요?

SBOM을 생성하는 플러그인이 보는 것은 빌드 시점의 의존성 그래프입니다. 하지만 그것은 보통 여러분이 배포하는 대상이 아니며, SBOM은 실제로 배포하는 것을 바이트 단위까지 그대로 기술해야 합니다. 의존성 해결 이후에 일어나는 바이트 변경 변환은 하나만 있어도 이 SBOM을 무효로 만듭니다.

이러한 바이트 변경 변환에는 어떤 것들이 있을까요? 가장 단순한 예가 fat JAR입니다. 모든 의존성을 하나의 JAR로 패키징하는 순간, SBOM이 의존성마다 제공하던 해시는 모두 틀린 값이 됩니다.

하지만 인스톨러를 배포하면 상황은 더 번거로워집니다. Windows의 Authenticode 서명, macOS의 Mach-O 서명, JAR 축소와 패킹, 이 모든 과정이 해시를 변경합니다. '의존성 해결 시점'에 생성된 SBOM은 최종 아티팩트에는 언제나 맞지 않습니다.

설상가상으로, 인스톨러가 추가하는 보이지 않는 컴포넌트들도 있는데, 여러분은 이를 전혀 알지 못할 수도 있습니다. 예를 들어 Windows 런처에 포함된 네이티브 zlib 라이브러리나 인스톨러 런타임에 들어 있는 shaded JAR 등이 모두 SBOM에 빠져 있는 셈입니다.

zlib 예는 전혀 이론적인 문제가 아니며, 저희가 직접 만드는 install4j Windows 런처에서 나온 사례입니다. 이 라이브러리는 수정 후 내장되기 때문에 독립 실행형 zlib 아티팩트는 배포되지 않습니다. 따라서 정밀 스캔을 하지 않는 한 사실상 보이지 않지만, 여전히 취약점의 영향을 받을 수 있으므로 여러분의 SBOM에 반드시 포함해야 하는 대상입니다.

최종 조립자 문제

설치형 소프트웨어의 경우 인스톨러는 고객이 받게 될 결과물을 조립하는 최종 단계입니다. SBOM이 이 단계 이전에 작성되거나 이 단계를 거치지 않고 작성된다면 그것은 제품을 기술하는 것이 아니며, 현재 또는 곧 시행될 규정을 위반하게 될 가능성이 높습니다.

따라서 '최종 조립자'는 인스톨러를 빌드하는 도구이며, 이 도구는 여러분의 SBOM에 대해 무언가를 할 수 있어야 합니다. 할 수 없는 일은 SBOM 자체를 생성하는 것이고, 이는 의존성 그래프를 알고 있는 빌드 도구만이 할 수 있습니다. 대신 최소한 자체 컴포넌트에 대한 SBOM을 작성할 수 있어야 합니다. 더 좋게는 기존 SBOM에 자체 추가 사항을 증강할 수 있어야 그 SBOM을 인스톨러 안에 넣어 배포할 수 있습니다.

install4j의 SBOM 기능

install4j 13.1은 각 미디어 파일에 포함되어 배포되는 install4j 런타임 컴포넌트에 대해 JSON과 XML 형식의 CycloneDX SBOM을 생성할 수 있습니다. 생성된 파일은 <media file>.install4j_runtime.cdx.json / .xml 형태로 미디어 파일 옆에 외부 파일로 작성하거나, 배포 트리의 한 경로에 내장할 수 있습니다.

내장 경로에 SBOM이 이미 존재하는 경우(CycloneDX 사양 버전 1.2부터 1.7까지 지원), install4j는 이를 교체하는 대신 런타임 컴포넌트와 그 의존성 그래프를 병합합니다. 또한 install4j는 컴파일 과정의 모든 바이트 변경 변환(서명, 축소, 패킹)을 추적하여 해시를 다시 기록하므로, SBOM이 최종 서명된 미디어 파일과 일치하게 됩니다.