자동차 사이버보안은 왜 공급망 전체를 봐야 할까?

차량 사이버보안 트렌드

자동차 한 대를 만들기 위해 몇 개의 회사가 관여할까요?

완성차 OEM 하나, Tier-1 수십 곳, Tier-2 수백 곳.
ECU 안에 들어가는 소프트웨어 하나에도
여러 회사의 코드와 오픈소스가 뒤섞여 있습니다.

그렇다면 이런 질문이 생깁니다.
"OEM이 아무리 보안을 잘 해도, 공급사 하나가 취약하면 어떻게 될까요?"

자동차 사이버보안이 공급망 전체를 봐야 하는 이유가 여기 있습니다.

자동차 공급망은 얼마나 복잡한가

자동차는 수만 개의 부품으로 이루어집니다. 소프트웨어도 마찬가지입니다. OEM이 직접 개발하는 소프트웨어보다 Tier-1·Tier-2·Tier-3에서 납품받는 소프트웨어가 훨씬 많습니다.

자동차 소프트웨어 공급망 구조

OEM

완성차
제조사

→

TIER-1

ECU
개발사

→

TIER-2

SW·모듈
공급사

→

MCU

반도체
벤더

→

OSS

오픈소스
라이브러리

OEM이 직접 작성하지 않은 코드가 차량 소프트웨어의 상당 부분을 차지한다

실제로 ECU 하나의 소프트웨어 스택을 뜯어보면 OEM 코드, Tier-1 개발 BSW, Tier-2 미들웨어, Tier-3 오픈소스 라이브러리가 겹겹이 쌓여 있습니다. 어느 레이어에서든 취약점이 생길 수 있습니다.

보안은 가장 약한 고리에서 무너진다

보안에서 오래된 원칙이 있습니다. "체인은 가장 약한 고리만큼만 강하다." 자동차 공급망에서 이 원칙은 매우 직접적으로 적용됩니다.

실제 시나리오 Tier-2 소프트웨어 취약점이 차량 전체로 확산되는 경로

1

Tier-2 업체가 납품한 미들웨어 라이브러리에 원격 코드 실행 취약점이 발견됩니다. 외부 보안 연구자가 CVE로 공개합니다.

↓

2

이 라이브러리는 Tier-1이 납품한 텔레매틱스 ECU에 포함되어 있습니다. 하지만 OEM은 어떤 차종의 어떤 ECU에 이 라이브러리가 들어있는지 모릅니다. SBOM이 없기 때문입니다.

↓

3

Tier-1은 패치를 개발했지만 어떤 OEM의 어떤 차량에 배포해야 하는지 추적이 안 됩니다. 계약에 보안 패치 의무가 명시되지 않았습니다.

↓

4

공격자가 CVE를 이용해 취약한 텔레매틱스 ECU를 원격으로 공격합니다. 내부 CAN 버스 접근에 성공합니다. OEM은 어떤 차량이 영향을 받는지조차 파악하지 못합니다.

이 시나리오의 핵심은 OEM이 잘못해서가 아닙니다. 공급망의 가시성이 없었기 때문입니다. 어떤 소프트웨어가 어떤 차량에 들어가 있는지 추적하지 못하면, 취약점이 발생해도 영향 범위를 파악할 수 없습니다.

R155는 공급망 전체를 책임지라고 한다

UN R155는 형식승인(VTA)의 책임을 OEM에게 부여합니다. 하지만 그 책임에는 공급망 전체가 포함됩니다. OEM이 "Tier-1이 잘못했으니 우리는 몰랐습니다"는 말이 통하지 않습니다.

R155 Annex 5에는 공급망 관리와 관련된 명확한 요구사항이 있습니다. 공급사가 납품하는 부품·소프트웨어의 사이버보안을 OEM이 관리해야 한다는 것입니다. 이것이 Tier-1·Tier-2로 보안 요구사항이 흘러내려가는 구조의 근거입니다.

OEM

차량 전체 TARA 수행 → 공급사 보안 요구사항 정의
어떤 ECU가 어떤 보안 기능을 가져야 하는지 명시. 계약서에 반영. 공급사 이행 여부 감사(Audit).

↓

Tier-1

OEM 요구사항 수령 → ECU 단위 TARA → 구현·검증 → 증거 제출
Secure Boot, SecOC, HSM 구현. V&V 결과, Pentest 결과를 OEM에 제출. 하위 공급사 관리.

↓

Tier-2

