SDV시대, SBOM이 자동차 공급망 보안의 출발점이 되는 이유
한 자동차 소프트웨어 프로젝트에서 보안팀이 긴급 알림을 받았습니다.
문제가 된 것은 널리 쓰이는 오픈소스 라이브러리의 특정 함수였습니다. 외부 공격자가 이 함수를 악용하면 시스템 내부 정보를 읽거나 비정상 동작을 일으킬 수 있다는 내용이었습니다. 처음에는 단순해 보였습니다.
“문제가 된 오픈소스 라이브러리를 쓰는 프로젝트만 찾으면 되겠지.”하지만 실제 확인은 쉽지 않았습니다.
패키지 목록에는 해당 오픈소스 이름이 없었습니다. 소프트웨어자재명세서(SBOM)에도 표시되지 않았고, 개발 문서에도 사용 기록이 남아 있지 않았습니다.
그렇다면 안전한 것일까요?
아니었습니다. 과거 한 개발자가 오픈소스 전체를 가져온 것이 아니라, 그 안에 있는 함수 몇 개만 복사해 프로젝트에 붙여 넣은 것이 문제였습니다. 이후 이 코드는 조금 수정돼 회사가 직접 만든 코드처럼 사용되고 있었습니다. 겉으로 보면 자체 개발 코드였습니다. 하지만 그 안에는 취약한 오픈소스 코드의 흔적이 남아 있었습니다.
보안팀은 다시 코드를 하나씩 추적해야 했습니다. 이 코드가 어느 프로젝트에 들어갔는지, 어느 제품에 쓰였는지, 어느 버전에 포함됐는지, 어느 공급사가 만든 코드인지 확인해야 했습니다.
취약점은 이미 공개됐고, 공격자는 그 정보를 분석하고 있을 가능성이 있었습니다. 하지만 보안팀은 가장 중요한 질문에 곧바로 답하지 못했습니다.
“이 위험한 코드가 우리 제품 어디에 들어가 있는가?”
이 장면은 오늘날 자동차 소프트웨어 보안의 현실을 보여줍니다. 자동차가 소프트웨어로 움직이는 시대에는 취약점 하나도 단순한 코드 문제가 아닙니다. 어느 부품에 들어갔는지, 어느 차량에 영향을 주는지, 어느 공급망을 통해 들어왔는지까지 확인해야 하는 공급망 보안 문제가 됩니다.
미국 자동차 보안 현장에서도 같은 고민
이런 문제는 최근 미국 자동차 사이버보안 현장에서도 확인됐습니다. 2026년 3월 미국 미시간주 앤아버에서 열린 16th Michigan Automotive Cybersecurity Event에서 래브라도랩스가 만난 글로벌 자동차·제조·기술 기업 관계자들은 단순한 취약점 탐지를 넘어 더 구체적인 질문을 던졌습니다.
“공급망을 통해 들어온 소프트웨어 안에 무엇이 포함돼 있는가?”
“오픈소스 취약점이 발견되면 어떤 차량과 부품이 영향을 받는가?”
“패키지 목록에는 없지만 코드 안에 복사된 취약한 함수까지 찾을 수 있는가?”
“미국과 유럽의 보안 규제에 맞춰 SBOM을 어떻게 만들고 관리해야 하는가?”
현장에서 특히 관심을 끈 것은 두 가지였습니다.
첫째는 코드 지문 분석과 스니펫 단위 탐지였습니다. 스니펫은 코드 조각을 뜻합니다. 오픈소스 전체가 아니라 함수 몇 개만 복사돼 들어간 경우, 일반적인 분석 방식으로는 찾기 어렵습니다. 하지만 실제 제품 안에는 취약한 코드가 남아 있을 수 있습니다.
둘째는 소프트웨어자재명세서(SBOM) 생성 이후의 관리였습니다. 현장에서 만난 고객들은 SBOM을 한 번 만드는 것보다, 완성차 기업과 여러 단계의 공급사 사이에서 SBOM을 주고받고, 취약점과 연결해 계속 관리하는 체계가 더 중요하다고 봤습니다.
자동차 공급망은 복잡합니다. OEM, Tier-1, Tier-2, 소프트웨어 기업, 반도체 기업이 연결됩니다. 각 기업의 역할과 책임도 다릅니다. 이 때문에 공급사 계층별로 유연하게 관리할 수 있는 SBOM 체계에 대한 관심이 높았습니다.
현장에서 확인된 메시지는 분명했습니다.
자동차 보안은 이제 취약점을 찾는 단계를 넘어, 소프트웨어 공급망 전체를 보이는 상태로 만들고 관리하는 단계로 이동하고 있습니다.
사진설명: 래브라도랩스는 미시간주 앤아버에서 열린 16th Michigan Automotive Cybersecurity Event에 참가 미국 고객의 목소리를 들었다.
자동차 보안은 ‘무엇이 들어갔는지 아는 것’에서 시작
예전 자동차는 엔진, 바퀴, 차체 같은 하드웨어가 중심이었습니다. 하지만 지금의 자동차는 다릅니다. 내비게이션, 인포테인먼트, 카메라, 센서, 배터리 관리, 자율주행 보조 기능, 통신 기능까지 수많은 기능이 소프트웨어로 움직입니다. 차량은 출고된 뒤에도 업데이트를 통해 새로운 기능을 추가하고, 보안 패치를 적용합니다. 이런 자동차를 SDV(Software Defined Vehicle)이라고 부릅니다. 쉽게 말해 소프트웨어로 기능이 바뀌고 발전하는 자동차입니다. SDV 시대의 자동차 회사와 부품사는 다음 질문에 답할 수 있어야 합니다.
이 차량 안에 어떤 소프트웨어가 들어갔는가?
그 소프트웨어는 어디서 왔는가?
취약점이 발견되면 어떤 차량과 부품이 영향을 받는가?
복사해서 붙여 넣은 코드 조각 안에 위험한 부분은 없는가?
고객사나 규제기관이 요구할 때 이를 증명할 수 있는가?
이 질문에 답하기 위한 출발점이 바로 SBOM입니다. 하나의 차량에는 인포테인먼트 시스템, 통신 모듈, 제어 소프트웨어, 센서, 배터리 관리 시스템 등 수많은 코드가 들어갑니다. 이 모든 코드를 완성차 기업 혼자 만드는 것도 아닙니다. 완성차 기업, 부품사, 반도체 기업, 임베디드 소프트웨어 기업, 오픈소스 커뮤니티가 복잡하게 연결됩니다. 이 구조 안에서 특정 오픈소스 취약점이 발견됐는데, 그 코드가 어느 부품과 어느 차량에 들어갔는지 모른다면 대응은 늦어질 수밖에 없습니다.
SDV는 소프트웨어 결함이 곧 리콜 사유가 됩니다. 수만 개 부품에 녹아든 오픈소스 라이브러리에서 CVE가 공개되는 순간, 기업은 즉시 세 가지를 따져야 합니다. 우리 차량에 해당 취약 코드가 실제로 존재하는지, 이 코드가 조향·제동 같은 핵심 기능에 영향을 미치는지, 패치가 필요한지 고려해야 합니다.
래브라도는 취약함수 코드스니펫 탐지로 치명적 CVE 코드가 사용 중인지와 어느 위치에 있는지를 알려주어 리콜 여부의 빠른 판단에 도움을 줍니다.
그래서 SDV 시대의 SBOM은 단순한 문서가 아닙니다. 자동차 소프트웨어 공급망을 관리하기 위한 기본 장부입니다. 자동차가 달리는 소프트웨어가 된 지금, 보안 경쟁력은 코드의 양이 아니라 코드를 얼마나 잘 알고, 얼마나 빠르게 대응할 수 있는가에서 갈립니다.
래브라도랩스는 자동차 보안의 핵심이 단순히 ‘취약점을 많이 찾는 것’에만 있다고 보지 않습니다. 더 중요한 것은 소프트웨어 공급망을 보이는 상태로 만드는 것입니다. 래브라도 SCA는 오픈소스 구성 요소와 취약점을 분석합니다. 특히 코드 지문 분석과 스니펫 단위 분석을 통해 일반적인 패키지 분석만으로는 찾기 어려운 코드 조각의 위험까지 확인할 수 있도록 돕습니다.
또한 SBOM SCM은 생성된 SBOM을 단순히 파일로 보관하는 데서 끝내지 않습니다. 완성차 기업, 부품사, 소프트웨어 공급사처럼 여러 기업이 연결된 환경에서 SBOM을 주고받고, 추적하고, 취약점과 연결해 관리합니다.
자동차 소프트웨어 공급망 보안은 이제 SBOM 생성에서 끝낼 수 없습니다. 래브라도랩스는 SCA 기반 오픈소스 취약점 분석부터 코드 지문 분석, 스니펫 단위 탐지, SBOM SCM 기반 공급망 관리까지 SDV 시대에 필요한 보안 체계를 설계합니다.
📌 안전한 자동차 SW 공급망 보안, 래브라도와 함께 지금 바로 시작하세요!
전화: 02-921-0419 (평일 09:00-18:00)
이메일: contact@labradorlabs.ai (1:1 데모 예약 및 견적 문의)
[참고문헌]
Automotive IQ, “16th Automotive Cybersecurity 2026,” Automotive IQ, 2026.03.
URL: https://www.automotive-iq.com/events-automotive-cybersecurity