차량 사이버보안/V&V + 모의해킹

Verification와 Validation은 뭐가 다를까?— ISO/SAE 21434에서 가장 헷갈리는 두 개념

vsec 2026. 5. 27. 09:44
현업에서 보는 차량 보안 기술

ISO/SAE 21434를 읽다 보면 많은 사람들이 여기서 멈춥니다.

실제로 자주 헷갈리는 부분
10절: Integration & Verification
11절: Cybersecurity Validation
"둘 다 테스트 아닌가요?"
"Verification 했는데 Validation 또 왜 하죠?"

이유가 있습니다. 한국어로 번역하면 둘 다 "검증"이 되는 경우가 많기 때문입니다. 하지만 실제로는 관점 자체가 다릅니다.

Verification는:
"우리가 설계한 대로 제대로 만들었는가?"

Validation은:
"애초에 올바른 것을 만들었는가?"

같은 보안 기능을 보더라도 묻는 질문이 완전히 다릅니다.

가장 유명한 한 문장으로 먼저 이해하기

VERIFICATION
"Are we building the product right?"
제대로 만들었는가?
초점: 구현 정확성 · 요구사항 충족
VALIDATION
"Are we building the right product?"
올바른 걸 만들었는가?
초점: 실제 목적 달성 · 현실 공격 대응

ISO/SAE 21434 V-모델에서의 위치

V-모델의 왼쪽은 설계·개발, 오른쪽은 검증입니다. Verification과 Validation은 오른쪽에서도 위치가 다릅니다.

ISO/SAE 21434 V-모델 — Verification vs Validation 위치
Concept
(Clause 9)
TARA·보안목표
System Design
(Clause 10)
아키텍처·요구사항
SW 개발
(Clause 10)
구현
Integration &
Verification
(Clause 10.4.2)
요구사항 충족 확인
Cybersecurity
Validation
(Clause 11)
차량 수준 타당성 확인
핵심 차이:
Verification(Clause 10.4.2)는 컴포넌트·시스템 단위에서 정의된 사이버보안 사양이 충족됐는지를 봅니다. Validation(Clause 11)은 차량 수준에서 아이템 전체를 대상으로 사이버보안 목표가 실제로 달성됐는지를 봅니다.

같은 Secure Boot로 두 개념 비교하기

예시 — Secure Boot
🔵 VERIFICATION 관점
  • 서명 검증 코드가 정상 동작하는가
  • 잘못된 서명 Firmware를 거부하는가
  • Public Key가 올바르게 저장됐는가
  • Boot Flow가 설계 문서와 일치하는가
  • 테스트 결과가 Pass인가
🟢 VALIDATION 관점
  • 이 구조로 실제 공격을 막을 수 있는가
  • Public Key 보호가 충분한가
  • Rollback Attack이 가능한가
  • Debug Interface로 우회 가능한가
  • Chain of Trust 중간이 깨질 수 있는가
예시 — SecOC
🔵 VERIFICATION 관점
  • MAC 생성이 정상적으로 동작하는가
  • Receiver 검증 로직이 정확한가
  • Freshness Value가 증가하는가
  • Replay Attack이 탐지되는가
🟢 VALIDATION 관점
  • 실제 공격 환경에서 SecOC가 유효한가
  • 키 탈취 시 대응 방안이 있는가
  • 적용 범위가 충분한가 (일부 메시지만 적용 시)
  • TARA에서 식별된 위협을 실제로 막는가

한눈에 비교

항목 Verification Validation
핵심 질문 제대로 만들었는가? 올바른 걸 만들었는가?
관점 구현 정확성 중심 위협·목적 달성 중심
기준 정의된 Requirement 실제 보안 목표·위협 시나리오
대상 범위 컴포넌트·시스템 단위 차량 수준 아이템 전체
주요 방법 기능 시험·코드 리뷰·정적 분석 PenTest·실환경 공격 시뮬레이션
ISO 21434 위치 Clause 10.4.2 Clause 11
결과물 Test Report·Pass/Fail Validation Report·Residual Risk 판단

Verification 성공 ≠ 차량이 안전하다

가장 중요한 포인트입니다.

⚠️ Verification는 모두 통과했지만 안전하지 않은 시나리오
✅ Secure Boot 서명 검증 — Pass
✅ SecOC MAC 생성·검증 — Pass
✅ OTA 무결성 검증 — Pass
✅ Security Access 인증 — Pass
모든 보안 요구사항 구현 확인 완료
그런데... JTAG Debug 포트가 양산 ECU에 열려 있다면?
공격자가 Debug 포트로 접근 → Flash Dump → 내부 키·알고리즘 추출 → Secure Boot 우회 가능
모든 Verification 결과는 Pass였지만 실제 차량은 취약합니다.
Verification Pass ≠ 차량이 실제로 안전하다. Validation이 필요한 이유입니다.
⚠️ ISO/SAE 21434가 둘을 별도 Clause로 나눈 이유입니다.
요구사항대로 완벽하게 구현했더라도, 보안 전략 자체가 실제 공격에 충분하지 않을 수 있습니다. Validation은 이 간극을 채우는 과정입니다.

