현업에서 보는 차량 보안 기술
차량 보안 프로젝트에서 취약점 분석을 하다 보면 어느 순간 이런 말이 나옵니다.
"근데 이거 우리가 만든 코드 아닌데요?"
Linux Kernel CVE, OpenSSL 취약점, BSP 보안 이슈. 이것들은 Tier-1이 직접 개발하지 않은 소프트웨어에서 나온 문제들입니다. 수정 권한도 없고, 내부 구현도 모르고, Vendor Patch를 기다려야 합니다.
SDV 시대 차량 보안의 가장 현실적인 고민 중 하나는
"직접 개발하지 않은 소프트웨어 취약점"을 누가 어떻게 관리하는가입니다.
BSP·OSS·3rd Party Stack 비중이 커질수록
공급망 보안의 책임 경계는 점점 복잡해지고 있습니다.
"직접 개발하지 않은 소프트웨어 취약점"을 누가 어떻게 관리하는가입니다.
BSP·OSS·3rd Party Stack 비중이 커질수록
공급망 보안의 책임 경계는 점점 복잡해지고 있습니다.
SDV ECU 안에는 얼마나 많은 외부 소프트웨어가 들어가나
예전 ECU는 MCU Vendor SDK + RTOS + 자체 Application 정도로 구성되는 경우가 많았습니다. 외부 의존성이 지금보다 훨씬 적었습니다.
SDV 시대 ECU는 다릅니다. 하나의 ECU 안에 이런 구성이 섞입니다.
| 소프트웨어 영역 | 주요 공급 주체 | 성격 |
|---|---|---|
| BSP (Board Support Package) | SoC Vendor | 외부 공급 |
| Linux Kernel | OSS Community + Vendor 커스터마이징 | 오픈소스 |
| Hypervisor | 3rd Party Vendor | 외부 공급 |
| Middleware / Stack | 외부 Supplier | 외부 공급 |
| Connectivity (Wi-Fi, BT) | Chipset Vendor | 외부 공급 |
| AI Runtime / Framework | OSS / Vendor | 오픈소스 |
| Application | Tier-1 자체 개발 | 직접 개발 |
현대 차량 ECU는 "Tier-1이 전부 직접 개발하는 구조"와 점점 멀어지고 있습니다.
Application을 제외한 대부분의 레이어가 외부에서 공급됩니다.
Application을 제외한 대부분의 레이어가 외부에서 공급됩니다.
그리고 취약점도 함께 들어온다
외부 소프트웨어 의존성이 커질수록, CVE도 함께 따라옵니다. 이건 피할 수 없습니다.
Linux Kernel
커널 CVE
매년 수백 건 발생. 차량용 커널도 영향권
OpenSSL / TLS
암호화 라이브러리
Heartbleed급 취약점이 주기적으로 발생
Wi-Fi Stack
연결 취약점
Chipset Vendor 패치 의존. 원격 공격 가능
Hypervisor
VM Escape
도메인 격리 무력화 가능성
Container Runtime
컨테이너 탈출
SDV 아키텍처 확산으로 영향 증가
OSS 의존성
Transitive 취약점
Log4Shell처럼 간접 의존으로 들어오는 경우
문제는 이 취약점들이 Tier-1이 직접 개발한 코드에서 나온 게 아니라는 점입니다.
BSP — 가장 애매한 회색 영역
그중에서도 BSP는 책임 경계가 가장 복잡한 영역입니다.
BSP 구조와 책임 경계 문제
SoC Vendor
BSP 제공
→
Linux Kernel
포함
+
Driver
포함
+
Security Patch
일부 포함
→
Tier-1 통합
ECU에 포함
⚠️ ECU에 통합되는 순간, 전체 시스템 보안 책임이 Tier-1에게 집중됩니다.
직접 개발하지 않은 BSP 취약점도 "최종 제품 책임자"로서 대응해야 합니다.
직접 개발하지 않은 BSP 취약점도 "최종 제품 책임자"로서 대응해야 합니다.
⚠️ 규제는 "누가 만들었는가"를 묻지 않습니다.
R155, CRA, ISO 21434는 "누가 추적 가능한가", "누가 영향 분석 가능한가", "누가 대응 가능한가"를 봅니다. 직접 개발 여부와 무관하게 최종 통합 책임자가 관리 주체가 됩니다.
R155, CRA, ISO 21434는 "누가 추적 가능한가", "누가 영향 분석 가능한가", "누가 대응 가능한가"를 봅니다. 직접 개발 여부와 무관하게 최종 통합 책임자가 관리 주체가 됩니다.
취약점 "존재"와 실제 "영향"은 완전히 다른 문제다
SCA(Software Composition Analysis) Tool을 돌리면 CVE 목록이 쏟아집니다. 하지만 이게 전부 실제 위협인 건 아닙니다.
🔴 Tool이 "CVE 발견"이라고 표시한 경우
- 실제로 사용하지 않는 Driver
- Compile 시 제외된 기능
- 비활성화된 Config
- Reachability 없는 코드 경로
- Vendor Customization으로 이미 패치됨
🟢 실제로 분석이 필요한 것
- 실제 사용 중인 코드 경로
- 공격자가 도달 가능한 Attack Surface
- 차량 기능과 연결된 경우
- 외부 인터페이스에서 접근 가능한 경우
- Safety 영향으로 이어지는 경우
취약점 "존재"와 실제 "영향"은 완전히 다른 문제입니다.
그래서 SCA Tool 결과를 그대로 보고서로 제출할 수 없고, Reachability Analysis와 실제 Attack Surface 분석이 따로 필요합니다. 이게 생각보다 훨씬 많은 공수가 드는 작업입니다.
그래서 SCA Tool 결과를 그대로 보고서로 제출할 수 없고, Reachability Analysis와 실제 Attack Surface 분석이 따로 필요합니다. 이게 생각보다 훨씬 많은 공수가 드는 작업입니다.
현실적인 절충안 — 어떻게 관리하는가
BSP·OSS 규모가 너무 크고, CVE 수가 너무 많고, 직접 수정 권한도 없습니다. 그래서 업계에서는 현실적인 운영 방향이 논의되고 있습니다.
현실적인 OSS / BSP 취약점 관리 방향
① Vendor Advisory 기반 관리
Linux·Yocto 등 OS Vendor 제공 플랫폼 컴포넌트에 대해서는 모든 CVE를 직접 분석·패치하는 대신, Vendor가 공식 제공하는 Security Advisory 또는 Stable Release Note 기반으로 관리하는 방식이 논의됩니다. Vendor가 이미 영향 분석과 패치를 수행한 경우, 그 결과를 신뢰하는 구조입니다.
② SBOM 제출 의무는 그대로 유지
직접 패치 여부와 별개로, OS·BSP를 포함한 모든 OSS 구성 요소에 대해 버전·출처 정보가 포함된 SBOM 제출은 계속 요구됩니다.
"직접 Patch를 모두 수행하지 않더라도,
최소한 무엇을 사용하고 있는지는 추적 가능해야 한다"
최소한 무엇을 사용하고 있는지는 추적 가능해야 한다"
③ Reachability 기반 우선순위화
모든 CVE를 동등하게 처리하지 않고, 실제 Attack Surface에 도달 가능한 취약점을 우선 처리하는 방식입니다. 사용하지 않는 기능이나 비활성 코드 경로의 취약점은 Residual Risk로 기록하고 허용 근거를 남기는 구조입니다.
공급망 역할 분담 구조
결국 이 문제는 혼자 해결할 수 없습니다. 최근 업계는 공급망별 역할 분담 구조로 움직이고 있습니다.
| 주체 | 주요 역할 | 한계 |
|---|---|---|
| SoC Vendor | BSP Patch 제공, Security Advisory 발행 | Patch 속도 느린 경우 많음 |
| OSS Community | 원본 취약점 Fix, CVE 발행 | 차량 특화 고려 없음 |
| Middleware Vendor | Component Patch 제공 | 차량 적용까지 시간 소요 |
| Tier-1 | 통합·영향 분석, SBOM 관리, OEM 대응 | 직접 수정 권한 없는 경우 많음 |
| OEM | 차량 영향 판단, 배포 전략 결정 | 공급망 전체 가시성 부족할 수 있음 |
"직접 수정"보다 "지속적 추적·분석·Coordination"이 핵심이 되고 있습니다.
OSS/BSP 취약점 대응 흐름
CVE 공개
취약점
식별
식별
→
SBOM 조회
영향
ECU 파악
ECU 파악
→
Reachability
실제 영향
분석
분석
→
Vendor 협의
Patch
Coordination
Coordination
→
OTA / 배포
패치
적용
적용
→
문서화
Evidence
기록
기록
SDV 시대에는 이 문제가 더 커진다
앞으로 SDV는 Linux 확대, AI Runtime 증가, Container 증가, Cloud 연동 증가 방향으로 갈 가능성이 큽니다. 직접 개발하지 않은 코드 비중이 더 커집니다.
✅ 그래서 점점 더 중요해지는 것:
SBOM — 무엇을 사용하는지 추적 가능한 목록
Vulnerability Monitoring — 지속적인 CVE 모니터링
Patch Coordination — 공급망과의 빠른 협력 체계
PSIRT — 조직 내 취약점 대응 프로세스
이건 보안 기능 개발이 아니라 보안 운영 체계의 문제입니다.
SBOM — 무엇을 사용하는지 추적 가능한 목록
Vulnerability Monitoring — 지속적인 CVE 모니터링
Patch Coordination — 공급망과의 빠른 협력 체계
PSIRT — 조직 내 취약점 대응 프로세스
이건 보안 기능 개발이 아니라 보안 운영 체계의 문제입니다.
현업에서는 이렇게 느낀다
현업 경험 4가지
ECU 안에 직접 개발하지 않은 코드가 생각보다 훨씬 많다 — BSP·OSS·Middleware 의존성이 계속 증가하고 있습니다. Application 레이어 아래를 들여다보면 전부 외부 공급 소프트웨어인 경우가 많습니다.
SCA Tool 결과만으로 대응 여부를 결정하기 어렵다 — False Positive가 너무 많고, Vendor Customization 영향이 큽니다. Tool이 CVE를 찾아줘도 실제 영향 분석은 사람이 해야 합니다.
취약점 분석보다 영향 분석 공수가 더 크다 — 실제 사용 여부와 Reachability 판단, Vendor 패치 적용 여부 확인까지 하면 CVE 하나당 들어가는 공수가 생각보다 큽니다.
결국 Tier-1이 공급망 전체 Coordination 역할을 맡게 된다 — OEM 대응, 통합 영향 분석, SBOM 제출, Vendor 협의까지. 보안 기능 개발보다 운영 공수가 더 커지는 경우도 있습니다.
마무리
SDV 시대 차량 소프트웨어는
더 이상 하나의 조직이 전부 만드는 구조가 아닙니다.
그래서 보안도 "내 코드만 보호하는 문제"에서
벗어나고 있습니다.
규제는 이미 방향을 정했습니다. "누가 만들었는가"가 아니라 "누가 추적하고, 분석하고, 대응할 수 있는가"를 봅니다.
그래서 지금 Tier-1에게 던져지는 질문은 이겁니다.
"직접 만든 코드는 아니더라도, 그 위험까지 관리할 수 있는가?"
핵심 요약
1
SDV ECU는 BSP·OSS·Middleware가 뒤섞인 구조 — Tier-1이 직접 개발하지 않은 코드 비중이 빠르게 커지고 있습니다
2
규제는 "개발자"가 아닌 "관리자"를 찾는다 — 누가 추적·분석·대응 가능한가가 기준입니다
3
취약점 존재와 실제 영향은 다르다 — Reachability Analysis와 Attack Surface 분석이 필수입니다
4
SBOM이 영향 분석의 출발점 — 무엇을 사용하는지 추적 가능해야 CVE 대응이 시작됩니다
5
핵심은 보안 기능이 아닌 운영 체계 — PSIRT, SBOM, Patch Coordination이 SDV 시대 차량 보안의 핵심입니다
반응형
'차량 사이버보안 > 보안기술' 카테고리의 다른 글
| Secure Debug를 막으면 개발은 어떻게 하지? — 양산 ECU의 Debug 권한 관리 현실 (0) | 2026.05.29 |
|---|---|
| "차량 보안의 핵심은 결국 '키 보호'다 — HSM 구조(심화)" (0) | 2026.05.26 |
| 차량 IDS 구현의 진짜 어려움 — 표준은 있는데, 판단 기준은 다 다르다 (0) | 2026.05.22 |
| 자동차 ECU는 왜 Secure Debug가 필요할까?— 개발용 디버그 포트는 왜 양산 이후 위험이 되는가 (0) | 2026.05.20 |
| SecOC는 왜 아직도 어려운 기술일까? (1) | 2026.05.16 |