자동차 보안 테스트는 왜 ‘완벽할 수 없을까’— Residual Risk와 현실적인 보안의 한계

차량 사이버보안 테스트·검증 시리즈

시리즈 전체 구성

1

이전 글

자동차 보안 테스트는 실제로 무엇을 할까?

ISO/SAE 21434 Clause 11 · 4가지 검증 유형 · 테스트 전체 구조

DONE

2

이전 글

차량 Penetration Test는 왜 일반 IT 해킹과 다를까?

공격면 · CAN·UDS·Firmware · 물리 공격 · 차량 특화 방법론

DONE

3

3편 · 지금 읽는 글 · 시리즈 완결

차량 보안 테스트는 왜 완벽할 수 없을까?

Residual Risk · Trade-off · PSIRT · Lifecycle 보안 운영

NOW

차량 사이버보안 프로젝트를 하다 보면 결국 이런 질문을 만나게 됩니다.

현업에서 자주 나오는 질문들

"이 정도면 이제 안전한 거죠?"

"취약점 0개로 만들 수는 없나요?"

"PenTest 통과했는데 왜 또 수정하죠?"

"모든 공격을 막을 수는 없는 건가요?"

그리고 이 질문들에 대한 답은 항상 같은 방향으로 이어집니다.

차량 보안은 "완벽한 방어"를 만드는 일이 아닙니다.

현실적인 비용과 제약 안에서,
허용 가능한 수준까지 리스크를 낮추는 과정입니다.

자동차 보안은 결국 리스크 관리(Risk Management)에 가깝습니다.

---

왜 완벽한 보안은 어려울까

이론적으로는 모든 ECU를 완벽하게 보호하고 싶습니다. 하지만 실제 차량 환경은 다릅니다.

이상적인 보안	현실 차량 환경의 제약
모든 CAN 메시지 암호화·인증	CAN 대역폭·CPU 부하·Latency 증가
모든 ECU에 HSM 적용	BOM 비용 증가, 저가 ECU 영향
Debug 포트 완전 차단	생산라인·정비·RMA 분석 어려움
항상 최신 SW 유지	Legacy ECU 존재, OTA 적용 불가 구간
모든 신규 공격 즉시 차단	새 공격 기법 계속 등장, 사전 예측 불가
무제한 보안 검증 시간	SOP 일정 고정, 검증 기간 제한

⚠️ 차량은 서버처럼 "즉시 패치·재배포"가 어렵습니다.
양산 이후 수정은 OTA가 가능한 경우라도 검증 공수가 크고, 하드웨어 변경이 필요한 경우는 리콜 수준의 비용이 발생합니다.

---

그래서 등장하는 개념 — Residual Risk

ISO/SAE 21434에서 중요한 개념 중 하나가 Residual Risk(잔여 위험)입니다.

RESIDUAL RISK 개념

초기 Risk

−

보안 대책
효과

=

Residual
Risk

보안 대책을 적용해도 완전히 제거되지 않고 남는 위험입니다. ISO/SAE 21434는 이 잔여 위험이 허용 가능한 수준인지를 판단하고 문서화하도록 요구합니다.

✅ ISO/SAE 21434가 요구하는 것:
Residual Risk를 0으로 만드는 게 아니라, "이 잔여 위험이 허용 가능한가"를 판단하고 그 근거를 남기는 것입니다. 그래서 Risk Acceptance 결정과 문서화가 중요합니다.

---

현실에서 계속 등장하는 Trade-off 시나리오들

이론과 현실 사이의 간극은 구체적인 상황에서 드러납니다.

1

모든 CAN 메시지에 SecOC를 적용해야 하는가?

✅ 이상적인 방향

• 모든 CAN 메시지 인증
• Spoofing·Replay 완전 차단
• 보안 수준 극대화

⚠️ 현실적 제약

• CAN 대역폭 증가
• ECU CPU 부하·Latency
• Legacy ECU 호환 문제
• 개발 공수 증가

→ 실제로는 Safety 관련 메시지, 외부 접점 메시지 우선 적용하고 내부 저위험 메시지는 Risk Acceptance 처리하는 경우가 많습니다.

2

모든 ECU에 HSM을 적용해야 하는가?

✅ 이상적인 방향

• 모든 ECU 키 하드웨어 보호
• CPU 분리 암호 연산
• Root of Trust 확립

⚠️ 현실적 제약

• BOM 비용 증가
• 저가 ECU 가격 경쟁력 영향
• 개발·통합 공수 증가

→ Gateway·ADAS·TCU처럼 공격 영향이 큰 ECU부터 우선 적용하고, 저위험 ECU는 SHE 또는 SW 기반 대안 검토합니다.

3

Debug 포트를 완전히 막아야 하는가?

✅ 이상적인 방향

• 모든 Debug 인터페이스 차단
• 내부 접근 완전 불가
• Flash Dump 원천 방지

⚠️ 현실적 제약

• 생산라인 품질 검사 필요
• 정비·RMA 분석 불가
• 개발 디버깅 어려움

→ "완전 차단"보다 "Secure Debug + 인증 기반 접근 통제"로 가는 경우가 많습니다. 무조건 막는 게 아니라 안전하게 관리하는 방향입니다.

---

차량 보안은 항상 5가지 사이에서 균형을 찾는다

🔒

보안 수준

높을수록 좋지만 비용·성능 영향

💰

비용

HSM·인증서·검증 공수 모두 비용

⚡

성능·Latency

암호 연산이 Real-time 제어에 영향

📅

개발 일정

SOP 고정, 보안 공수 추가 어려움

🔧

정비성

너무 잠그면 유지보수·RMA 어려움

⚙️

Safety 연속성

보안 기능이 Safety 동작 방해 금지

