SBOM만 믿으면 큰일남: 실제 바이너리가 보여주는 소프트웨어 공급망의 진짜 구성

• SBOM은 ‘우리가 넣었다고 기록한 것’을 보여주지만, 바이너리는 ‘실제로 고객에게 나간 것’을 보여줌

  • 이 차이가 별거 아닌 문서 정합성 문제가 아니라, 보안·라이선스·경영 리스크로 바로 이어진다는 게 핵심임
  • 건설 현장에서 철골마다 제철소 표식이 있고 레미콘마다 배치 번호가 붙는 것처럼, 소프트웨어도 출처를 증명할 수 있어야 한다는 비유가 꽤 직관적임

• 문제는 소프트웨어의 출발점이 항상 깨끗하지 않다는 거임

  • 오래된 빌드에서 물려받은 코드, 이전 프로젝트에서 복사해 온 코드, 협력사 SDK 안에 숨어 있는 라이브러리가 그대로 제품에 들어갈 수 있음
  • 누가 악의적으로 숨긴 게 아니라, 애초에 기록 절차를 한 번도 지나지 않은 구성 요소가 생기는 구조임

• 기록되지 않은 오픈소스는 먼저 법적 리스크를 만든다

  • 오픈소스 라이선스는 저작권 라이선스라서, 조건을 지키지 않으면 ‘허락받고 쓴 것’이 아니게 됨
  • 저작자 표시, 라이선스 전문 포함, 경우에 따라 자체 소스코드 공개 같은 의무가 붙을 수 있음
  • 규제기관이 따로 잡으러 다니는 구조는 아니지만, 권리자가 직접 문제를 제기할 수 있고 시한이나 관할 제약도 작음
  • 실제로는 인수·합병(M&A) 과정에서 인수 측 법무팀이 코드 분석을 하다가 이런 위반을 발견하는 경우가 많다고 함

• 두 번째는 더 익숙한 보안 리스크임: 모르는 구성 요소의 취약점은 고칠 수도 없음

  • 대표 사례가 2021년 12월의 로그4셸(Log4Shell)임
  • 로그4j 사용 기록을 갖고 있던 기업은 몇 시간 안에 영향 여부를 확인했지만, 기록이 없던 기업은 수주 동안 전체 소프트웨어를 뒤져야 했음
  • 이후 다른 취약점이 또 나오면 처음부터 다시 뒤지는 일이 반복됨. 특정 취약점 검색만으로는 ‘우리 제품 안에 뭐가 들어 있나’를 알 수 없기 때문임

• AI 코딩 도우미가 판을 더 복잡하게 만들고 있음

  • 예전에는 개발자가 라이브러리를 직접 찾아 내려받고 프로젝트에 추가했기 때문에, 라이선스와 기록이 같이 따라오는 경우가 많았음
  • 그런데 AI 코딩 도우미는 라이브러리를 ‘가져오는’ 게 아니라 코드를 바로 생성함
  • 그 코드 일부가 다른 사람이 저작권을 가진 공개 코드와 닮았거나 사실상 복사된 조각일 수 있는데, 라이선스 정보는 같이 오지 않음

• 인사이너리(Insignary)가 실제 애플리케이션을 분석한 결과도 꽤 빡셈

  • AI가 일부 또는 전체 코드를 작성한 앱에서는 전체 파일의 37%에서 신고되지 않은 오픈소스 코드 조각이 발견됨
  • AI가 애플리케이션 전체를 작성한 경우에는 이 비율이 56%까지 올라감
  • 기존 소프트웨어 구성 분석(SCA) 도구가 실제 존재하는 구성 요소 중 찾아낸 건 약 23%에 그쳤다고 함
  • 이유는 단순함. 많은 SCA 도구가 소스코드 자체보다 신고된 매니페스트를 읽는 방식에 기대기 때문임

• 그래서 ‘SBOM 검증’은 문서 리뷰가 아니라 실제 배포물 대조에 가까움

  • 문서에 적힌 구성과 실제 컴파일된 소프트웨어 내부 구성이 일치하는지 확인하는 과정임
  • 패키지 매니페스트에 없는 라이브러리, 코드베이스에 직접 붙여 넣은 구성 요소, 모호하게 선언된 버전이 여기서 드러남
  • 김택완 인사이너리 대표는 이걸 재무감사에 비유함. 회사가 재무제표를 직접 작성해도, 투자자는 독립 감사를 요구한다는 논리임

• 이 이슈는 이제 엔지니어링팀만의 숙제가 아니라 경영진 리스크로 올라가는 중임

  • 캐나다의 Bill C-8, 유럽의 사이버복원력법(Cyber Resilience Act) 같은 규제가 나오면서 소프트웨어 무결성이 전사 리스크 관리 영역으로 이동하고 있음
  • 제품 안에 무엇이 들어 있는지, 그 출처를 어떻게 증명할 수 있는지가 이사회 레벨 질문이 된다는 얘기임

• 이사회가 정말 물어야 할 질문은 하나로 압축됨

  • “우리 인벤토리는 완전합니다”라는 보고를 받았을 때, 다음 질문은 “그걸 어떻게 아나요?”여야 함
  • 도구 이름이나 SBOM 작성자가 중요한 게 아니라, 실제 배포물 기준으로 독립적인 증거가 있느냐가 핵심임

---

기술 맥락

• 여기서 선택의 축은 SBOM을 만들 것이냐 말 것이냐가 아니에요. 이미 많은 조직은 SBOM을 만들고 있거든요. 진짜 질문은 그 SBOM이 실제 바이너리와 맞는지 어떻게 증명하느냐예요.

• 기존 SCA 도구가 매니페스트 중심으로 동작하면 개발자가 정식 의존성으로 선언한 라이브러리는 잘 잡을 수 있어요. 하지만 복사해 넣은 코드, 레거시에서 물려받은 파일, AI가 생성한 코드 조각은 선언 자체가 없으니 빠질 수밖에 없어요.

• 그래서 바이너리 분석이 중요해져요. 개발 과정의 의도나 문서가 아니라 최종 산출물 안에 실제로 어떤 코드와 구성 요소가 들어갔는지를 보자는 접근이거든요. 고객에게 나가는 건 저장소가 아니라 빌드된 제품이니까요.

• 특히 AI 코딩 도우미가 들어오면 코드 유입 경로가 훨씬 흐려져요. 사람이 라이브러리를 추가할 때처럼 라이선스 파일과 패키지 기록이 따라오는 게 아니라, 모델이 코드 형태로 바로 뱉어내기 때문이에요.

• 운영 관점에서는 취약점 대응 속도도 달라져요. Log4Shell처럼 대형 취약점이 터졌을 때 정확한 인벤토리가 있으면 영향 범위를 바로 좁힐 수 있지만, 없으면 제품 전체를 다시 뒤져야 해요.