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

현업에서 보는 ISO/SAE 21434 06

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

많은 사람들이 자동차 보안을 이렇게 생각합니다.

개발 완료 → 양산 → 보안 완료.

하지만 실제 차량 사이버보안의 진짜 시작은
차량이 도로에 나간 이후입니다.

새로운 CVE가 계속 발견되고, 공격 기법이 진화하고,
원격 공격 표면은 계속 늘어납니다.

현대 차량은 이제 "출시 후에도 계속 관리되어야 하는 IT 시스템"에 가까워지고 있습니다.
Clause 12~14는 바로 그 현실을 다룹니다.

Clause 12~14는 어디에 위치하는가

시리즈 전체 흐름 — 마지막 단계

Clause 5·6
조직·프로젝트

→

Clause 9
TARA

→

Clause 10
설계·구현

→

Clause 11
검증

→

Clause 12~14
양산·운영·EOL

Clause 12~14의 역할을 한 줄씩 나누면 이렇습니다.

Clause	명칭	핵심 질문
12	Post-Development Activities	양산 이후 보안을 어떻게 운영하는가?
13	Incident Response	실제 보안 사고가 발생하면 어떻게 대응하는가?
14	End of Cybersecurity Support	언제까지 보안 지원을 할 것인가?

과거 자동차

양산 후 변경 거의 없음

보안 사고 개념 약함

취약점 = 출시 후 발견 시 대응 없음

정비소 중심 대응

EOL = 부품 단종만 고려

SDV·21434 이후

OTA 지속 보안 패치

PSIRT 상시 운영

CVE 모니터링·대응 체계

Fleet 단위 원격 대응

보안 지원 종료 계획 필요

Clause 12 — 양산 이후 보안 운영

Clause 12는 차량이 출시된 이후에도 보안이 지속적으로 운영되어야 한다는 것을 요구합니다. 핵심 활동은 Vulnerability Monitoring, OTA 보안 관리, Field 모니터링, Threat Intelligence 반영입니다.

Clause 12 Post-Development Activities 양산 이후 보안 운영

Vulnerability Monitoring 필수

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

Cybersecurity Event 평가

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

OTA 보안 관리

보안 패치를 OTA로 배포하는 체계를 운영합니다. 패치 서명, 인증서 관리, 배포 전략, 실패 시 Rollback 처리가 포함됩니다. OTA 자체가 공격 표면이 되지 않도록 지속적인 보안 검증이 필요합니다.

Threat Intelligence 반영

새로운 공격 기법, 자동차 업계 보안 사고 사례를 TARA와 보안 요구사항에 반영합니다. 차량 운영 기간 내내 계속되는 활동입니다.

Vulnerability Monitoring Report WP

정기적으로 수행한 취약점 모니터링 결과 기록. 발견된 CVE, 영향 분석 결과, 대응 조치 이력이 포함됩니다.

SBOM 있을 때 vs 없을 때 — CVE 대응 현실

이벤트

OpenSSL Critical CVE 공개 — 원격 코드 실행 가능, CVSS 9.8

SBOM 없음

"우리 차량 어디에 OpenSSL 들어갔지?" → 전체 ECU 수작업 조사 → Tier-1 개별 문의 → 수주 소요 → 그 사이 공격 노출

SBOM 있음

영향 차종·ECU 즉시 파악 → PSIRT 대응 착수 → OTA 패치 일정 수립 → Fleet 배포 → 48시간 내 대응 완료

Clause 12가 요구하는 Vulnerability Monitoring은 SBOM 없이는 사실상 작동하지 않습니다. 어떤 컴포넌트가 어느 차량에 들어있는지 추적할 수 없으면 CVE가 발표돼도 영향 차량을 파악하는 데만 수주가 걸립니다.

Clause 13 — 보안 사고 대응과 PSIRT

Clause 13은 실제 보안 사고가 발생했을 때의 대응 체계를 정의합니다. 그리고 이 단계의 핵심 조직이 PSIRT(Product Security Incident Response Team)입니다.