실제 프로젝트에서는 이 순서로 흐른다

ISO/SAE 21434 기반 프로젝트 검증 흐름
Verification
Requirement 기반 기능 시험 — 보안 요구사항이 구현됐는지 확인
Secure Boot 동작 확인·SecOC MAC 검증·Security Access 시험·OTA 서명 검증
Verification
취약점 스캔 — CVE·코드 취약점·OSS 분석
SCA Tool·Static Analysis·SBOM 기반 CVE 매핑
Verification
Fuzzing — 비정상 입력에 대한 견고성 확인
CAN Fuzzing·UDS Fuzzing·Ethernet Fuzzing
Validation
Penetration Test — 실제 공격자 관점에서 침투 시도
TARA 위협 시나리오 기반·차량 수준 공격 시뮬레이션
Validation
Residual Risk 판단 — 남은 위험이 허용 가능한 수준인지 판단
Risk Acceptance 문서화·사이버보안 목표 달성 여부 확인

현업에서는 Validation이 더 어렵다

🔵 Verification — 상대적으로 명확
  • Requirement Pass/Fail로 결과 명확
  • 테스트 케이스 사전 정의 가능
  • 정적 분석 도구 활용 가능
  • 기준이 문서에 있음
🔴 Validation — 판단이 어렵다
  • 새 공격 기법 등장 가능성 고려
  • 실제 공격자 수준 판단 필요
  • 차량 사용 환경 가변성
  • SDV·OTA로 환경이 계속 변함
  • Residual Risk 허용 여부 판단
Validation은 기술 문제이면서 동시에 "리스크 판단" 문제입니다.
그래서 Validation Report에는 테스트 결과뿐 아니라 Residual Risk 판단 근거와 사이버보안 목표 달성 여부까지 포함되어야 합니다.

SDV 시대 — Validation의 끝이 없어진다

SDV 시대 차량은 OTA로 계속 업데이트됩니다. 소프트웨어가 바뀌면 새로운 공격면이 생길 수 있습니다.

그래서 최근 등장하는 개념들:

Continuous Validation — 출시 후에도 지속적으로 보안 타당성 재확인
Runtime Monitoring — 실시간 이상 행동 감지
PSIRT 기반 재검증 — 새 취약점 발견 시 영향 재평가
SBOM 기반 Validation — 구성 요소 변경 시 영향 분석

현업에서는 이렇게 느낀다

현업 경험 3가지

Verification 통과 후 PenTest에서 문제가 나오는 경우가 있다 — 요구사항이 부족하거나, 설계 자체에 구조적 약점이 있는 경우입니다. 이때 "Verification를 잘못한 게 아니라 Validation에서 제대로 잡은 것"입니다.
Validation Report 작성이 생각보다 어렵다 — 단순히 PenTest 결과를 나열하는 게 아니라, "사이버보안 목표가 달성됐는가", "잔여 위험이 허용 가능한가"에 대한 판단을 담아야 합니다.
Validation은 반복된다 — OTA 업데이트, ECU 하드웨어 변경, 새 CVE 발견 시마다 영향을 재검토해야 합니다. 한 번 끝난 게 아닙니다.

마무리

Verification는 "기술 구현 확인"에 가깝고,
Validation은 "현실 공격 관점 타당성 평가"에 가깝습니다.

둘 다 필요하지만,
Validation이 훨씬 더 어렵고 끝이 없습니다.
핵심 요약
1
Verification = "요구사항대로 제대로 구현됐는가" — Clause 10.4.2, 컴포넌트·시스템 단위
2
Validation = "실제 환경에서 보안 목표가 달성됐는가" — Clause 11, 차량 수준 전체 관점
3
Verification Pass ≠ 차량이 안전하다 — 구현은 맞아도 보안 전략 자체가 부족할 수 있습니다
4
Validation은 리스크 판단이 포함된다 — Residual Risk 허용 여부와 사이버보안 목표 달성 근거가 필요합니다
5
SDV 시대에는 Continuous Validation이 중요해진다 — OTA·CVE·환경 변화에 따라 반복적으로 수행해야 합니다
Verification Validation ISO21434 차량사이버보안 VandV PenetrationTest ResidualRisk SDV TARA 차량보안테스트
반응형