그래서 TARA가 중요한 이유가 여기 있습니다.
모든 걸 동일하게 보호하는 게 아니라 "어디에 더 집중해야 하는가"를 우선순위화하는 과정이기 때문입니다. Risk 수준에 따라 보안 대책의 강도를 다르게 적용하는 것이 TARA의 핵심 역할입니다.

---

PenTest 통과 = 안전한 차량일까

❌ "PenTest 통과 = 완벽하게 안전"

✅ "현재 시점·현재 범위 내에서 주요 위협 시나리오를 검증"

PenTest는 특정 시점, 특정 범위 기준의 검증입니다.

이후에 새로운 공격 기법이 발견될 수 있고, 차량 소프트웨어가 업데이트되면 새로운 공격면이 생길 수 있습니다. CVE도 계속 공개됩니다.

그래서 PenTest 통과는 "지금 이 시점에 알려진 주요 위협 시나리오는 방어된다"는 의미에 가깝습니다.

---

그래서 자동차 보안은 이제 "운영"의 문제다

예전 차량 보안은 출시 전 한 번 검증하면 끝에 가까웠습니다. SDV 시대에는 달라집니다.

자동차 보안 패러다임 변화

📦 과거 패러다임

개발 → 보안 검증 → 출시 → 끝

↓

🔗 현재 패러다임 — Lifecycle 전체

TARA·설계 → 개발·검증 → 출시 → 취약점 모니터링 → OTA 패치 → 재검증 → 지속 운영

그래서 CSMS, PSIRT, SUMS 같은 개념이 계속 중요해지고 있습니다. 보안은 출시 전 한 번 하는 게 아니라 차량 Lifecycle 전체에 걸쳐 운영하는 체계가 필요합니다.

---

PSIRT — 양산 이후 보안을 운영하는 방법

Product Security Incident Response Team. 양산 이후 발생하는 취약점·보안 사고에 대응하는 조직과 프로세스입니다.

1

취약점 접수·모니터링 — CVE 공개, 외부 제보, 내부 발견. SBOM 기반으로 영향 ECU 즉시 파악

2

영향 분석·우선순위 결정 — 차량에서의 실제 Reachability, Safety 영향, 공격 난이도 종합 판단

3

대응 방안 결정 — 즉시 패치 / OTA 예약 / Risk Acceptance / Mitigation 중 선택. 공급망 Coordination 포함

4

OTA 배포·검증 — 패치 개발·검증·배포. 배포 후 정상 동작 확인

5

이력 관리·개선 — Audit 증적 보관, 재발 방지 조치, 다음 차종 반영

✅ PSIRT가 있다는 것은 "보안 문제가 생겼을 때 대응할 수 있다"는 의미입니다. R155가 CSMS를 요구하는 핵심 이유 중 하나가 바로 이 지속적 보안 운영 체계입니다.

---

현업에서는 이렇게 느낀다

현업 경험 4가지

Residual Risk 문서화가 생각보다 중요하다 — 왜 이 위험을 수용했는지 근거를 남기는 게 Audit에서 핵심이 됩니다. "몰랐다"보다 "알고 판단했다"가 훨씬 낫습니다.

보안 결정은 항상 Trade-off 판단이다 — 어느 쪽이 절대적으로 옳은 게 아니라, 비용·일정·위험 수준을 종합해서 판단하는 과정입니다. 이 판단 근거가 Work Product에 남아야 합니다.

PenTest 결과에서 취약점이 나와도 전부 수정하지 않는 경우가 있다 — 차량 환경에서 Reachability 없거나 공격 조건이 너무 까다로운 경우, Risk Acceptance로 처리하고 다음 모델에 반영하는 방식이 현실적인 선택일 수 있습니다.

양산 이후가 오히려 더 바빠지기 시작했다 — SDV·OTA 시대가 되면서 출시 후 CVE 대응, SBOM 관리, OTA 패치 검증이 계속 이어집니다. 보안은 끝이 없어지고 있습니다.

---

시리즈를 마치며 — 3편에 걸쳐 정리한 것들

3편 시리즈 전체 흐름 정리

1

1편: 차량 보안 테스트는 PenTest 하나가 아니다 — Requirement부터 Validation까지 4단계 전체가 필요합니다

2

2편: 차량 PenTest는 IT 해킹과 다르다 — CAN·UDS·PCB·Firmware까지 차량 도메인 이해가 필수입니다

3

3편: 차량 보안은 완벽할 수 없다 — Residual Risk를 인정하고 Lifecycle 전체에서 운영하는 체계가 핵심입니다

---

마무리

자동차 보안은
"완벽하게 막는 기술"보다,
"현실적인 리스크를 인정하고 계속 관리하는 체계"에 가깝습니다.

그래서 TARA, CSMS, PSIRT, SUMS가 모두 연결됩니다.

핵심 요약

1

완벽한 차량 보안은 현실적으로 불가능하다 — 비용·성능·정비성·일정 제약이 항상 존재합니다

2

Residual Risk = 보안 대책 이후에도 남는 위험 — ISO/SAE 21434는 이를 허용 가능한 수준으로 관리하고 문서화하도록 요구합니다

3

차량 보안은 항상 Trade-off 판단 — SecOC·HSM·Debug 정책 모두 비용·성능·정비성과 균형을 찾아야 합니다

4

PenTest 통과는 "현 시점 주요 위협 방어" 증명 — 새 공격 기법·CVE가 등장하면 리스크는 다시 생깁니다

5

SDV 시대 보안은 Lifecycle 전체 운영 — PSIRT·OTA·SBOM·지속 모니터링이 차량 보안의 핵심이 되고 있습니다

ResidualRisk 차량사이버보안 ISO21434 RiskManagement PSIRT CSMS SUMS OTA보안 TARA SDV