Tier-1 요구사항 수령 → SW 보안성 입증 → SBOM 제공
납품 소프트웨어의 취약점 관리. CVE 발생 시 Tier-1에 통보. 소프트웨어 구성 목록(SBOM) 제공.

이 구조에서 OEM은 직접 Tier-2·Tier-3를 관리하지 않아도 됩니다. 하지만 Tier-1이 Tier-2를 관리하고, 그 결과를 OEM에 보고하는 체계가 갖춰져야 합니다. 공급망의 각 레벨이 자기 아래 레벨을 책임지는 구조입니다.

SBOM — "어떤 소프트웨어가 들어있는지 알아야 한다"

공급망 보안의 핵심 도구 중 하나가 SBOM(Software Bill of Materials, 소프트웨어 구성 명세서)입니다. 식품의 성분표처럼, 소프트웨어에 어떤 컴포넌트가 포함되어 있는지를 목록화한 것입니다.

SBOM 없을 때	SBOM 있을 때
새 CVE 발생 시 어떤 차량이 영향받는지 모름	취약한 라이브러리를 사용하는 ECU·차종 즉시 파악
오픈소스 라이선스 위반 위험	사용 라이선스 전체 파악·관리 가능
공급사 변경 시 영향 범위 불명확	의존성 추적으로 변경 영향 사전 파악
VTA 심사에서 소프트웨어 출처 증명 어려움	VTA·규제 대응 증거 자료로 활용
패치 범위 산정 불가 → 전체 리콜 검토	영향 차량만 타깃 OTA 패치 배포 가능
PSIRT 없어 보안 사고 대응 체계 불명확	PSIRT 운영으로 CVE 발생 시 공식 대응 가능
빌드 서버·서명 키 보호 체계 없음	개발 환경 보안으로 빌드 체인 침해 위험 차단

SBOM은 이미 의료기기·항공·방산 분야에서는 오래전부터 요구되던 개념입니다. 자동차에서도 빠르게 중요성이 높아지고 있습니다. 미국 NHTSA, 유럽 ENISA 모두 차량 SBOM의 중요성을 강조하고 있으며, 일부 OEM은 이미 계약 요건으로 SBOM 제출을 요구하기 시작했습니다.

공급망 보안 요구가 현장을 어떻게 바꿨는가

R155 이전 — 기능 납품 중심

보안은 OEM이 알아서 하는 것

Tier-1은 기능 동작 여부만 납품

소프트웨어 출처 추적 불필요

취약점 발생해도 공급사 의무 없음

보안 계약 조항 거의 없음

공급사 보안 역량 평가 없음

R155 이후 — 보안 책임 공유

OEM이 공급사에 보안 요구사항 전달

Tier-1이 TARA·V&V 결과 OEM에 제출

SBOM으로 소프트웨어 구성 추적

취약점 발생 시 공급사 통보·패치 의무

계약서에 보안 요건·증거 제출 명시

공급사 보안 역량 감사(Audit) 수행

이 변화는 단순히 문서가 늘어난 게 아닙니다. 자동차 산업의 계약 관계 자체가 바뀌고 있습니다. 이제 Tier-1은 "ECU를 납품하는 회사"에서 "보안이 검증된 ECU를 납품하고 그것을 증명하는 회사"가 되어야 합니다.

오픈소스 — 공급망 보안의 숨겨진 변수

현대 차량 소프트웨어에는 상당량의 오픈소스가 포함됩니다. Linux, OpenSSL, curl, SQLite — 이름만 들어도 아는 오픈소스들이 ECU 안에 들어있습니다. 그리고 이 오픈소스들은 끊임없이 새로운 CVE가 발견됩니다.

문제는 자동차 개발 주기와 오픈소스 패치 주기가 완전히 다르다는 것입니다. IT 서버는 취약점이 발견되면 수일 내에 패치할 수 있습니다. 하지만 차량 ECU 소프트웨어는 개발·검증·양산 승인 과정이 수개월에서 수년이 걸립니다.

2021년 발견된 Log4Shell(Log4j 취약점)은 수백만 개의 서버를 위협했습니다. 만약 동일한 수준의 취약점이 차량에 탑재된 오픈소스에서 발견된다면? 어떤 차종이 영향을 받는지 파악하는 것부터 시작해야 합니다. SBOM 없이는 그 파악조차 불가능합니다.

실제 사례 — Log4Shell (CVE-2021-44228)

2021년 Log4j 취약점(Log4Shell)이 공개됐을 때 자동차 업계도 충격을 받았습니다. 이 사건이 자동차 공급망 보안에 던진 질문은 명확했습니다.

