차량 보안 사고는 언제 정부에 신고해야 할까? — 24시간 신고, 긴급조치, 최종조치의 의미

규제 · 인증

현장에서 자주 듣는 말

"IDS 경보가 뜨면 일단 정부에 신고부터 해야 하는 거 아닌가요?"

"24시간 안에 원인 분석까지 다 끝내야 신고할 수 있는 거 아닌가요?"

"긴급조치는 어차피 임시방편이니까 대충 해도 되지 않나요?"

"최종조치라고 하면 결국 펌웨어 패치 얘기 아닌가요?"

차량에서 비인가 진단 요청이 실제로 성공했거나, OTA 서버 취약점이 공격에 악용됐다면 — 제작사는 무엇부터 해야 할까요?

국토교통부 가이드라인은 이 질문에 꽤 명확한 답을 갖고 있습니다. 신고 대상은 "취약점이 실제로 악용된 경우"이고, 신고 기한은 인지 후 24시간 이내입니다. 그리고 신고는 끝이 아니라 시작입니다 — 그 뒤로 긴급조치, 최종조치, 정부의 점검까지 이어지는 절차가 기다리고 있습니다.

---

사고 신고, 기본 정보부터 정확히

구분	내용
신고 주체	CSMS 인증을 받은 제작사
신고 기한	제작사가 자동차 사이버보안 사고 발생을 인지한 후 24시간 이내
신고 방식	자동차 사이버보안 대응시스템(csms.kotsa.or.kr)을 통해 신고 (정보통신망법 관련 사고는 별도 표시)
신고 대상	자동차 사이버보안 취약점이 실제로 악용된 경우

법적 근거는 자동차관리법 제30조의12입니다 — 제작사는 CSMS 운영 중 사고가 발생한 때에는 국토교통부장관에게 즉시 그 사실을 신고해야 합니다.

---

보안 이벤트 · 취약점 · 사고는 다른 말이다

진단 인증 실패, IDS 경보, Gateway 차단, SecOC MAC Fail, OTA 실패, 비정상 CAN 메시지 탐지, ECU Reset — 이런 이벤트들이 발생했다고 곧바로 신고 대상이 되는 건 아닙니다. 신고 판단을 하려면 먼저 세 단어를 구분해야 합니다.

구분	의미	예시
보안 이벤트	보안상 의미가 있을 수 있는 관찰 결과	IDS 경보, 인증 실패, Gateway 차단
취약점	공격자가 악용할 수 있는 약점	인증 우회 가능성, 입력 검증 오류, 취약 라이브러리
사고	취약점이 실제로 악용되어 피해·위험이 발생한 상황	실제 비인가 접근 성공, 원격 기능 악용, 악성 업데이트 시도

❌ "IDS 경보가 뜨거나 취약점이 발견되면 무조건 정부에 신고해야 한다"

✅ 신고 대상은 "취약점이 실제로 악용된 경우"에 한정된다

내부 침투테스트에서 취약점이 발견된 것은 신고 대상이라기보다는 취약점 관리 대상입니다. 반대로 외부 공격자가 그 취약점을 실제로 이용해 차량 기능에 접근했다면 신고 대상이 됩니다. 즉 판단 기준은 "이상 징후가 있었는가"가 아니라 "취약점이 실제로 악용됐는가"입니다.

---

24시간은 "인지 시점"부터 센다

차량 보안 사고는 발생과 인지가 항상 동시에 일어나지 않습니다. 공격은 며칠 전에 발생했지만 VSOC 분석으로 뒤늦게 확인될 수도 있고, 외부 화이트해커가 먼저 악용 사례를 제보할 수도 있고, 정비소의 이상 증상 보고가 분석 과정에서 사고로 확인될 수도 있고, 협력사가 특정 SW 취약점 악용 사실을 통보해올 수도 있습니다. 24시간은 사고가 벌어진 순간이 아니라, 제작사가 그 사실을 인지한 순간부터 카운트됩니다.

💡 "24시간 안에 원인 분석까지 다 끝내야 하나?"라는 부담은 오해에서 옵니다. 24시간 신고는 완벽한 최종 보고서가 아니라, 정부가 사고 상황과 확산 가능성을 빠르게 파악할 수 있도록 하는 초기 신고입니다. 정확한 공격 경로, 전체 영향 차량 수, 취약 SW 버전, 협력사 원인 여부 같은 정보는 후속 분석을 통해 업데이트하면 됩니다. 중요한 건 사고를 숨기거나 늦추지 않고, 인지한 사실을 기준으로 먼저 신고하는 것입니다.