Clause 13 Cybersecurity Incident Response 보안 사고 대응

취약점 접수 체계 필수

외부 연구자 제보, CVE 수신, 자체 발견 경로를 정의합니다. Bug Bounty, Security Contact, CVE 등록 절차가 포함됩니다. 외부로부터 보안 취약점을 접수할 수 있는 공개된 창구가 있어야 합니다.

영향 분석 및 Risk 평가

접수된 취약점이 실제 차량에 어떤 영향을 미치는지 분석합니다. 영향 차종, 공격 가능성, 피해 규모, 긴급도를 평가해 대응 우선순위를 결정합니다.

패치 개발 및 배포

대응 방향(패치·완화·허용)을 결정하고 실행합니다. OTA 배포 또는 리콜 형태로 진행됩니다. 공급망과 협력해 Tier-1·Tier-2 패치를 조율하는 과정이 포함됩니다.

외부 공개 및 CERT 협력

Coordinated Disclosure 정책에 따라 취약점 정보를 적절한 시점에 공개합니다. AutoISAC, CERT, 규제 기관과의 협력 절차가 정의되어야 합니다.

Incident Response Report WP

대응한 보안 사고의 전체 이력 기록. 접수 경위, 영향 분석, 대응 조치, 배포 결과, 재발 방지 계획이 포함됩니다.

PSIRT 취약점 대응 흐름

취약점 접수
CVE·제보·자체발견

→

영향 분석
차종·ECU·위험도

→

대응 결정
패치·완화·허용

→

패치 개발
공급망 협업

→

OTA 배포
Fleet 전체

→

종료·기록
Work Product

자동차 업계에서 PSIRT는 R155·21434 이후에야 본격적으로 논의되기 시작했습니다. IT 기업에서 오래전부터 운영해온 개념이지만, 자동차 PSIRT는 공급망 전체(OEM·Tier-1·Tier-2)와 협력해 패치를 조율하고 Fleet 전체에 배포해야 한다는 점에서 훨씬 복잡합니다.

과거 자동차 업계

취약점 공개를 최대한 억제. "우리 차량에 보안 문제 없음" 기조. 외부 제보 창구 없음. 발견돼도 리콜 여부만 고민.

21434·R155 이후

CVE 등록·Coordinated Disclosure 확산. Bug Bounty 운영 OEM 증가. AutoISAC·CERT 협력. OTA 패치 체계 구축.

자동차 업계는 폐쇄형 산업에서 운영형 보안 산업으로 이동 중입니다. 대형 OEM들은 이미 Security Contact 페이지 운영, Bug Bounty 프로그램 도입, PSIRT 조직 공식화를 진행하고 있습니다. Tier-1도 이 흐름을 따라가야 하는 시점이 됐습니다.

Clause 14 — 언제까지 보안을 지원할 것인가

Clause 14는 현실적으로 가장 어려운 문제를 다룹니다. 차량은 10~20년 운영되지만, ECU에 탑재된 소프트웨어와 하드웨어의 보안 지원 기간은 한계가 있습니다.

Clause 14 End of Cybersecurity Support 보안 지원 종료 관리

보안 지원 종료 계획 필수

언제까지 취약점 패치, OTA 지원, 인증서 갱신을 제공할지 사전에 정의합니다. 고객 공지 및 대안 제시 계획도 포함됩니다.

암호 알고리즘 수명 관리

현재 사용 중인 암호 알고리즘(RSA, ECC, AES 등)이 차량 운영 기간 동안 안전한지 평가합니다. 양자 컴퓨터 위협(PQC 전환)과 같은 장기 위협도 고려해야 합니다.

인증서 수명 및 갱신 계획

OTA 인증서, ECU 인증서, 루트 CA의 만료 일정과 갱신 절차를 관리합니다. 인증서 만료는 OTA 불가, 인증 실패, Fleet 장애로 이어질 수 있어 장기 관리 계획이 필수입니다.

Legacy ECU 대응 방침

HSM 미탑재, OTA 불가능한 구형 ECU에 대한 보안 지원 방침을 정의합니다. 패치 불가 시 Residual Risk Accept 또는 대안 완화 조치를 결정합니다.

