TARA는 언제 다시 해야 할까? — 변경관리(Change Management)의 현실

보안 규제와 프로세스 — 실무 현장

변경이 생길 때마다 나오는 말

"HW는 그대로인데 SW만 바뀌었어요. TARA 다시 해야 하나요?"

"Requirement 하나 수정했는데 TARA 업데이트가 필요한가요?"

"CVE 하나 발견됐는데 TARA를 다시 열어야 하나요?"

"OTA 기능 추가됐는데 기존 TARA가 아직 유효한 건가요?"

처음 TARA를 수행할 때는 비교적 명확하다. 문제는 그다음이다. 개발은 계속 바뀌고, 누군가는 반드시 묻는다 — "이 변경 때문에 TARA를 다시 해야 하나요?"

ISO/SAE 21434는 이 질문에 명확한 답을 주지 않는다. 그래서 실무에서 항상 고민이 생긴다.

---

21434가 실제로 말하는 것

먼저 한 가지 오해를 정리해야 한다. ISO/SAE 21434는 "이런 변경이 발생하면 TARA를 다시 수행하라"는 식의 명시적인 목록을 제공하지 않는다.

21434 Clause 10(사이버보안 엔지니어링)과 관련 조항에서 강조하는 것은 변경 자체가 아니라 보안 영향(Security Impact)이다.

💡 21434 관점의 핵심 질문

"변경이 발생했는가?" (X)
"변경이 보안 위험에 영향을 주는가?" (O)

즉, 변경의 존재가 아니라 변경의 보안 영향이 TARA 재검토 여부를 결정한다.

❌ 변경이 발생하면 항상 TARA를 처음부터 다시 수행해야 한다

✅ 변경의 보안 영향을 먼저 분석하고, 영향이 있을 때 TARA를 재검토한다

모든 변경마다 TARA를 처음부터 수행하면 프로젝트가 멈춰버릴 수 있다. 반대로 아무 변경에도 TARA를 검토하지 않으면 새로운 위험을 놓친다. 중요한 것은 변경의 보안 영향을 판단하는 프로세스를 갖추는 것이다.

---

TARA 재검토가 필요한 변경 — 어떤 경우인가

실무에서 공통적으로 나타나는 패턴이 있다. 다음 질문 중 하나라도 "예"가 나온다면 TARA 재검토를 고려해야 한다.

TARA 재검토를 트리거하는 변경 유형

1

새로운 인터페이스 또는 통신 채널 추가 — Bluetooth, Wi-Fi, Ethernet, OTA, USB, V2X 등 외부 연결이 추가되면 공격 표면(Attack Surface)이 넓어진다. 기존 TARA의 Item Boundary와 Trust Boundary가 바뀌기 때문에 재검토가 필요하다.

2

기능 추가 또는 Asset 중요도 변경 — 단순 모니터링 ECU에 제어 기능이 추가되거나, 새로운 안전 관련 기능이 탑재되면 Impact Rating 자체가 달라질 수 있다. 기존 Damage Scenario가 더 심각해지는 경우다.

3

시스템 아키텍처 변경 — Standalone ECU에서 Domain Controller, 또는 Zonal Architecture로 변경되면 신뢰 경계(Trust Boundary)와 통신 경로가 달라진다. 기존 Threat Scenario의 Attack Path가 바뀔 수 있다.

4

새로운 취약점 발견 (CVE 등) — 사용 중인 OSS나 써드파티 컴포넌트에서 중대한 CVE가 발견됐다면, 기존 TARA에서 "실현 불가능"으로 평가한 Attack Path가 현실화될 수 있다. 영향 분석이 필요하다.

5

운영 환경 변경 — 차량 내 네트워크 구조 변경, 클라우드 백엔드 연동 추가, Fleet Management 연결 등 차량이 동작하는 환경 자체가 바뀌는 경우다.

---

TARA 재검토가 불필요한 변경 — 어떤 경우인가

