차량 보안은 왜 공급망 전체를 관리해야 할까? — Clause 7·8

현업에서 보는 ISO/SAE 21434 02

이전 편 | ISO 21434는 왜 개발보다 조직 관리부터 시작할까? — Clause 5·6

자동차 한 대에는 얼마나 많은 회사가 참여할까요?

OEM, Tier-1, Tier-2, 반도체 벤더, 오픈소스 공급사.
그리고 ECU 하나 안에도 MCU 벤더 코드, AUTOSAR BSW, 통신 스택, 오픈소스 라이브러리가 함께 들어갑니다.

현대 차량은 "하나의 회사가 만든 제품"이 아니라
"수많은 공급망이 연결된 소프트웨어 집합체"에 가깝습니다.

그래서 자연스럽게 이런 질문이 나옵니다.
"OEM이 보안을 잘해도 공급사 하나가 취약하면 어떻게 될까?"

ISO/SAE 21434 Clause 7·8은 바로 이 문제를 다룹니다.

Clause 7·8은 무엇을 말하는가

두 Clause의 역할을 한 줄로 나누면 이렇습니다.

Clause 7 Distributed Cybersecurity Activities 공급망 전체 보안 활동 분담

공급망 보안 요구사항 전달

OEM의 보안 요구사항이 Tier-1을 거쳐 Tier-2까지 끊기지 않고 전달되는 구조를 요구합니다. 요구사항이 중간에 사라지면 책임 공백이 생깁니다.

역할·책임 분담 (Interface Agreement)

누가 어떤 보안 활동을 책임지는지 공급망 계층별로 명확히 정의합니다. 사고 발생 시 "몰랐다"는 상황을 방지하는 핵심 장치입니다.

공급사 보안 역량 확인

공급사가 보안 요구사항을 이행할 역량을 갖추고 있는지 확인합니다. 선정 기준, 감사 절차, 이행 증거 제출이 포함됩니다.

보안 증거 수집·관리

Tier-2의 검증 결과가 Tier-1을 거쳐 OEM에 전달되는 증거 체계를 갖춰야 합니다. 요구사항은 아래로, 증거는 위로 흐릅니다.

Clause 8 Continual Cybersecurity Activities 출시 이후 지속 보안 활동

취약점 모니터링

출시 이후 새로운 CVE, 오픈소스 취약점, 보안 연구자 제보를 지속적으로 모니터링합니다. 차량 소프트웨어에 포함된 컴포넌트 기준으로 영향을 분석해야 합니다.

사이버보안 이벤트 평가

발견된 취약점이나 보안 이벤트가 실제 위협으로 이어질 수 있는지 평가합니다. 심각도와 영향 차종에 따라 대응 수준을 결정합니다.

취약점 대응 및 패치

평가 결과에 따라 패치·완화·허용 중 대응 방향을 결정하고 실행합니다. OTA 또는 리콜 형태로 차량에 반영됩니다.

지속적 위협 정보 반영

새로운 공격 기법, Threat Intelligence를 TARA에 반영하고 보안 요구사항을 업데이트합니다. 차량 운영 기간 내내 계속되는 활동입니다.

왜 공급망 보안이 중요해졌을까

과거 자동차 산업에서 Tier-1에 요구한 것은 명확했습니다. ECU 기능 구현, 통신 정상 동작, 성능 만족. 보안은 후순위였습니다.

하지만 차량이 인터넷에 연결되고, OTA를 지원하고, 클라우드와 통신하기 시작하면서 상황이 바뀌었습니다.

공격 표면이 된 자동차 공급망

OEM

차량 전체
아키텍처

→

TIER-1

ECU
개발

→

TIER-2

SW 모듈
공급

→

MCU Vendor

HSM
Secure Boot

→

OSS

OpenSSL
Linux

과거 공급망 요구사항

기능 동작 중심 납품

보안 요구사항 불명확

오픈소스 관리 부족

취약점 대응 책임 모호

출시 후 대응 체계 없음

21434·R155 이후

보안 요구사항 계약 반영

SBOM 관리 요구

공급사 Audit 수행

취약점 통보 체계 요구

PSIRT 운영 연결

보안에는 유명한 원칙이 있습니다. "체인은 가장 약한 고리만큼만 강하다." 자동차 공급망도 완전히 같습니다. OEM이 Secure Boot를 넣고 HSM을 써도, 공급망 아래에서 취약점이 들어오면 의미가 없습니다.

요구사항은 아래로, 보안 증거는 위로

Clause 7이 설명하는 공급망 보안의 핵심 구조는 단순합니다.

공급망 보안 활동 흐름

▼ 요구사항 전달

OEM

차량 수준 보안 목표 정의, Tier-1에 요구사항 전달

Tier-1

