EU 취약점 신고 의무 시작…24시간 안에 완성 보고서는 아니다
유럽연합(EU) 사이버복원력법(CRA) 제14조의 보안 신고 의무가 2026년 9월 11일 적용되기 시작했다. IT Pro의 9월 11일 보도 도 EU 시장의 디지털 요소 제품 제조사에 적극 악용 중인 취약점과 중대한 보안 사고를 단계적으로 신고하는 의무가 이날부터 적용됐다고 확인했다.
핵심은 첫 제출이 완성된 조사 보고서가 아니라는 점이다. EU에 소프트웨어나 연결형 하드웨어를 공급하는 한국 기업도 제조사에 해당할 수 있으며, 신고 대상 상황을 인지하면 24시간 조기 경보를 먼저 내고 72시간 상세 통지와 유형별 최종 보고를 이어가야 한다.
24시간·72시간·최종 보고는 서로 다른 단계다
EU 집행위원회의 CRA 신고 안내 에 따르면 제조사는 신고 대상 상황을 인지한 뒤 24시간 안에 조기 경보, 72시간 안에 상세 통지를 제출해야 하며, 적극 악용 취약점의 최종 보고는 시정 또는 완화 조치가 제공된 뒤 14일 이내, 중대한 사고의 최종 보고는 72시간 통지 후 한 달 이내에 내야 한다. 같은 안내는 CRA Single Reporting Platform(SRP)이 2026년 9월 11일부터 운영되고, 오픈소스 소프트웨어 관리자에게 적용되는 별도 신고 의무는 2027년 12월 11일 시작된다고 명시한다.
신고 시계는 취약점이 생긴 날이나 CVE가 공개된 날이 아니라 제조사가 신고 대상 상황을 인지한 때부터 흐른다. 첫 단계에서는 당시 확보한 기본 사실을 알리고, 다음 통지에서는 사건의 성격과 초기 심각도 판단, 가능한 완화 조치 등 확인된 내용을 보강한다. 조사가 진행 중이라는 이유만으로 첫 제출을 미룰 수 있는 구조는 아니다.
최종 보고는 앞선 통지와 목적이 다르다. 원인과 실제 영향, 시정 조치처럼 조사와 대응을 거쳐야 확정할 수 있는 내용을 정리하는 단계다. 따라서 제목의 ‘24시간 안에 완성 보고서는 아니다’라는 표현은 조기 경보와 최종 보고를 분리한 법정 절차를 가리킨다.
모든 CVE가 자동으로 신고 대상이 되는 것은 아니다
신고를 작동시키는 범주는 제품에 영향을 미치는 적극 악용 중인 취약점과 중대한 보안 사고다. 단순히 CVE가 배정됐거나 외부 라이브러리에 결함이 있다는 사실만으로 신고 의무가 자동 발생한다고 단정할 수 없다. 제조사는 실제 악용을 뒷받침하는 신뢰할 만한 증거가 있는지, 사고가 제품의 보안 기능이나 데이터 기밀성·시스템 무결성에 중대한 영향을 주는지 확인해야 한다.
아일랜드 국가사이버보안센터의 시행 안내 는 제3자 구성요소에서 적극 악용 취약점이나 중대한 사고가 발생하더라도 자사 완제품이 영향을 받은 것으로 확인되면 최종 제품 제조사가 신고해야 하며, 2027년 12월 이전에 출시됐더라도 현재 EU 시장에서 제공되는 관련 제품은 신고 의무의 적용을 받는다고 설명한다. 반대로 제품에 포함되지 않은 버전의 결함이나 자사 출시 제품에 영향을 주지 않는 취약점까지 같은 사건으로 신고해야 한다는 뜻은 아니다.
실제 판단에서는 취약점 식별자보다 제품과의 연결 관계가 중요하다. 어떤 출시 제품과 버전에 문제의 구성요소가 들어갔는지, 해당 구성요소가 공격 가능한 형태로 사용됐는지, 실제 악용 증거를 언제 확보했는지를 구분해야 한다. 처음에는 영향이 없다고 판단했다가 새로운 증거로 결론이 바뀌면 인지 시점도 다시 검토할 필요가 있다.
한국 기업은 국적보다 EU 시장에서의 역할을 따져야 한다
CRA 적용 가능성은 개발 조직이 한국에 있다는 사실보다 제품이 EU 시장에 제공됐는지, 기업이 그 제품에서 어떤 법적 역할을 맡는지에 달려 있다. 네트워크에 직접 또는 간접 연결되는 소프트웨어와 하드웨어가 중심 범위이며 운영체제, 모바일 앱, 스마트 기기, 산업용 사물인터넷 제품 등이 포함될 수 있다. 다만 연결되지 않는 제품과 별도 규제가 적용되는 일부 분야에는 예외가 있어 개별 제품 단위의 판단이 필요하다.
한국 기업이 자체 이름이나 상표로 완제품을 EU 시장에 공급한다면 제조사 역할을 우선 검토해야 한다. EU 수입자나 유통 파트너가 있다는 이유만으로 제품의 기술적 영향 판단과 제조사 신고 책임이 자동으로 이전된다고 볼 수는 없다. 반면 다른 회사의 완제품에 들어가는 부품이나 모듈만 제공한다면 계약 명칭이 아니라 실제 출시 구조와 법적 역할을 확인해야 한다.
- 완제품 제조사: 자사 코드와 제3자 구성요소 가운데 실제 판매된 제품 버전에 포함된 항목을 식별해야 한다.
- 부품·모듈 공급자: 자체적으로 EU 시장에 제공하는 제품인지, 다른 제조사의 제품 개발에 정보를 제공하는 위치인지 구분해야 한다.
- EU 파트너를 둔 한국 제조사: 제품 영향 판단, SRP 제출, 이용자 대응을 각각 누가 담당하는지 정해 법정 시계가 시작된 뒤의 전달 지연을 줄여야 한다.
오픈소스 소프트웨어 관리자의 별도 의무가 2027년 12월에 시작된다는 사실도 상용 완제품 제조사의 현재 책임과 혼동해서는 안 된다. 오픈소스 구성요소를 상용 제품에 통합한 제조사는 해당 구성요소가 자사 제품에 미친 영향을 기준으로 2026년부터 적용된 신고 의무를 판단해야 한다.
신고는 ENISA 단일 플랫폼에서 한 번 제출한다
제조사는 CRA SRP를 통해 신고서를 한 번 제출한다. 신고는 원칙적으로 제조사의 주된 사업장이 있는 회원국의 컴퓨터보안사고대응팀(CSIRT)을 대상으로 하며, 특별한 예외가 없다면 ENISA에도 동시에 제공된다. 최초로 받은 CSIRT는 제품이 제공된 다른 회원국의 CSIRT에 관련 신고를 전달한다.
한국 본사와 EU 법인·수입자 사이에서는 누가 SRP의 실제 제출 주체인지 별도로 확인해야 한다. 법정 기한은 내부 승인 완료 시점이 아니라 제조사가 사건을 인지한 시점을 기준으로 움직이므로, 보안 제보 접수 기록과 제품별 구성 정보, EU 측 연락 체계가 서로 분리돼 있으면 초기 신고에 필요한 사실을 모으는 시간이 줄어든다.
지금 적용된 것은 CRA 전체 기술 요구사항이 아니라 제14조 신고 의무다. 제품의 보안 설계, 취약점 처리와 적합성 평가를 포함한 주요 의무의 전면 적용은 2027년 12월에 이어진다. 현재 제조사가 해야 하는 일은 완성된 원인 분석을 하루 안에 만드는 것이 아니라, 신고 대상임을 인지한 순간부터 조기 경보·상세 통지·최종 보고를 서로 다른 마감으로 관리하는 것이다.
함께 읽기:
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.