소프트웨어 구성 명세(SBOM)는 더 이상 보안팀의 참고 자료가 아닙니다. 미국 연방 조달, EU 사이버복원력법(CRA), 국내 소프트웨어 공급망 보안 가이드라인이 잇달아 SBOM을 납품 조건으로 못 박으면서, 오픈소스 구성요소를 "무엇을, 어떤 버전으로, 어떤 라이선스로" 쓰고 있는지 증명하는 일이 제품 출하의 전제가 되었습니다.
이 글의 핵심
- SBOM 요구는 미국·EU·국내 순으로 확산 중이며, EU CRA는 2027년 12월 전면 적용됩니다.
- 형식(SPDX·CycloneDX)보다 중요한 것은 구성요소 식별의 정확도와 최신성입니다.
- 소스코드가 없는 바이너리·펌웨어까지 식별해야 SBOM의 빈 곳이 사라집니다.
규제가 요구하는 것
출발점은 2021년 5월 미국 행정명령 14028이었습니다. 연방 정부에 소프트웨어를 납품하는 공급자에게 SBOM 제출을 요구하면서, 같은 해 NTIA가 SBOM의 "최소 요소"를 정의했습니다. 이후 EU는 2024년 12월 발효된 사이버복원력법(CRA)으로 디지털 요소가 포함된 제품 전반에 구성요소 관리와 취약점 대응 의무를 부과했고, 국내에서도 2024년 과학기술정보통신부와 KISA가 소프트웨어 공급망 보안 가이드라인을 통해 SBOM 작성·활용 절차를 제시했습니다.
| 규제·지침 | 대상 | 시점 | 핵심 요구 |
|---|---|---|---|
| 미국 EO 14028 | 연방 조달 소프트웨어 | 2021년 5월 | SBOM 제출, 안전한 개발 관행 증명 |
| EU CRA | EU 시장에 출시되는 디지털 제품 | 보고 의무 2026년 9월 / 전면 적용 2027년 12월 | 구성요소 관리, 취약점 처리 절차, 적합성 문서 |
| 국내 SW 공급망 보안 가이드라인 | 공공·민간 SW 공급망 참여 기업 | 2024년 | SBOM 작성·검증·공유 절차 권고 |
세 규제의 공통점은 분명합니다. 어떤 오픈소스가 제품 안에 들어 있는지 목록으로 제출할 수 있어야 하고, 새 취약점이 공개되었을 때 그 목록으로 영향 범위를 즉시 판단할 수 있어야 합니다.
SBOM은 문서가 아니라 데이터다
SBOM을 한 번 만들어 PDF로 보관하는 조직이 아직 많습니다. 그러나 규제가 기대하는 SBOM은 빌드마다 갱신되고, 취약점 데이터베이스와 자동으로 대조되는 기계 판독 가능한 데이터입니다. 표준 형식은 두 가지로 수렴했습니다.
- SPDX: 리눅스 재단이 관리하는 형식으로 ISO/IEC 5962 국제 표준입니다. 라이선스 정보 표현이 정교합니다.
- CycloneDX: OWASP가 관리하는 형식으로 보안 용도에 초점을 두며, 취약점 정보(VEX)와의 연계가 자연스럽습니다.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "library",
"name": "openssl",
"version": "3.0.13",
"licenses": [{ "license": { "id": "Apache-2.0" } }],
"purl": "pkg:generic/openssl@3.0.13"
}
]
}형식보다 식별 정확도
어느 형식을 고르든 변환은 어렵지 않습니다. 문제는 그 안에 들어가는 구성요소 목록이 얼마나 정확한가입니다. 패키지 매니저 매니페스트만 읽는 방식은 개발자가 직접 복사해 넣은 코드, 벤더가 납품한 라이브러리, 빌드 과정에서 정적으로 링크된 구성요소를 놓칩니다. 이렇게 빠진 항목은 취약점 공개 시점에 그대로 사각지대가 됩니다.
바이너리까지 식별해야 하는 이유
제조업과 공공 부문에서 특히 자주 마주치는 상황이 있습니다. 협력사가 납품한 펌웨어나 실행 파일에는 소스코드가 없습니다. 컨테이너 이미지 안에 들어 있는 시스템 라이브러리도 마찬가지입니다. 소스코드 기반 SCA로는 이 영역을 확인할 수 없기 때문에, 바이너리 자체에서 오픈소스를 식별하는 기술이 필요합니다.
"SBOM의 가치는 완전성에서 나옵니다. 90%를 식별한 목록은 나머지 10%가 어디에 있는지 모른다는 뜻입니다." OSBC 기술 컨설팅팀
바이너리 식별은 컴파일이나 난독화 이후에도 남아 있는 코드의 특징값을 비교하는 방식으로 이루어집니다. 이 접근은 소스코드 접근 권한과 무관하게 동작하기 때문에, 공급망의 어느 단계에서 받은 산출물이든 같은 기준으로 검증할 수 있습니다.
관리 체계를 만드는 4단계
- 범위 정의: 어떤 제품·버전·산출물이 SBOM 대상인지 정하고, 협력사 납품물 포함 여부를 계약 조건에 반영합니다.
- 생성 자동화: 빌드 파이프라인에 SCA 도구를 연결해 릴리스마다 SBOM이 생성되도록 합니다. 사람이 손으로 만드는 SBOM은 유지되지 않습니다.
- 취약점 연동: 생성된 SBOM을 취약점 데이터베이스와 상시 대조하고, 영향받는 제품과 담당자에게 자동으로 알립니다.
- 제출·공유 절차: 고객·규제기관 요청에 대응할 형식, 공개 범위, 갱신 주기를 문서화합니다.
OSBC가 지원하는 방식
OSBC는 바이너리 SCA인 Clarity로 소스코드 없는 산출물까지 식별하고, Clarity SC로 여러 제품의 SBOM을 한 곳에서 관리하며 취약점 알림까지 연결합니다. 관리 체계 자체가 아직 없는 조직에는 ISO/IEC 5230 기반의 거버넌스 컨설팅으로 정책과 절차부터 함께 만듭니다.
SBOM 의무화는 준비된 조직에는 부담이 아니라 신뢰를 증명할 기회입니다. 규제 시점이 정해진 지금, 목록을 만드는 일보다 목록을 살아 있게 유지하는 체계를 먼저 설계하시기 바랍니다.