모든 변경이 TARA 재검토를 의미하지는 않는다. 보안 영향이 없거나 미미한 변경들이 있다.

✅ 영향 분석 후 유지 가능한 변경

보안 영향이 없거나 기존 범위 내

단순 버그 수정 (보안 기능 무관)

UI·로그·오타 수정

기능·인터페이스 변경 없는 코드 리팩토링

이미 평가된 범위 내 파라미터 조정

성능 최적화 (통신 프로토콜 변경 없음)

⚠️ 반드시 영향 분석이 필요한 변경

보안 영향 여부 불분명 — 판단 필요

암호 알고리즘 변경 또는 키 길이 변경

인증 로직 수정

메시지 구조 변경 (새 필드 추가 등)

보안 관련 설정값 변경

외부 라이브러리 버전 업그레이드

⚠️ 주의 — "HW는 그대로, SW만 바뀌었다"는 말

가장 자주 나오는 케이스다. HW가 같아도 SW 변경이 새로운 기능을 추가하거나, 기존 보안 메커니즘의 동작을 바꾸거나, 외부 인터페이스의 동작을 변경한다면 TARA 영향이 있다. "HW 동일"은 TARA 재검토 면제의 근거가 되지 않는다.

---

실무에서 작동하는 프로세스 구조

변경이 발생했을 때 "TARA를 다시 해야 하나?"에 바로 답하려 하면 항상 막힌다. 실무에서 더 잘 작동하는 구조는 중간에 판단 단계를 하나 두는 것이다.

변경관리 — TARA 영향 판단 프로세스

변경 요청
접수

→

보안 영향
분석
(SIA)

→

TARA
영향 여부
판단

→

필요 시
TARA
업데이트

→

Req·V&V
영향 분석

핵심은 변경을 TARA로 직행하는 것이 아니라, Security Impact Analysis(SIA)를 통해 먼저 영향 범위를 판단하는 것이다.

이 구조에서 SIA(Security Impact Analysis)가 핵심 허브 역할을 한다. 어떤 변경이 TARA까지 올라가야 하는지, 보안 요구사항만 수정하면 되는지, 아무 영향이 없는지를 이 단계에서 판단한다. SIA 없이 TARA 재수행 여부를 논하면 매번 담당자의 직관에 의존하게 된다.

---

가장 자주 놓치는 것 — 추적성

실무에서 반복적으로 나타나는 문제가 있다. TARA만 업데이트하고 멈추는 것이다.

❌ TARA에 Threat Scenario를 추가했으니 변경관리는 완료됐다

✅ TARA가 바뀌면 아래로 연결된 모든 산출물을 함께 검토해야 한다

21434의 핵심은 추적성(Traceability)이다. TARA → Cybersecurity Goal → Security Requirement → Verification → Validation 전체가 연결되어 있다. TARA에 새로운 Threat Scenario가 추가됐는데 해당 위협을 대응하는 Requirement가 없거나, Requirement가 추가됐는데 Test Case가 없다면 추적성이 끊긴다. OEM 심사에서 가장 자주 지적받는 지점이다.

TARA 변경 내용	함께 검토해야 할 산출물	놓치면 생기는 문제
새 Threat Scenario 추가	Cybersecurity Goal, Security Requirement	위협은 있는데 대응 요구사항 없음
Risk Level 변경	Treatment 결정, Requirement 우선순위	기존 대응이 새 Risk Level에 부족할 수 있음
Attack Path 변경	보안 메커니즘 선정, 설계 반영	공격 경로가 달라졌는데 대응이 그대로
Asset 범위 변경	Item Definition, Damage Scenario	새 Asset에 대한 위협 분석 누락
새 Threat Scenario 해소	V&V Test Case 추가	Requirement는 있는데 검증 방법 없음

---

OEM은 무엇을 보는가