End of Cybersecurity Support Notice WP

보안 지원 종료 시점, 범위, 영향 차량, 고객 안내 방법이 담긴 공식 문서입니다. 규제 기관 보고 의무가 생길 수 있습니다.

차량 보안 지원의 현실적 타임라인

양산 시점

차량 출시 · 보안 운영 시작

OTA 인증서 발급, PSIRT 상시 운영, CVE 모니터링 시작. 보안 지원의 출발점.

3~5년 후

MCU 벤더 지원 종료 시작

일부 MCU 벤더가 보안 패치 제공을 중단. Legacy ECU 대응 방침 결정 필요. SBOM 기반 영향 ECU 파악이 핵심.

5~7년 후

OTA 인증서 갱신 · 오픈소스 EOL

OTA 인증서 만료 도래. 일부 오픈소스 라이브러리 유지보수 종료. 인증서 갱신 실패 시 Fleet 전체 OTA 불가 위험.

10년 후

암호 알고리즘 노후화 우려 시작

현재 사용 중인 RSA-2048, ECC 알고리즘의 양자 내성 검토 필요. PQC 전환 계획 수립. 하드웨어 제약으로 교체 불가 ECU 존재.

15~20년 후

보안 지원 종료 선언

공식적인 End of Cybersecurity Support 공지. 남은 차량은 Residual Risk Accept 또는 운행 중단 권고. 규제 기관 보고 의무 발생 가능.

OTA 인증서가 만료되면 무슨 일이 생길까요? Fleet 전체가 OTA 업데이트를 받지 못하게 됩니다. 보안 패치 배포가 불가능해지고, 인증 실패로 연결 서비스가 중단될 수 있습니다. 차량 설계 초기부터 인증서 수명과 갱신 계획을 반영해야 하는 이유입니다.

SDV 시대 — 차량이 "운영 중인 시스템"이 되다

Clause 12~14가 의미하는 가장 큰 변화는 자동차 산업이 제품 판매 산업에서 운영·서비스 산업으로 이동하고 있다는 것입니다.

과거 자동차 산업

차 판매 후 관계 종료

보안 = 개발 단계만

정비소 중심 사후 대응

차량 단위 개별 관리

소프트웨어 업데이트 거의 없음

SDV 시대

차 판매 후 운영 시작

보안 = 차량 수명 전체

Fleet 원격 모니터링·대응

클라우드 기반 Fleet 관리

OTA 지속 보안 패치

실제 OEM들이 강화하고 있는 영역이 이를 보여줍니다. Vehicle SOC, Fleet Monitoring, IDS Alert 수집, OTA 보안 인프라, Backend Security, PSIRT 조직이 모두 "차량을 지속적으로 운영하는 시스템"으로 다루기 시작한 결과입니다.

자동차가 "지속적으로 운영되는 컴퓨터"가 되고 있습니다. ISO/SAE 21434 Clause 12~14는 이 변화의 방향을 보여주는 영역입니다. 그리고 이 변화는 앞으로 더 빠르게 진행될 것입니다.

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

OTA는 기능보다 운영 체계가 더 어렵다 — OTA 기술 구현보다 인증서 관리, Rollback 대응, Fleet 배포 전략, 실패 Recovery가 훨씬 어렵습니다. 특히 수백만 대 Fleet에 동시 배포할 때 실패율 관리와 단계별 롤아웃 전략이 핵심입니다.

PSIRT 운영은 생각보다 IT SOC와 비슷하다 — CVE 모니터링, Threat Intelligence 수집, Incident Tracking, Coordinated Disclosure 등 자동차 PSIRT 활동이 IT 보안 운영 조직과 거의 동일해지고 있습니다. 자동차 업계 보안 인력에게 IT 보안 운영 경험이 점점 중요해지고 있습니다.

