오늘은 SBOM(Software Bill of Materials), 그중에서도 SBOM 증명(Attestation)과 검증(Verification)에 대해 이야기해보려고 합니다. 소프트웨어 공급망 보안이 점점 더 중요해지고 있는 요즘, SBOM은 필수적인 요소로 자리 잡고 있습니다. 하지만 단순히 SBOM을 생성하는 것만으로는 충분하지 않습니다. SBOM이 신뢰할 수 있는지, 변조되지 않았는지를 보장해야 하는데요. 바로 여기서 SBOM 증명과 검증이 필요해집니다. 오늘은 SBOM 증명이 왜 필요한지, 그리고 증명이 없어서 발생한 실제 보안 사고 사례는 어떤 것들이 있는지 먼저 알아보겠습니다.
■ SBOM 증명이란? 그리고 왜 필요할까요?
SBOM 증명이란, 이 SBOM이 특정 소프트웨어에 대해 생성된 것이 맞으며 변조되지 않았다는 사실을 입증하는 과정입니다.
예를 들어, 우리가 온라인 쇼핑을 할 때 공식 브랜드에서 물건을 샀다고 가정해봅시다. 우리가 브랜드에서 보낸 것이 맞는지 확인하려면, 공식 판매처인지(출처 확인), 제품이 개봉되지 않았는지(무결성 확인), 정품 인증 마크가 있는지(디지털 서명 확인) 등을 확인합니다.
SBOM도 마찬가지입니다.
✔️ 이 SBOM이 정말 소프트웨어 개발사에서 생성한 게 맞는가?
✔️ SBOM이 생성된 이후 변조되지 않았는가?
✔️ SBOM에 포함된 정보를 믿을 수 있는가?
이 질문에 대한 답을 할 수 있어야만 SBOM이 공급망 보안에서 제대로 역할을 할 수 있습니다. 하지만 현실에서는 SBOM 증명이 부족해서 문제가 되는 경우가 많습니다. 실제 사례를 살펴보겠습니다.
■ SBOM 증명이 없어서 발생한 대표 보안 사고 3가지
1️⃣SolarWinds 공급망 공격 (2020) – SBOM이 있었어도 증명이 없었다!
SolarWinds는 IT 관리 소프트웨어를 제공하는 회사인데요. 이 회사의 Orion 소프트웨어 업데이트가 해킹을 당했습니다. 해커는 악성코드를 추가한 후, 이를 정상적인 업데이트처럼 서명하여 배포했습니다.
✔️ SolarWinds 공급망 공격의 문제점
• SBOM이 제공되지 않아, 소프트웨어 내부에 어떤 변경이 있었는지 확인할 방법이 없었음
• 소프트웨어는 서명되어 있었지만, SBOM 자체의 무결성을 검증하는 체계가 없었음
• 공급망을 통해 18,000개 이상의 기업과 정부 기관이 감염됨
✔️ 만약 SBOM 증명이 있었다면?
• SBOM을 서명하고 검증하여, 변조된 코드가 포함되었는지 사전에 확인 가능
• SBOM 검증이 자동화되어 있었다면, 악성코드가 포함된 업데이트를 차단할 수 있었음
2️⃣Codecov CI/CD 공격 (2021) – 무결성 검증이 없던 소프트웨어
Codecov는 소프트웨어 테스트 도구를 제공하는 회사입니다. CI/CD(지속적 통합/배포) 환경에서 많이 사용되는데요, 공급망 공격을 받아 배포된 스크립트가 변조되는 사건이 발생했습니다.
✔️ Codecov CI/CD 공격의 문제점
• 공식 배포된 Bash 스크립트에 해커가 악성코드를 삽입했지만, 무결성을 검증하는 절차가 없었음
• 개발자들이 해당 스크립트를 다운로드하여 실행하면서, 인증 정보가 탈취됨
✔️ 만약 SBOM 검증이 자동화되어 있었다면?
• 배포된 스크립트의 SBOM을 검증하여, 변조 여부를 사전에 감지 가능
• CI/CD 환경에서 SBOM 검증이 자동화되었다면, 악성코드가 포함된 소프트웨어가 배포되지 않도록 차단 가능
3️⃣ 3CX 공급망 공격 (2023) – SBOM 검증이 필요했던 순간
3CX는 VoIP 솔루션을 제공하는 기업입니다. 그런데 이 회사의 소프트웨어가 해킹을 당했는데요, 공식 업데이트에 트로이 목마가 포함되었고, 이를 정상적인 업데이트로 가장하여 배포한 사건입니다.
✔️ 3CX 공급망 공격의 문제점
• 해커가 정상적인 코드에 악성코드를 삽입했지만, SBOM이 없어서 확인할 방법이 없었음
• 소프트웨어 서명이 있었지만, SBOM을 검증하는 체계가 없었기 때문에 변조된 소프트웨어가 그대로 배포됨
✔️ 만약 SBOM 검증이 자동화되어 있었다면?
• 배포 전 SBOM을 검증하여, 악성코드가 포함된 소프트웨어를 감지 가능
• CI/CD 파이프라인에서 SBOM 검증이 포함되었다면, 해커가 변조한 소프트웨어 배포를 막을 수 있었음
결국 소프트웨어의 ‘원재료 목록’인 SBOM 생성은 소프트웨어 공급망 보안의 출발점일 뿐입니다. 이 목록이 신뢰할 수 있는지 보장하려면 ‘증명과 검증’을 통한 관리가 필요합니다. 앞서 보여드린 여러 보안 사고 사례에서 보듯, SBOM 생성만으로는 공급망 공격을 완전히 막기 어렵지만, 증명·검증 프로세스를 더한다면 피해를 사전에 차단할 수 있습니다. 안심할 수 있는 소프트웨어 공급망 생태계를 위해 SBOM 증명은 더 이상 선택이 아닌 필수입니다. 2탄에서는 SBOM 증명과 검증에 대한 최신 기술 동향을 소개할 예정이니 많은 기대부탁드려요!