---

신고 이후 이어지는 8단계

자동차 사이버보안 사고 대응 절차

1

제작사 — 사고 인지 및 24시간 이내 신고

2

정부 — 사고 현황·확산 정도를 신속히 파악하고 후속 조치 사항 요구

3

제작사 — 긴급 조치 계획을 정부에 보고하고 시행

4

정부 — 긴급조치의 적정성·이행여부를 점검하고, 필요시 보완 요청(시정명령)

5

제작사 — 근본 원인을 분석해 최종 조치 계획을 보고하고 시행

6

정부 — 최종조치의 적정성·이행여부를 점검하고, 필요시 보완 요청

7

정부 — 조치 이행여부·적정성, CSMS 사고 절차 준수 여부를 종합 검토해 사고 종결 처리

---

긴급조치 — 피해 확산을 막는 시급한 조치

가이드라인은 긴급조치를 "해당 사고의 피해 확산 방지를 위한 시급한 조치"로 정의하며, 고객 통지·집중 모니터링·관련 차량 임시 조치 및 격리 등을 예로 듭니다. 실무적으로는 취약한 서버 API 임시 차단, 특정 원격 기능 일시 비활성화, 고위험 차량군 집중 모니터링, OTA 캠페인 일시 중지, 공격에 쓰인 인증서 폐기, Gateway 정책 임시 강화 같은 조치가 여기에 해당합니다.

⚠️ 긴급조치는 빠른 판단이 생명이지만, 과한 조치는 또 다른 문제를 만듭니다. 보안상 의심된다는 이유만으로 차량 기능을 무조건 차단하면 운행 안전이나 고객 피해로 이어질 수 있습니다. 긴급조치는 보안·안전·품질·고객 영향을 함께 고려해서 판단해야 합니다.

---

최종조치 — 근본 원인을 해결하는 조치

최종조치는 "해당 사이버보안 취약점의 근본 원인을 분석하고 이를 해결하기 위한 조치"이며, 펌웨어 업데이트·장비 교체 등을 예로 듭니다. 긴급조치가 "확산 방지"라면 최종조치는 "근본 해결"입니다. ECU 펌웨어 업데이트, OTA 보안 패치 배포, 취약 라이브러리 업데이트, 인증 로직 수정, 키·인증서 교체, Gateway Filtering 정책 변경, IDS 룰 업데이트, 재발 방지 절차 개선까지 — 최종조치는 기술 조치뿐 아니라 운영 절차 개선까지 포함할 수 있습니다.

구분	긴급조치	최종조치
목적	피해 확산 방지	근본 원인 해결
시점	사고 인지 직후	원인 분석 후
성격	임시·단기 조치	영구·근본 조치
핵심 질문	지금 더 큰 피해를 막을 수 있는가	같은 문제가 다시 발생하지 않게 해결했는가

ℹ️ 두 조치 모두 시행 전에 조치계획을 정부에 보고해야 합니다. 정부는 이행 여부와 적정성을 점검하고, 보완이 필요하면 시정을 명할 수 있습니다. 즉 제작사가 알아서 조치하고 끝내는 구조가 아니라, 매 단계 정부의 확인을 거치는 구조입니다.

---

사고 신고와 정기 위협정보 제출은 다르다

여기서 헷갈리기 쉬운 지점이 하나 있습니다. 가이드라인에는 사고 신고(24시간 이내) 말고도 "자동차 사이버공격·위협 정보 자료 제출"이라는 별도 의무가 있습니다. 이건 사고가 아니라 CSMS 인증을 받은 제작사가 정기적으로 제출해야 하는 자료입니다.

구분	제출 주기	내용
정기 제출	매년 2월 말, 전년도(1~12월) 수집 정보 대상	위협 정보 수집 현황, 기존 조치 유효성 평가, 추가 보완조치 현황
비정기 제출	별도 요구받은 경우 요구일로부터 15일 이내	인증기관이 별도로 요청하는 자료
사고 신고 (비교)	사고 인지 후 24시간 이내	취약점이 실제로 악용된 경우에 한정

정기 제출은 "그동안 어떤 위협 정보를 수집했고 기존 조치가 여전히 유효한가"를 보고하는 평시 모니터링 보고이고, 사고 신고는 "실제로 악용된 사고가 터졌다"는 비상 보고입니다. 둘을 같은 절차로 착각하면, 평소엔 연 1회 제출로 충분하다고 안심하다가 실제 사고 발생 시 24시간 대응 체계가 준비돼 있지 않을 수 있습니다.