공급망 전체 대응이 가장 어렵다 — CVE 발생 시 OEM → Tier-1 → Tier-2 → 오픈소스 공급자 전체 체인이 함께 움직여야 합니다. Tier-2가 이미 사업을 종료했거나 연락이 안 되는 경우도 실제로 발생합니다. 이것이 DIA와 공급망 관리가 초기부터 중요한 이유입니다.

Residual Risk Accept는 현실적으로 존재한다 — 모든 차량의 모든 취약점을 수정할 수는 없습니다. Legacy ECU, OTA 불가 차량, HW 제약 때문에 "이 위험은 현재 대응 불가, 허용 판단"을 내리는 경우가 실제로 있습니다. 이 판단이 문서화되고 근거가 있어야 규제 대응이 됩니다.

인증서 만료는 생각보다 빨리 온다 — 개발 초기에 설정한 인증서 유효기간이 생각보다 빨리 도래합니다. 특히 개발·테스트 단계에서 발급한 인증서가 양산 이후에도 그대로 사용되다가 만료 직전에 발견되는 경우가 있습니다. 인증서 수명 계획은 설계 초기부터 반영되어야 합니다.

시리즈를 마치며 — ISO/SAE 21434가 보여주는 변화

과거 자동차 산업은 "차를 잘 만드는 산업"이었습니다.
앞으로의 자동차 산업은
"안전하게 계속 운영하는 산업"에 가까워지고 있습니다.
ISO/SAE 21434는 단순한 규격이 아니라,
그 변화의 방향 자체를 보여주는 표준입니다.

이번 시리즈에서 다룬 내용을 돌아보면, ISO/SAE 21434가 요구하는 것은 결국 하나입니다. 자동차 보안을 우연히 잘하는 수준이 아니라, 조직 체계를 갖추고, 위협을 분석하고, 요구사항을 정의하고, 구현하고, 검증하고, 출시 후에도 지속적으로 관리하는 체계를 만들라는 것입니다.

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

0

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

1

Clause 5·6 — 왜 기술보다 조직 관리부터 시작할까? CSMS, DIA, PSIRT 기반

2

Clause 7·8 — 공급망 전체가 보안 활동에 참여해야 하는 이유. SBOM, Interface Agreement

3

Clause 9 — TARA가 자동차 보안의 출발점인 이유. Asset·Threat·Attack Path·Security Goal

4

Clause 10 — 보안 요구사항이 ECU 설계로 내려가는 과정. Secure Boot·HSM·SecOC 선택 근거

5

Clause 11 — 구현됐다는 것과 검증됐다는 것은 다르다. PenTest·Traceability·Cybersecurity Case

6

Clause 12~14 — 진짜 시작은 차량이 도로에 나간 이후. PSIRT·OTA·EOL 운영 체계

핵심 요약

• Clause 12는 양산 이후 보안 운영 — Vulnerability Monitoring, OTA 관리, Threat Intelligence 반영
• Clause 13은 보안 사고 대응 — PSIRT 운영, 취약점 접수·분석·패치·배포·공개 전체 체계
• Clause 14는 보안 지원 종료 관리 — 언제까지 어떻게 지원할 것인가를 사전 정의
• Vulnerability Monitoring은 SBOM 없이는 사실상 불가능하다
• PSIRT는 차량 출시 후 취약점 대응 조직 — IT SOC와 점점 가까워지고 있다
• 인증서 수명·암호 알고리즘 노후화·Legacy ECU 대응이 EOL의 핵심 과제다
• 주요 Work Product: Vulnerability Monitoring Report, Incident Response Report, End of Cybersecurity Support Notice
• 자동차 산업은 제품 판매 산업에서 운영·서비스 산업으로 이동 중이다
• SDV 시대 차량은 "지속적으로 운영되는 시스템" — 보안도 그에 맞게 운영되어야 한다
• ISO/SAE 21434는 단순 규격이 아니라 자동차 산업 변화의 방향 자체를 보여주는 표준이다

📚 현업에서 보는 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 Clause12 Clause13 Clause14 PSIRT OTA보안 VulnerabilityMonitoring SBOM EOL IncidentResponse 차량사이버보안 SDV R155 자동차규제