→어떤 차량 ECU에 Log4j가 들어있는지 즉시 파악하기 어려웠다

→Tier-1·Tier-2를 통해 간접적으로 포함된 경우가 있었다

→OEM조차 영향 범위를 빠르게 식별하지 못하는 사례가 발생했다

→"차량 안에 어떤 오픈소스가 들어있는가" 자체가 중요한 문제로 부상했다

이 사건 이후 자동차 업계에서 SBOM(Software Bill of Materials) 논의가 급격히 중요해지기 시작했습니다.

이것이 차량 SBOM과 취약점 모니터링 체계가 단순한 규제 대응이 아닌, 실질적인 보안 필수 요소가 되고 있는 이유입니다.

현업에서는 실제로 이렇게 경험한다

OEM마다 요구사항 수준이 달라 Tier-1이 혼란스럽다 — A OEM은 TARA 문서 형식까지 지정하고, B OEM은 보안 목표만 충족하면 방법은 자유입니다. 같은 ECU를 여러 OEM에 납품하는 Tier-1은 OEM마다 다른 형식의 보안 증거를 준비해야 합니다. 표준화된 공급망 보안 요구사항 형식이 없다는 것이 업계의 현실적 과제입니다.

SBOM 작성 자체가 새로운 공수다 — 기존에 SBOM을 관리하던 조직이 없는 경우가 많습니다. 어떤 오픈소스를 쓰는지, 어떤 버전인지, 어느 ECU에 들어가는지를 처음부터 정리하면 생각보다 많은 시간이 걸립니다. 그리고 한 번 만든 SBOM을 소프트웨어 변경 시마다 업데이트하는 체계를 갖추는 것이 더 어렵습니다.

Tier-2 이하 관리는 Tier-1의 새로운 과제다 — OEM이 Tier-1에 SBOM과 취약점 관리를 요구하면, Tier-1은 자신의 Tier-2에 같은 것을 요구해야 합니다. 하지만 Tier-2 중에는 규모가 작아 이런 요구에 대응할 역량이 없는 경우도 있습니다. 공급망의 아래로 내려갈수록 보안 역량의 차이가 큽니다.

취약점 발생 시 책임 소재 논쟁이 생긴다 — 공급사가 납품한 소프트웨어에서 취약점이 발견됐을 때, 패치 비용·OTA 배포 비용·리콜 비용을 누가 부담하는지가 분쟁이 되는 경우가 있습니다. 계약 단계에서 보안 사고 시 책임 범위를 명확히 정의하지 않으면 사고 이후 해결이 더 복잡해집니다.

마무리

자동차 한 대의 보안 수준은
가장 보안이 약한 공급사의 수준에서 결정됩니다.
OEM이 아무리 잘해도, 공급망 전체가 함께 움직이지 않으면 의미가 없습니다.

R155는 이 현실을 직시하고, OEM에게 공급망 전체의 사이버보안을 관리할 책임을 부여했습니다. 그 책임은 계약서 한 장으로 끝나지 않습니다. SBOM, 취약점 모니터링, 공급사 감사, 패치 배포 절차까지 전체 체계가 필요합니다.

자동차 산업이 소프트웨어 중심으로 전환될수록, 공급망 보안은 선택이 아닌 필수가 됩니다. 그리고 이 변화는 OEM뿐 아니라 Tier-1·Tier-2 모두에게 새로운 역량을 요구하고 있습니다.

핵심 요약

• 차량 소프트웨어는 OEM·Tier-1·Tier-2·오픈소스가 겹겹이 쌓인 구조다
• 보안은 가장 약한 공급사 수준에서 결정된다 — 공급망 전체를 봐야 하는 이유
• R155는 OEM에게 공급망 전체 사이버보안 관리 책임을 부여한다
• 요구사항은 OEM → Tier-1 → Tier-2로 흘러내려가고, 증거는 거꾸로 올라온다
• SBOM은 어떤 소프트웨어가 어디 들어있는지 추적하는 핵심 도구
• SBOM 없으면 CVE 발생 시 영향 차량 파악조차 불가능하다
• 오픈소스 취약점 모니터링이 차량 공급망 보안의 새로운 과제로 부상했다
• 계약 단계부터 보안 요건·증거 제출·사고 책임을 명확히 정의해야 한다

공급망보안 SBOM 차량사이버보안 UNECE_R155 ISO21434 Tier1보안 자동차공급망 취약점관리 오픈소스보안 CVE 자동차규제