TARA[VisualPro Tech Brief] 3년 안에 표적이 된다면, TARA는 언제 다시 여는가
01요약
0283%가 말해 주는 것과 말해 주지 않는 것
QNX의 「Under the Hood: SDV Developer Report」 2026년판은 OnePoll이 7월 20일부터 8월 4일까지 온라인으로 조사했습니다. 보안 관련 수치는 이렇습니다.
| 수치 | 내용 |
|---|---|
| 83% | SDV가 3년 안에 사이버 공격의 주요 표적이 될 것으로 예상 |
| 48% | 보안 위협을 가장 큰 향후 우려로 꼽음(전년보다 5%포인트 상승) |
| 47% | SDV를 대규모로 출시할 때 가장 큰 위험으로 사이버 취약점을 꼽음 |
| 46% | 맞추기 가장 어려운 규제로 사이버보안 표준(UNECE WP.29, ISO/SAE 21434)을 꼽음 |
| 79% | 더 빠른 경쟁사 때문에 압박을 느낌 |
읽을 때 두 가지를 기억해야 합니다. 이 조사는 차량용 소프트웨어를 파는 회사가 의뢰한 조사이고, 응답자는 보상을 받고 참여했습니다. 그리고 83%는 개발자의 전망이지 발생한 공격의 통계가 아닙니다. "83%의 차량이 공격받는다"로 읽으면 안 됩니다.
이 조사를 다룬 TheAutoExec 기사는 여기서 한 걸음 더 나갑니다. 필자는 차량이 언제까지 보안 업데이트를 받는지, 취약점이 나오면 어떻게 대응하는지 제조사가 답할 수 있어야 한다고 썼습니다. 조사 결과가 아니라 필자의 의견입니다. 다만 엔지니어에게는 이 질문이 곧바로 다른 질문이 됩니다. 그 답의 근거가 되는 위험 평가는 지금도 맞는가?
03양산 시점의 TARA는 가정 위에 서 있다
ISO/SAE 21434는 범위를 개념과 개발에서 멈추지 않습니다. 생산, 운영, 유지보수, 폐기까지 포함합니다. 8절은 지속적인 위험 평가에 쓸 정보를 모으는 활동과 사이버보안 지원이 끝날 때까지의 취약점 관리를, 13절은 사고 대응과 업데이트를, 14절은 지원 종료와 폐기를 다룹니다. UN R155의 사이버보안 관리체계도 생산 후 단계까지 다룹니다.
왜 양산 뒤에도 평가가 달라질까요? 공격 잠재력 방식의 공격 실현 가능성은 다섯 가지 요소의 합으로 정합니다.
| 요소 | 묻는 것 | 시간이 지나면 |
|---|---|---|
| 소요 시간 | 공격을 찾아내고 실행하는 데 얼마나 걸리나 | 공격 코드가 공개되면 크게 준다 |
| 전문 지식 | 어느 수준의 전문가가 필요한가 | 도구가 나오면 낮아진다 |
| 아이템·컴포넌트 지식 | 대상 정보를 얼마나 구하기 어려운가 | 분석 자료가 퍼지면 낮아진다 |
| 접근 난이도 | 대상에 접근할 기회가 얼마나 있나 | 연결 기능이 늘면 쉬워진다 |
| 장비 | 어떤 장비가 필요한가 | 장비가 흔해지면 낮아진다 |
점수가 낮을수록 공격이 쉽다는 뜻입니다. 양산 시점에 "이 공격은 어렵다"고 적은 근거는 대부분 이 다섯 칸에 들어 있고, 다섯 칸 모두 차량 밖 세상이 바뀌면 함께 바뀝니다. 자산과 피해의 크기는 그대로인데 공격만 쉬워질 수 있습니다.
04예제 1 — 공격 코드가 공개되었을 때
교육용 가상 시스템입니다(특정 차량·제조사의 설계가 아닙니다). 텔레매틱스 제어 장치(TCU)가 셀룰러 망에 연결되어 있고, 네트워크 스택에 공개 라이브러리를 씁니다. 업데이트 관리자는 서명 검증 키로 OTA 패키지를 검증합니다. 위협은 두 가지입니다.
- TH-1 TCU 네트워크 스택의 취약점으로 원격 코드를 실행하고 위조 차량 제어 메시지를 보낸다 (영향 Severe)
- TH-2 진단 포트로 ECU 메모리를 읽어 서명 검증 키를 빼낸 뒤 위조 업데이트 패키지를 설치한다 (영향 Major)
양산 시점(T0)에 두 위협은 모두 어렵다고 평가했습니다. TH-1을 실행하려면 공격자가 취약점을 직접 찾아야 했기 때문입니다. 그 뒤 TCU가 쓰는 라이브러리의 취약점과 공격 코드가 공개되었다고 가정합니다(T1). 바뀌는 것은 AP-1의 값입니다.
| AP-1 요소 | T0 양산 시점 | T1 공격 코드 공개 후 | 왜 바뀌나 |
|---|---|---|---|
| 소요 시간 | 17 | 1 | 직접 찾으면 수개월, 공개 코드를 맞춰 쓰면 며칠 |
| 전문 지식 | 6 | 3 | 전문가가 아니어도 숙련자면 실행할 수 있다 |
| 아이템·컴포넌트 지식 | 3 | 0 | 필요한 정보가 공개되었다 |
| 접근 난이도 | 1 | 1 | 셀룰러 망 연결은 그대로다 |
| 장비 | 0 | 0 | 일반 장비로 충분하다 |
| 합계 | 27 | 5 | |
| 공격 실현 가능성 | Very Low | High |
다음은 위험 계산 화면입니다.
| 위협 | 영향 등급 | T0 공격 실현 가능성 · 위험 등급 | T1 공격 실현 가능성 · 위험 등급 | 처리 결정 |
|---|---|---|---|---|
| TH-1 | Severe | Very Low · 2 | High · 5 | 위험 유지 (T0에 내린 결정 그대로) |
| TH-2 | Major | Very Low · 1 | Very Low · 1 | 위험 유지 |
여기서 두 가지를 볼 수 있습니다.
첫째, 전체를 처음부터 다시 할 필요가 없습니다. 바뀐 것은 공격 경로 하나의 평가값이고, TH-2는 그대로입니다. 공개된 취약점이 어느 자산과 공격 경로에 닿는지만 알면 다시 볼 곳은 좁혀집니다.
둘째, 위험값은 다시 계산되지만 결정은 저절로 바뀌지 않습니다. 위험 등급 5 옆에 "위험 유지"가 그대로 남습니다. 이 결정은 위험 등급이 2일 때 내린 것입니다. 다시 열어 본 사람이 없다면 문서에는 낡은 결정이 계속 유효한 것처럼 남습니다. 처리 결정은 책임이 따르는 판단이므로 도구가 대신할 일이 아닙니다. 그래서 누가 언제 다시 볼지를 절차로 정해 두어야 합니다.
이 예제에서는 TH-1의 결정을 "위험 감소"로 바꾸고 사이버보안 목표 두 개를 공격 경로에 연결했습니다.
- SG-1 TCU 네트워크 스택의 공개 취약점은 정해진 기간 안에 OTA 패치로 해소한다
- SG-2 TCU에서 온 메시지는 게이트웨이에서 허용된 제어 메시지만 차량 내부로 통과시킨다
SG-1의 "정해진 기간"이 바로 TheAutoExec 필자가 묻는 지원 약속과 이어지는 자리입니다. 패치 기간과 지원 기간을 말하려면 그 근거가 되는 위험 평가가 있어야 합니다.
05예제 2 — OTA로 기능이 늘어날 때
두 번째 신호는 외부가 아니라 우리 쪽에서 옵니다. 양산 뒤 OTA로 원격 시동 기능을 추가한다고 합시다(T2). 양산 시점 TARA에는 이 기능의 자산도 공격 경로도 없습니다. 기존 평가값을 고치는 것으로는 부족하고 항목을 새로 만들어야 합니다.
| TARA 항목 | 새로 추가한 내용 |
|---|---|
| 자산 | 원격 시동 명령 인증 토큰 (기밀성·무결성) |
| 피해 시나리오 | 권한 없는 원격 시동으로 차량을 도난당한다 (Financial Major) |
| 위협 | TH-3 원격 시동 API의 인증 결함을 이용해 권한 없는 사용자가 시동 명령을 보낸다 |
| 공격 경로 | AP-3 앱과 서버 사이의 API를 분석해 인증 토큰을 위조하고 원격 시동 명령을 보낸다 |
| 공격 실현 가능성 · 위험 등급 | 합계 10 · High · 4 |
| 처리 결정 · 사이버보안 목표 | 위험 감소 · SG-3 원격 시동 명령은 차량 소유자에게 발급된 유효한 인증으로만 실행한다 |
QNX 조사에서 79%가 속도 압박을 말했습니다. 기능을 자주 내보낼수록 TARA는 "한 번 끝내는 문서"로 두기 어렵습니다. 새 기능을 출시하는 절차에 TARA 갱신 여부를 확인하는 칸이 있어야 합니다.
06언제 다시 열까: 네 가지 신호
| 신호 | 먼저 확인할 것 | TARA에서 바뀌는 칸 |
|---|---|---|
| 공개 취약점·공격 코드 | 우리가 쓰는 부품·라이브러리에 해당하는가 | 공격 실현 가능성 요소 → 위험 등급 → 처리 결정 |
| OTA 기능 추가·인터페이스 변경 | 새 자산이나 새 공격 경로가 생겼는가 | 자산·피해·위협·공격 경로 신규 |
| 실제 사고·침해 징후 | 양산 시점의 가정이 깨졌는가 | 공격 실현 가능성, 사이버보안 목표 |
| 사이버보안 지원 종료 결정 | 그동안 "유지"로 둔 위험을 언제까지 감당하는가 | 처리 결정 |
신호를 찾는 일과 평가를 다시 하는 일은 다른 일입니다. 취약점 정보 수집과 사고 대응에는 별도의 체계가 필요합니다. TARA는 그 체계가 찾아낸 사실이 위험과 결정을 어떻게 바꾸는지 적는 자리입니다.
07VisualPro TARA로 할 수 있는 것과 할 수 없는 것
할 수 있는 것
1자산 → 피해 → 위협 → 공격 경로 → 사이버보안 목표 → 위험 처리를 한 모듈에서 이어 갑니다.
2공격 실현 가능성을 세 방식으로 평가합니다.
3평가값을 고치면 위험 등급이 다시 계산됩니다.
4MCP 연결로 AI와 함께 작성합니다.
할 수 없는 것
VisualPro TARA는 평가를 기록하고 계산하는 도구입니다. 취약점 정보를 수집하거나 사고를 대응하는 도구가 아니므로, 공격 코드가 공개되었다는 사실은 담당자가 판단해 입력해야 합니다.
08내일 확인할 것
보안 담당
- 처리 결정마다 그 결정을 내린 시점과 당시 위험 등급을 알 수 있는가?
- 공개 취약점이 나왔을 때 어느 자산과 공격 경로를 봐야 하는지 바로 찾을 수 있는가?
개발·제품 담당
- OTA로 기능을 내보내는 출시 절차에 TARA 갱신 여부를 묻는 항목이 있는가?
- 공개 라이브러리와 TARA의 자산이 연결되어 있는가?
품질·규제 담당
- TARA를 다시 여는 신호와 담당자, 처리 기한이 절차에 적혀 있는가?
- 고객에게 약속하는 지원 기간이 위험 평가와 맞는가?
09마무리
10자주 묻는 질문
Q1취약점이 나올 때마다 TARA를 처음부터 다시 해야 합니까?
Q2공격 실현 가능성이 올라가면 영향 등급도 바뀝니까?
Q3CVSS 점수가 높은 취약점이면 위험도 곧바로 높은 것 아닙니까?
Q4위험 유지 결정은 잘못된 것입니까?
Q5처음 시작한다면 무엇부터 하면 됩니까?
· QNX, "Under the Hood: SDV Developer Report" 보도자료, 2026.10.21 — 보도자료 보기
· TheAutoExec, "Four-fifths of automotive software developers expect their cars to be attacked by hackers within three years", 2026.10.28 — 기사 보기
· ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering (1절 범위, 8·13·14·15절) — ISO 안내 페이지
· UN Regulation No. 155 Cyber security and cyber security management system — UNECE 안내 페이지