OEM 심사에서 변경관리 관련 질문은 보통 이런 형태로 온다.

ℹ️ OEM 심사에서 자주 나오는 질문

"이 기능이 추가된 이후 TARA를 재검토했는가?" / "재검토하지 않았다면 그 근거가 문서화되어 있는가?" / "변경 이후 보안 요구사항은 업데이트됐는가?" / "새로운 Threat Scenario에 대한 Test Case가 존재하는가?"

중요한 것은 OEM이 반드시 "TARA를 다시 했는지"를 보는 것이 아니라는 점이다. 변경의 보안 영향을 인지하고 있는가, 그리고 그 판단이 문서화되어 있는가를 본다.

💡 TARA를 업데이트하지 않은 것도 정당한 결정이 될 수 있다.

조건은 하나다 — 왜 영향이 없다고 판단했는지 근거가 문서화되어 있어야 한다. "검토했고, 보안 영향이 없다고 판단했고, 그 이유는 다음과 같다"는 형태의 기록이 있어야 심사에서 설명이 된다.

---

🔧 현업에서 느끼는 변화들

변경관리 프로세스가 없는 경우 프로젝트 후반에 몰아치기가 된다 — 개발 중에 변경이 쌓이고, OEM 심사 직전에 "TARA가 최신 상태인가"를 점검하면 대부분 추적성이 끊겨 있다. 변경 시점마다 SIA를 한 장이라도 남기는 습관이 없으면, 심사 준비 단계에서 재작업이 집중된다.

"보안 영향 없음"도 문서가 되어야 한다 — 가장 자주 나오는 상황이 "이 변경은 보안과 관계없어서 넘어갔다"는 구두 합의다. 심사에서 이 변경이 들어오면 근거를 제출할 수 없다. "영향 없음"이라는 판단도 SIA 문서 한 줄로 남겨두면 그것이 곧 증거가 된다.

CVE 대응이 TARA와 연결되지 않는 경우가 많다 — CVE가 발견되면 패치를 적용하는 것은 잘 한다. 그런데 그 CVE가 기존 TARA의 어떤 Threat Scenario와 연결되는지, Attack Feasibility가 바뀌는지까지 검토하는 경우는 드물다. 패치는 했지만 TARA·Requirement와 추적성이 끊기는 전형적인 패턴이다.

TARA 변경관리의 핵심 질문은 "다시 해야 하는가"가 아니다.

"이 변경이 보안 위험에 영향을 주는가 — 그리고 그 판단을 우리는 기록하고 있는가."

좋은 변경관리는 모든 변경을 TARA로 끌어올리는 것이 아니라, 영향 있는 변경을 놓치지 않는 것에서 시작된다.

핵심 요약

1

21434는 "이럴 때 TARA를 다시 해라"는 목록을 제공하지 않는다 — 변경 자체가 아니라 보안 영향 여부를 판단하라고 요구한다.

2

공격 표면·신뢰 경계·Asset 중요도가 바뀌면 재검토가 필요하다 — 새 인터페이스 추가, 기능 변경, 아키텍처 변경, CVE 발견이 대표적 트리거다.

3

변경 → SIA → TARA 판단 순서가 실무에서 잘 작동한다 — TARA 재수행 여부를 바로 논하지 말고, 먼저 보안 영향을 분석하는 단계를 두는 것이 핵심이다.

4

TARA가 바뀌면 Goal·Requirement·V&V도 함께 검토해야 한다 — TARA만 업데이트하고 멈추면 추적성이 끊긴다. OEM 심사에서 가장 많이 지적받는 패턴이다.

5

"영향 없음"도 문서화가 필요하다 — TARA를 업데이트하지 않은 결정도 근거가 기록되어 있어야 심사에서 설명된다.

TARA 변경관리 ChangeManagement ISO/SAE21434 SecurityImpactAnalysis 자동차사이버보안 추적성 CybersecurityCase CSMS 보안요구사항