ECU 단위 보안 요구사항 도출, Tier-2에 전달

Tier-2

SW 모듈 보안 요구사항 수령, OSS 관리 기준 수립

OSS

사용 라이브러리 버전·라이선스·취약점 관리

▲ 보안 증거 제출

OEM

공급망 전체 증거 취합, VTA 형식승인 대응

Tier-1

ECU 보안 검증 결과, TARA, Pentest 결과 제출

Tier-2

SW 보안성 입증 문서, SBOM, CVE 대응 이력 제출

OSS

사용 컴포넌트 목록, 라이선스 정보 제공

요구사항이 Tier-2까지 전달되지 않거나, 증거가 OEM까지 올라오지 않으면 책임 공백이 생깁니다. 실제 사고가 발생했을 때 "요구사항 받은 적 없는데요"라는 상황이 반복되는 이유가 여기 있습니다.

Interface Agreement — 역할 공백을 막는 계약

Clause 7에서 요구하는 핵심 장치가 Interface Agreement입니다. 누가 어떤 보안 활동을 책임지는지를 공급망 계층별로 사전에 계약 수준에서 정의하는 문서입니다.

보안 활동	책임 주체	산출물
차량 수준 TARA	OEM	TARA 보고서, 사이버보안 목표
ECU 단위 TARA	Tier-1	ECU TARA, 보안 요구사항
Secure Boot 구현	Tier-1	구현 명세, 검증 결과
HSM 초기 설정	Tier-2 / MCU Vendor	HSM 구성 문서, 키 관리 절차
SBOM 제공	Tier-2	소프트웨어 구성 목록, 버전 정보
OTA 인증 구조	OEM	OTA 보안 아키텍처, 인증서 관리
취약점 모니터링	공급망 공동	CVE 대응 이력, 영향 분석 결과

Interface Agreement 없을 때

OEM: "왜 이 취약점이 안 막혔죠?" → Tier-1: "Tier-2 라이브러리 문제였습니다" → Tier-2: "요구사항 받은 적 없는데요"

Interface Agreement 있을 때

역할과 책임이 사전에 계약으로 정의되어 있어 사고 발생 시 대응 경로와 책임 소재가 즉시 명확해짐

공급망 보안 가시성 없을 때

OpenSSL 취약점 발표 → "우리 차량 어디에 OpenSSL 들어갔지?" → 수주간 수작업 조사

SBOM 관리 있을 때

SBOM으로 영향 차종·ECU 즉시 파악 → PSIRT 대응 착수 → OTA 패치 일정 수립

SBOM — 취약점 대응의 출발점

Clause 7·8의 흐름에서 SBOM(Software Bill of Materials)은 거의 필수 수준으로 연결됩니다. 취약점이 발생했을 때 가장 먼저 해야 하는 것이 "어떤 차량이 영향을 받는가"를 파악하는 것이기 때문입니다.

SBOM 없이 취약점 대응 — 실제 벌어지는 상황

이벤트

OpenSSL 취약점 공개 — 원격 코드 실행 가능, CVSS 9.8

OEM

"우리 차량 어디에 OpenSSL이 들어갔지?" — 전체 ECU 목록 수작업 확인 시작

Tier-1

"Tier-2가 넣었습니다" — 각 공급사에 개별 문의, 수주 소요

Tier-2

"버전 기억 안 납니다. 확인해보겠습니다" — 형상 관리 부재로 추적 불가

결과

영향 차량 파악까지 수개월. 그 사이 공격 노출 상태 지속.

SBOM이 있으면 이 과정이 완전히 달라집니다. 취약점 발표 즉시 영향 차종과 ECU를 파악하고, PSIRT 대응과 OTA 패치 일정을 수립할 수 있습니다. 그래서 지금 자동차 업계는 SBOM, Software Traceability, Vulnerability Monitoring을 갈수록 중요하게 봅니다.

R155 역시 같은 방향을 요구합니다. 핵심은 OEM이 공급망 전체를 관리해야 한다는 것입니다. Tier-1 문제, Tier-2 문제, OSS 문제라도 차량 형식승인 책임은 결국 OEM에 있습니다.

Clause 8 — 출시 이후에도 보안은 계속된다

Clause 8은 자동차 산업에 중요한 관점 변화를 담고 있습니다.

과거 자동차 산업

차량 출시 = 프로젝트 종료

출시 후 보안 업데이트 없음

취약점 대응 조직 미운영

CVE 모니터링 체계 없음

공급망 지속 관리 없음

SDV·21434 이후

차량 출시 = 운영 시작

OTA로 지속 보안 패치

PSIRT 상시 운영

CVE·Threat Intel 모니터링

공급망 지속 취약점 관리