---

실제 판단은 이렇게 갈린다

상황	판단
개발 중 침투테스트에서 진단 접근제어 취약점 발견 (판매 차량 미적용, 외부 악용 없음)	신고 대상 아님 — 개발 단계 취약점 처리 대상
화이트해커가 판매 차량에서 진단 서비스 인증 우회에 실제 성공, 재현 증거 제출	신고 대상 적극 검토 — 실제 악용 가능성이 확인된 상황
OTA 서버 인증 취약점이 공격에 사용돼 비정상 패키지 요청 발생 (업데이트 성공은 안 함)	긴급조치(캠페인 중지, API 차단) 및 신고 검토 필요
특정 차량군에서 비정상 진단 요청 이벤트 급증 (악용 미확인)	우선 모니터링·분석 대상 — 악용 확인 시 신고 절차로 전환

---

PSIRT와 VSOC의 역할 분담

탐지에서 신고 판단까지

VSOC
이벤트 탐지

→

PSIRT
취약점·사고 여부 판단

→

OEM 보안팀
신고·조치 계획 결정

→

개발/Tier-1/정비망/고객대응
긴급·최종조치 수행

VSOC가 이상 징후를 발견했다고 곧바로 신고 대상은 아닙니다. PSIRT(또는 보안 사고 대응 조직)가 취약점 악용 여부와 고객 차량 영향을 판단한 뒤에야 신고 여부가 결정됩니다.

실무에서 챙겨야 할 지점

증적은 시간 순서가 생명이다 — 언제 인지했고, 언제 신고했고, 언제 조치했고, 언제 효과를 확인했는지가 남아 있어야 나중에 정부·인증기관·고객·협력사에 설명할 수 있습니다.

정부 신고와 고객 통지는 다른 절차다 — 초기엔 정부에 먼저 신고하고 영향 분석 후 고객 통지 범위를 정할 수도 있고, 반대로 긴급한 고객 조치가 먼저 필요할 수도 있습니다. 둘을 하나의 절차로 뭉뚱그리면 판단이 늦어집니다.

협력사와의 역할은 사고 전에 정해둬야 한다 — 사고 원인이 항상 OEM 내부에 있는 건 아닙니다. Tier-1, 통신 모듈, 클라우드 서비스, 오픈소스 라이브러리 등에서 비롯될 수 있으므로, 사고 통보 기한·분석 지원 범위·로그 제공 범위를 계약 단계에서 미리 정의해야 합니다.

사고 종결이 끝이 아니다 — 모니터링이 충분했는지, 더 빨리 탐지할 수 있었는지, TARA와 보안 요구사항을 업데이트해야 하는지를 돌아봐야 CSMS가 실제로 개선됩니다.

차량 보안 사고 대응의 핵심은 "문제를 발견했는가"가 아니라, "인지 후 얼마나 빠르게 신고하고, 확산을 막고, 근본 원인을 해결했는가"입니다.

좋은 CSMS는 사고를 감추는 체계가 아니라, 사고를 통해 절차와 보안 조치를 개선하는 체계입니다.

핵심 요약

1

신고 대상은 "취약점이 실제로 악용된 경우"에 한정된다 — 단순 이벤트나 취약점 발견은 신고 대상이 아니다.

2

24시간은 발생 시점이 아니라 인지 시점부터 센다 — 완벽한 원인 분석이 아니라 신속한 초기 신고가 목적이다.

3

신고 이후 긴급조치 → 최종조치 → 사고 종결까지 정부 점검이 이어진다 — 신고는 끝이 아니라 시작이다.

4

긴급조치는 확산 방지, 최종조치는 근본 해결이다 — 성격과 시점이 다른 두 조치를 구분해야 한다.

5

사고 신고와 정기 위협정보 제출은 별개의 의무다 — 연 1회 정기 보고와 24시간 긴급 신고를 혼동하면 안 된다.

6

VSOC의 탐지가 곧바로 신고 판단은 아니다 — PSIRT·보안팀이 실제 악용 여부와 영향을 판단한 뒤 신고 여부가 결정된다.

※ 이 글은 국토교통부 「자동차 사이버보안 인증제도 가이드라인」(2026.5) 및 자동차관리법 제30조의12를 바탕으로 작성했습니다.

사고신고 24시간신고 긴급조치 최종조치 CSMS PSIRT VSOC 자동차관리법 규제대응