차량 출시 이후에도 새로운 CVE 발견, 오픈소스 취약점 공개, 보안 연구자 제보, 원격 공격 가능성 발견, 인증서 갱신 필요 같은 일들이 계속 발생합니다. 이 모든 상황에 대응할 체계가 없다면 차량이 도로에서 달리는 동안 공격에 노출됩니다.

차량은 이제 "출시 후에도 계속 관리되는 소프트웨어 시스템"이 되었습니다. 그리고 SDV 시대로 갈수록 이 요구는 더 강해질 것입니다.

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

공급망 보안이 기술보다 더 어렵다 — 암호화 알고리즘을 넣는 것보다 공급사 관리, 형상 추적, SBOM 관리, CVE 대응이 더 어렵게 느껴지는 경우가 많습니다. 기술 문제가 아니라 조직·계약·운영 문제에 가깝기 때문입니다.

Tier 아래로 갈수록 보안 역량 차이가 커진다 — 대형 Tier-1은 PSIRT, Secure Coding, TARA 경험이 있지만, Tier-2·Tier-3 중에는 보안 전담 인력 자체가 없는 경우도 있습니다. 공급망 전체 수준을 맞추는 것이 현실적으로 가장 어려운 과제 중 하나입니다.

OEM마다 요구 형식이 달라 Tier-1이 가장 힘들다 — 어떤 OEM은 Cybersecurity Case를 강하게 요구하고, 어떤 OEM은 TARA 산출물 중심으로 봅니다. 여러 OEM에 동시에 ECU를 납품하는 Tier-1은 프로젝트마다 다른 형식을 맞춰야 하는 현실적인 어려움이 있습니다.

결국 "가시성(Visibility)" 싸움이 된다 — 현업에서 가장 많이 듣는 말 중 하나가 "어떤 ECU에 어떤 소프트웨어가 들어있는지 추적 가능해야 한다"입니다. SBOM, Traceability, Configuration Management의 중요성이 계속 올라가는 이유입니다.

PSIRT 운영은 만드는 것보다 유지하는 것이 어렵다 — 절차를 문서화하는 건 빠르게 할 수 있습니다. 하지만 실제 CVE가 발표됐을 때 공급망 전체와 협업하며 영향 분석, 패치 조율, OTA 배포 결정을 프로세스대로 움직이는 것은 전혀 다른 이야기입니다.

마무리

자동차 사이버보안은 ECU 하나의 문제가 아니라
공급망 전체의 문제입니다.
그리고 차량이 도로를 달리는 동안, 그 문제는 계속됩니다.

Clause 7·8은 이 현실을 설명합니다. 누가 어떤 소프트웨어를 만들었는지, 어떤 오픈소스를 사용했는지, 취약점이 생기면 누가 대응하는지를 끝까지 추적해야 하는 시대가 됐습니다.

다음 편에서는 Clause 9, 즉 Concept Phase를 다룹니다. 자동차 업계가 왜 Threat Analysis와 Attack Path를 개발 출발점으로 삼게 되었는지, TARA가 어떻게 보안 요구사항으로 이어지는지를 살펴봅니다.

핵심 요약

• Clause 7은 공급망 전체 보안 활동 분담 구조를 정의한다
• Clause 8은 출시 이후 지속 보안 활동과 운영 체계를 정의한다
• 자동차 보안은 가장 약한 공급망 고리에서 무너질 수 있다
• 요구사항은 아래로 내려가고, 보안 증거는 위로 올라온다
• Interface Agreement로 공급망 계층별 책임 경계를 명확히 해야 한다
• SBOM은 취약점 발생 시 영향 차량을 즉시 파악하기 위한 핵심 도구다
• R155 역시 공급망 전체 보안 책임을 OEM에 요구한다
• 현업에서는 기술보다 공급망 조율·가시성·Traceability 관리가 더 어렵다
• PSIRT는 만드는 것보다 공급망 전체와 연동해 실제로 운영하는 것이 어렵다

📚 현업에서 보는 ISO/SAE 21434 — 시리즈

0

ISO/SAE 21434는 도대체 무엇을 바꿨을까? — 오버뷰

1

ISO 21434는 왜 개발보다 조직 관리부터 시작할까? — Clause 5·6

2

차량 보안은 왜 공급망 전체를 관리해야 할까? — Clause 7·8  ← 현재 글

3

TARA는 왜 자동차 보안의 출발점이 되었을까? — Clause 9

4

보안 요구사항은 어떻게 ECU 설계가 될까? — Clause 10

5

차량 보안 검증은 무엇을 증명해야 할까? — Clause 11

6

양산 이후 차량 보안은 어떻게 유지될까? — Clause 12~14

ISO21434 Clause7 Clause8 SBOM 공급망보안 PSIRT 차량사이버보안 Traceability R155 취약점관리 InterfaceAgreement