제8부 안전·보안·시스템공학

8.13 사이버보안 III: 제품·펌웨어 보안 — SBOM·서명·OTA·EU CRA·보안적합성

8.13.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자

8.11은 인증 제품의 감항 보안을, 8.12는 조직과 지상 체계의 보안을 다루었다. 이 장은 그 사이의 대부분의 제품, 곧 인증을 받지 않는 UAS와 그 구성품의 소프트웨어·펌웨어를 다룬다. 이런 제품은 항공 감항 규정이 아니라 일반 제품 보안 규제(EU 사이버복원력법 CRA, 무선기기 지침의 사이버 요구)와 시장 요구를 따른다. 핵심 주제는 다섯이다. 무엇이 들어 있는지 아는 것(SBOM), 변조되지 않았음을 확인하는 것(서명·보안 부팅), 안전하게 바꾸는 것(갱신·복구), 취약점을 다루는 것(수명 동안의 처리와 신고), 그리고 이를 요구하는 제도이다.

배우는 것:

• 제품 보안 규제의 지형 — CRA의 적용 범위와 인증 항공 제품·국방용의 제외, 무선기기 지침 위임 규정 2022/30, 감항 보안(8.11)과의 경계.
• CRA의 요구 — 부속서 I의 제품 속성 요구와 취약점 처리 요구, 지원 기간과 보존, 취약점·사고 신고의 시한, 적합성 평가 경로.
• 펌웨어 복원성 — NIST SP 800-193의 보호·탐지·복구와 갱신·탐지·복구 신뢰 루트.
• SBOM — NTIA 최소 요소와 실무 규칙, CRA에서의 위치, 깊이의 한계.
• 네 가지 계산 — 기단의 갱신 적용 속도와 노출 항공기·일, 서명 키 침해 뒤 폐기까지의 취약한 기간, 같은 사건에 대한 세 제도의 시한과 CRA 지원·보존 날짜, SBOM 깊이에 따른 포함 비율.
• 한국의 제품 보안 제도 — 보안적합성 검증, 정보통신망연결기기등 정보보호인증, SW 공급망 보안 가이드라인(2차 출처).

선수 지식: 2.10(보안 부팅·이중 슬롯·롤백 방지), 8.8(현장 적재 소프트웨어), 8.11(감항 보안), 8.12(Part-IS·NIS2)를 읽었다고 가정한다. 암호 규격·키 관리는 9.19가, 링크의 서명(MAVLink)은 9.5이, 하이재킹 대응은 8.16이 다룬다.

특히 중요한 독자: 엔지니어는 8.13.5~8.13.9를, 인증·법무 담당자는 8.13.3·8.13.4·8.13.10을, 정책 담당자는 8.13.3·8.13.10·8.13.11을, 사업 담당자는 8.13.10(경로 선택)과 8.13.12(설계 트레이드오프)를 먼저 읽는다.

기준 시점과 정직성. 2026년 11월 기준이다. 원문을 읽은 것: EU 위임 규정 2022/30(무선기기 지침의 사이버 요구, 관보 PDF), NIST SP 800-193(2018-05, 45쪽), NTIA의 SBOM 최소 요소(2021-07, 28쪽). CRA(규정 (EU) 2024/2847)는 EUR-Lex가 자동 응답으로 접근을 막아 관보 원문을 받지 못했다. 대신 비공식 사본(cyberresilienceact.eu의 조문·부속서)을 읽고, 위원회 요약 페이지와 핵심 사실(적용일, 24 h·72 h·14일·1개월 시한, 지원 기간 5년, 부속서 II의 SBOM 문구)을 교차 확인했다. 관보 조문과의 대조는 하지 못했으므로 CRA 인용은 (비공식 사본)이다. 읽지 못한 것: CISA의 2025 SBOM 최소 요소 초안(접근 차단, 검색 요약만), EN 18031 계열, ARINC 665·835, DO-326A·DO-356A, 한국 법령과 지침의 원문(보도와 해설만), 드론용 정보보호인증 해설서 본문. 읽지 못한 부분은 (확인 필요), 2차 출처는 (2차 출처)로 표시했다.

8.13.2 개념 — 제품은 팔린 뒤에도 취약해진다

제품 보안의 특징은 제품이 출하된 뒤에 위험이 늘어난다는 점이다. 출하 때 알려진 취약점이 없어도 구성요소(운영체제, 통신 라이브러리, 오픈소스 부품)에서 나중에 취약점이 발견된다. 그래서 제품 보안은 설계 때의 속성만이 아니라 수명 동안의 과정을 요구한다. 과정은 구성요소를 아는 것(SBOM), 변조를 막는 것(서명·보안 부팅), 고치는 것(갱신과 복구), 알리는 것(취약점 공개와 신고)으로 이어진다.

NIST SP 800-193은 펌웨어 복원성을 보호·탐지·복구 세 성질로 나눈다. 보호는 인가되지 않은 변경을 막는 것(인증된 갱신만 허용), 탐지는 변경이나 손상이 생겼을 때 알아채는 것, 복구는 손상된 펌웨어와 핵심 자료를 정상 상태로 돌리는 것이다. 이 틀은 2.10의 보안 부팅·이중 슬롯과 같은 구조이며 UAS의 비행 제어 컴퓨터·ESC·무선 모뎀·카메라·충전기처럼 변경 가능한 펌웨어가 있는 모든 장치에 적용된다. SP 800-193의 목적은 주로 원격 공격에 맞서 각 장치의 펌웨어와 핵심 자료를 인가되지 않은 변경에서 보호하고 무결성 상태로 복원하는 것이다(1.3절). 안전한 로컬 갱신을 구현한 장치는 악의적 관리자나 물리적 접근을 가진 공격에 취약할 수 있으므로 별도의 물리·환경·기술 보안 조치가 필요하고, 이는 범위 밖이다(3.5절).

항공 인증 제품과 일반 제품의 차이. 인증 항공 제품의 소프트웨어는 DO-178C의 개발 보증과 FLS 규정(8.8.5), 감항 보안(8.11)과 ICA를 따른다. 인증을 받지 않는 제품은 이 틀 밖에 있고 CRA 같은 일반 제품 규제가 같은 문제(구성요소, 서명, 갱신, 취약점 처리)를 다룬다. 두 체계는 같은 문제에 다른 수단을 사용한다. 감항 체계는 형식 설계의 적합성을, 일반 제품 규제는 제조자의 과정과 신고를 중심에 둔다.

8.13.3 규제의 지형과 적용 범위

CRA의 적용 범위(제2조, 비공식 사본). CRA는 의도된 목적이나 합리적으로 예상되는 사용이 장치나 네트워크에 대한 직접·간접의 논리적·물리적 데이터 연결을 포함하는 디지털 요소가 있는 제품에 적용한다(제1항). 아래는 제외 조항이다.

특정 범주·개방 범주 UAS는 어디인가. 제2조(3)의 문구는 "인증된(certified)" 제품이다. 형식증명이나 같은 수준의 인증을 받은 UAS(인증 범주)가 제외 대상이 되는 것은 분명하다. 개방 범주 UAS의 C 등급 표지는 규정 2019/945(2018/1139에서 위임)에 따른 적합성 선언이어서 이를 "인증된" 제품으로 볼 수 있는지, 아니면 CRA의 대상인지는 원문과 해석 지침 없이는 단정할 수 없다 (확인 필요). 이 장은 인증을 받지 않는 UAS 제품을 CRA가 적용될 수 있는 대상으로 다루고 적용 여부는 제품별 법률 검토로 남긴다.

CRA의 일정(제71조, 위원회 요약으로 교차 확인). 2024-12-10에 발효했고 제14조의 신고 의무는 2026-09-11부터 적용된다. 제4장(적합성 평가 기관의 통지)은 2026-06-11부터, 나머지는 2027-12-11부터 적용된다. 따라서 2026년 11월 현재 신고 의무는 이미 적용 중이고 설계·문서·적합성 평가 요구는 아직 적용 전이다. 출시 전 제품의 지원·보존 계산은 8.13.8에 있다.

무선기기 지침 위임 규정(EU) 2022/30(원문 확인). 인터넷에 연결되는 무선기기에는 네트워크 보호(제3조(3)(d)), 개인정보·프라이버시 보호(e), 사기 방지(f)의 필수 요구가 적용된다. 제1조는 (d)를 인터넷 연결 무선기기 전체에, (e)를 개인정보 등을 처리할 수 있는 기기에, (f)를 금전 이전을 가능하게 하는 기기에 적용한다. 제2조(2)는 규정 (EU) 2018/1139가 함께 적용되는 무선기기에는 (e)와 (f)를 적용하지 않는다고 한다. 따라서 문구상 (d)는 항공 규정이 적용되는 기기에도 남는다. 원문의 적용일은 2024-08-01이나 후속 위임 규정으로 2025-08-01로 연기되었다는 2차 출처가 다수 있다 (2차 출처, 개정 규정 원문 미확인). 조화 표준은 EN 18031 계열이라는 보도가 있다 (2차 출처). 드론이 인터넷 연결 무선기기에 해당하는지(예: 조종기·스마트폰을 거치는 경우)는 제품 구조에 따른다 (확인 필요).

감항 보안과의 경계. 인증 제품에서 소프트웨어 갱신은 FLS 규정과 FAA NPRM의 "이전(transfer)" 절차(8.11.10), AC 119-1A의 서명 절차와 개인 키 통제(8.11.10의 ANSP 구성 요소 7항)로 다룬다. 같은 기업이 인증 제품과 비인증 제품을 모두 만들면 두 체계의 요구를 한 개발·릴리스 과정이 만족하게 만드는 것이 비용 면에서 낫다(이 책의 견해, 8.13.12).

8.13.4 CRA의 요구 (비공식 사본)

부속서 I 제1부: 제품의 속성. 위험 평가(제13조(2))에 근거해 제품은 해당하는 만큼 아래를 갖춘다. ① 알려진 악용 가능한 취약점이 없는 상태로 출시, ② 보안 기본 설정과 초기화 기능, ③ 보안 업데이트로 취약점을 고칠 수 있음(자동 업데이트를 기본값으로 하되 끄기·연기 선택), ④ 인증·접근 관리로 비인가 접근 방지와 보고, ⑤ 저장·전송 자료의 기밀성 보호(암호화), ⑥ 자료·명령·프로그램·설정의 무결성 보호와 손상 보고, ⑦ 자료 최소화, ⑧ 필수·기본 기능의 가용성을 사고 이후에도 보호(서비스 거부 완화), ⑨ 다른 장치·네트워크의 가용성에 주는 부정적 영향 최소화, ⑩ 공격 표면과 외부 인터페이스 제한, ⑪ 악용 완화 기법으로 사고의 영향 감소, ⑫ 내부 활동과 접근·수정의 기록·감시(사용자가 해제할 수 있음), ⑬ 사용자가 자료·설정을 안전하게 영구 삭제할 수 있음. 이 목록의 ⑥은 UAS의 명령·프로그램·설정(비행 계획, 파라미터, 지오펜스)의 무결성에 직접 대응한다.

부속서 I 제2부: 취약점 처리. 제조자는 ① 구성요소와 취약점을 식별·문서화하고 SBOM을 일반적이며 기계가 읽을 수 있는 형식으로 작성하되 적어도 최상위 의존을 포함하고, ② 지체 없이 취약점을 고치고 업데이트를 제공하며(가능하면 기능 업데이트와 분리), ③ 효과적이고 정기적인 보안 시험·검토를 하고, ④ 업데이트가 제공된 뒤 고친 취약점의 정보를 공개하고, ⑤ 조정된 취약점 공개 정책을 시행하며, ⑥ 취약점 신고를 위한 연락처를 제공하고, ⑦ 업데이트를 안전하게 배포하는 메커니즘을 두고, ⑧ 업데이트를 지체 없이, 원칙적으로 무상으로 전파한다.

지원 기간과 보존(제13조). 제조자는 제품이 쓰일 것으로 예상되는 기간을 반영해 지원 기간을 정하며 최소 5년이다(예상 사용이 5년 미만이면 그 기간). 지원 기간 동안 부속서 I 제2부에 따라 취약점을 처리한다. 제공한 보안 업데이트는 발행 후 최소 10년 또는 지원 기간의 남은 기간 중 긴 쪽 동안 제공을 유지하고(제9항), 기술 문서와 적합성 선언은 출시 후 최소 10년 또는 지원 기간 중 긴 쪽 동안 보관한다(제13항). 지원 기간의 종료일(월·연)은 구매 시점에 명확하게 밝힌다(위원회 요약).

신고(제14조). 제조자는 악용되고 있는 취약점과 보안에 영향을 주는 중대 사고를 알게 되면 조정 CSIRT와 ENISA에 단일 신고 플랫폼으로 동시에 신고한다. 시한은 ① 알게 된 때부터 24시간 안에 조기 경보, ② 72시간 안에 통지, ③ 최종 보고는 취약점이면 시정·완화 조치가 제공된 뒤 14일 안, 사고이면 통지 후 1개월 안이다. 시한은 조사 완료가 아니라 제조자가 알게 된 인지 시점부터 센다. 영향받는 사용자에게도 알려야 한다(제8항). 중대 사고는 민감·중요 자료나 기능의 가용성·진본성·무결성·기밀성을 해칠 수 있거나, 악성 코드의 도입·실행으로 이어질 수 있는 경우이다(제5항).

적합성 평가(제32조, 부속서 III·IV). 기본 경로는 제조자의 내부 통제(모듈 A)이다. 부속서 III의 중요 제품 1종은 조화 표준 등을 적용하지 않았거나 일부만 적용하면 EU 형식 심사(B+C)나 완전 품질 보증(H)을 택하고, 중요 제품 2종은 B+C·H·사이버보안 인증 제도(보증 수준 '상당' 이상) 중 하나를 택한다. 부속서 III에는 부트 관리자, 운영체제, 보안 기능이 있는 마이크로프로세서·마이크로컨트롤러·ASIC·FPGA, 하이퍼바이저·컨테이너 런타임, 방화벽·침입 탐지·방지 시스템, 변조 방지 마이크로프로세서·마이크로컨트롤러 등이 있다. 부속서 IV의 핵심 제품(보안 상자 장치, 스마트 미터 게이트웨이와 고급 보안 장치, 스마트카드·보안 요소)은 유럽 사이버보안 인증을 요구할 수 있다. 드론이나 비행 제어기는 열거되지 않았으나 구성품으로 따로 판매되는 운영체제·부트 관리자·보안 마이크로컨트롤러는 해당할 수 있다 (분류는 확인 필요).

8.13.5 펌웨어 복원성 — NIST SP 800-193의 지침

SP 800-193(2018-05)은 신뢰 루트(RoT)에 기초한 세 성질의 지침을 구조화한다. 아래는 원문 4절의 핵심이다(shall은 RFC 2119의 뜻).

세 가지를 확인한다. 첫째, RTU·RTD·RTRec는 논리적 구성요소이며 서로 분리되어 있지 않아도 된다. 둘째, 원문의 주석은 갱신 가능한 키 저장소가 키 침해 복구 수단이지만 변조에 더 취약해질 수 있고, 갱신 불가능한 키 저장소를 사용하려면 서명 키 노출에 대한 완화·복구 수단을 설계하라고 권고한다. 이것이 8.13.7의 키 폐기 계산이 다루는 문제이다. 셋째, SP 800-193은 컴퓨터 보안 지침이며 항공 인증 요구가 아니다. UAS 장치에 적용하려면 안전 요구(2.10의 롤백 방지 카운터와 롤백 허용의 충돌)와 조정해야 한다.

8.13.6 SBOM — 무엇이 들어 있는가

NTIA의 최소 요소(2021-07) 는 세 부분이다.

• 데이터 필드(7개): 공급자 이름, 구성요소 이름, 구성요소의 버전, 그 밖의 고유 식별자, 의존 관계(상위 구성요소가 하위 구성요소를 포함한다는 관계), SBOM 데이터의 작성자, 타임스탬프.
• 자동화 지원: 자동 생성과 기계 판독이 가능한 형식(SPDX, CycloneDX, SWID 태그)이다.
• 실무와 절차: 빈도(새 빌드·릴리스마다 새 SBOM, 오류가 있으면 수정판), 깊이, 알려지지 않은 의존(known unknowns), 배포·전달, 접근 통제, 오류의 수용이다.

깊이와 알려지지 않은 의존. NTIA는 SBOM이 모든 최상위 구성요소와 그 이행적 의존 전체를 나열하는 것을 목표로 하되, 최소한 최상위 의존을 나열하고 이행적 의존을 재귀적으로 찾을 정보를 담으라고 한다. 전체 그래프를 나열하지 못하면 작성자는 알려지지 않은 의존을 명시해야 하고, 기본 해석은 데이터가 불완전하다는 것이다. 이 기본값 덕분에 "의존이 없는 구성요소"와 "의존을 모르는 구성요소"가 구분된다. 실무 사례로 "특정 구성요소가 조직 네트워크에 없음을 증명(prove the negative)"하려면 거의 완전한 그래프가 필요하다고 한다.

CRA에서의 위치. 부속서 I 제2부 제1호는 SBOM을 적어도 최상위 의존을 포함하는 기계 판독 형식으로 작성하라고 한다. NTIA의 기본 목표보다 낮은 최소선이다. 부속서 VII(기술 문서)는 취약점 처리 절차의 일부로 SBOM을 포함하고, 시장 감시 당국의 근거 있는 요청이 있을 때 SBOM을 제공한다고 한다. 사용자에게 SBOM을 제공하기로 하면 접근 위치를 알린다(부속서 II 제9호). 즉 SBOM은 사용자에게 의무로 공개하는 문서가 아니라 제조자의 내부 문서이며 당국에 제공하는 문서이다 (비공식 사본).

깊이가 얕으면 무엇을 놓치는가. 아래 계산은 구성요소 하나가 직접 의존하는 평균 개수를 $\lambda$, 트리의 단계를 5로 두고 단계 $i$에 $\lambda^{i}$개의 구성요소가 있다고 가정한다. $k$단계까지 나열한 SBOM이 포함하는 비율은 $\sum_{i\le k}\lambda^{i}\big/\sum_{i\le 5}\lambda^{i}$이다.

이 표는 트리 모형의 가정이다. 실제 의존 그래프는 같은 부품이 여러 곳에서 공유되고 분포가 치우쳐 있다. 요점은 값이 아니라 방향이다. 직접 의존만 나열한 SBOM은 이행적 의존에 있는 취약점을 찾지 못한다. 알려진 취약점이 공통 라이브러리에서 나올 때 이는 공통 소프트웨어를 사용하는 기단 전체의 노출(8.11.8)로 이어진다. 그래서 알려지지 않은 의존의 명시와 빈도·깊이 규칙이 필요하다. CISA의 2025 최소 요소 초안은 구성요소 해시, 라이선스, 도구 이름, 생성 맥락의 네 필드를 추가하자고 했다는 보도가 있으나 (2차 출처, 초안 원문 미확인).

항공 인증 제품의 대응 문서. DO-178C의 소프트웨어 형상 색인(SCI)은 소프트웨어 형상 항목과 버전을 정하는 인증 자료이다(8.8.4). SCI와 SBOM은 목적이 다르다. SCI는 형식 설계의 형상을 증명하고, SBOM은 취약점 대응을 위한 구성요소 목록이다. 오픈소스 구성요소를 사용하는 인증 제품이면 두 문서를 같은 형상 관리(8.22)에서 만들어야 불일치가 생기지 않는다(이 책의 견해).

8.13.7 워크스루 I — 기단의 패치 전파와 서명 키 폐기

문제. 취약점의 수정 업데이트가 나왔다. 기체가 500대인 기단에서 각 기체는 하루에 갱신 기회(착륙 뒤 지상 연결, 충전, 정비 입고)를 얻을 확률이 $p$이고 기체끼리 독립이라고 가정한다. 수정이 나온 지 $t$일 뒤에 갱신을 적용한 비율은 $1-(1-p)^{t}$이고, 비율 $q$에 이르는 시간은 $t_q=\ln(1-q)/\ln(1-p)$, 첫 기회까지의 평균은 $1/p$일, 노출 항공기·일의 기댓값은 $N/p$이다(8.13-calc.py).

읽을 것. ① 기단의 노출은 갱신 기회에 거의 반비례한다. 같은 수정이 나와도 매일 운용하는 기단은 8.4일에 95 %가 적용하고 분기 정비 기단은 268일이 걸린다. ② 앞의 8.11.8에서 본 공통 취약점의 동시 노출은 수정 이후에도 이 곡선만큼 이어진다. 공격자의 관점에서 수정의 공개는 아직 갱신하지 않은 기체의 목록을 만든다. ③ 곡선은 연속 운용을 가정한 것이다. 연결이 끊긴 채 보관 중인 기체, 배터리가 방전된 기체, 소유자가 갱신을 미루는 기체(CRA 부속서 I 제1부 (2)(c)의 "임시로 연기할 수 있는 선택")는 꼬리가 더 길다. ④ 기한을 정해 강제하면 꼬리가 잘린다. 예를 들어 수정 후 7일이 지난 뒤에는 갱신하지 않은 기체의 출동을 막는 정책이면 $p=0.1$ 기단의 미적용 비율이 47.8 %에서 0으로 줄지만, 그만큼 운용 가용성을 잃는다. 안전 임계 갱신과 일반 갱신을 구분하는 이유이다.

서명 키 침해와 폐기. 서명 키가 침해되면 공격자는 기체가 신뢰하는 서명으로 악성 펌웨어를 만들 수 있다. 신뢰를 거두려면 키 저장소를 갱신해야 하고(SP 800-193 4.1.2(4)), 이것도 위 곡선을 따라 기단에 전파된다. 취약한 기간은 탐지 지연 + 폐기 갱신의 준비 지연 + 기단 전파($t_{95}$) 이다. $p=0.1$이면 아래와 같다.

이 값은 키 저장소가 갱신 가능하고 루트 키가 남아 있을 때이다. 설계는 세 가지로 갈린다. ① 단일 키(서명 키가 곧 루트): 키가 침해되면 키 저장소 갱신도 서명할 수 없어 원격 복구가 없다. ② 루트 키(오프라인)와 릴리스 키(운용 환경)의 이중 구조: 릴리스 키가 침해되어도 루트 키가 폐기 갱신에 서명할 수 있어 위 표의 기간으로 복구한다. 루트 키가 침해되면 원격 복구가 없다. ③ 키 저장소를 갱신할 수 없는 설계: SP 800-193은 이 경우 서명 키 노출에 대한 완화·복구 수단을 설계하라고 권고한다. 복구는 현장 교체나 장치 교체이다. 루트 키를 오프라인에 두고 접근을 통제하는 것이 AC 119-1A의 "부품 서명 절차와 개인 키 접근 통제"(8.11.10)와 AMC 20-42 9절의 키 관리 절차에 대응한다.

한계. 확률 $p$는 독립·정상 상태의 가정이고 기단의 운용 형태(요일·계절)는 반영하지 않았다. 강제 정책이나 연결 상태, 소유자의 선택은 곡선을 크게 바꾼다. 서명 알고리즘과 키 길이는 이 장의 범위 밖이다(9.19).

8.13.8 워크스루 II — 같은 사건의 세 시계, 지원·보존 날짜, 과징금

한 사건에 여러 시계가 돈다. 항공 설계 조직이면서 EU 시장에 인증을 받지 않는 제품도 파는 제조자가 악용되고 있는 취약점을 2026-11-02 22:00 UTC에 알았고 수정이 9일 뒤에 제공된다고 하자. 해당하는 제도를 모두 적용하면 시한이 아래 순서로 온다(8.13-calc.py).

세 가지를 읽을 수 있다. 첫째, 24시간이 가장 빠른 시한이고 CRA와 NIS2의 시한이 중복된다. 둘째, 같은 사건이어도 대상 사건의 정의가 달라 모든 시계가 도는 것은 아니다(악용 취약점이나 보안 중대 사고는 CRA, 안전에 중대한 위험은 Part-IS, 서비스에 중대한 영향은 NIS2). 셋째, CRA 제69조(3)은 제14조의 신고 의무가 2027-12-11 이전에 시장에 나온 모든 범위 내 제품에도 적용된다고 하므로 신고 의무는 출시 시점과 무관하게 지금(2026-09-11부터) 적용된다. 반면 부속서 I의 제품 속성 요구는 2027-12-11 이전에 출시한 제품에는 그 뒤 실질적인 변경이 있을 때만 적용된다(제69조(2)).

지원·보존 날짜(CRA 제13조). 출시일 2028-03-01이고 지원 기간이 최소 5년이면 다음과 같다.

UAS 기체의 수명이 5~10년이므로 업데이트 제공 유지의 기간이 기체 수명보다 길 수 있다. 서명 인프라와 키 보관, 배포 서버를 이 기간 동안 유지할 책임이 제조자에게 있다(이 책의 정리).

CRA와 NIS2의 과징금 상한. CRA 제64조(2)는 부속서 I 필수 요구와 제13·14조 위반에 1,500만 유로와 전 세계 연 매출 2.5 % 중 큰 값, (3)은 일부 의무에 1,000만 유로·2 %, (4)는 부정확한 정보 제공에 500만 유로·1 %를 상한으로 한다(비공식 사본). 제64조(2)에서 고정액과 매출 비례 값이 같아지는 매출은 $15\text{M}/0.025=600\text{M}$ 유로이다(8.12.7의 NIS2는 500M 유로).

이 값은 EU 규정이 정한 상한이다. 실제 과징금은 시장 감시 당국이 사안별로 정하며 이 장은 그 기준을 읽지 못했다 (확인 필요).

8.13.9 서명·갱신 설계의 원칙

위 문서들이 공통으로 요구하는 설계 원칙을 UAS 장치에 대응시키면 아래와 같다. 각 항목은 근거 문서를 밝힌다.

1. 갱신 경로를 하나로 한다. 인증된 갱신 메커니즘이 펌웨어를 바꾸는 유일한 수단이다(SP 800-193 4.1.2(5)). 개발용 디버그 포트·부트로더 모드·무선 설정 도구는 유일한 경로를 우회하는 길이므로 제품 출시에서 닫거나 인증을 거치게 한다(CRA 부속서 I 제1부 (j) 공격 표면과 외부 인터페이스 제한).
2. 서명 키를 계층화한다. 루트 키는 오프라인에 두고 릴리스 키와 키 저장소 갱신에만 사용한다(8.13.7). 개인 키 접근은 통제하고 서명 절차를 문서화한다(AC 119-1A 10.2의 7항, AMC 20-42 9절의 키 관리).
3. 갱신 중 사고에도 장치가 동작을 유지하게 한다. 갱신 중 전원 상실이 있어도 장치가 동작하거나 다음 재부팅에서 복구할 수 있어야 한다(SP 800-193 4.1.2(2)). 이중 슬롯과 확정이 이 요구를 만족하는 방식이다(2.10).
4. 보안과 안전의 충돌을 조정한다. 롤백 방지 카운터(보안)와 롤백 허용(안전)은 충돌한다. 카운터는 새 이미지를 확정한 뒤에만 올린다(2.10).
5. 비행 중과 안전 임계 단계에서는 활성화하지 않는다. FLS 규정은 비행 중이나 안전 임계 단계에서 적재 기능이 의도치 않게 활성화되는 것을 막는 방호를 요구한다(AC 20-115D 8.b, 8.8.5).
6. 자료와 설정도 보호한다. 지오펜스·비행 한계·파라미터·키 저장소는 코드와 같은 무결성 보호를 받아야 한다. SP 800-193은 핵심 자료의 보호·탐지·복구를 포함하고, CRA 부속서 I 제1부 (f)는 명령·프로그램·설정의 무결성을 요구한다.
7. 호스트에서 온 정보를 신뢰하지 않는다. 호스트 프로세서의 소프트웨어가 펌웨어에 전달한 정보는 신뢰하지 않는다(SP 800-193 4.1.1(6)). 임무 컴퓨터·지상 연결에서 비행 제어기로 가는 명령은 8.11.6의 분리 구조에서 관문을 거친다.
8. 적용 이력을 남긴다. 적용한 버전과 파라미터를 기록해 사고 조사와 신고(CRA 제14조)에 대비한다(8.23, CRA 부속서 I 제1부 (l) 기록·감시).
9. 취약점 접수 창구와 공개 정책을 둔다. 조정된 취약점 공개 정책과 연락처(부속서 I 제2부 (5)·(6), 부속서 II 제2호)는 인증 제품에서도 ICA의 보고 체계(8.11.10)와 연결한다.

8.13.10 경로 선택 — 제품 유형별 적용 제도

아래는 이 장과 앞 장의 원문을 읽은 범위의 정리이다. CRA의 적용 여부는 제품별 법률 검토가 필요하다.

8.13.11 한국의 제품 보안 제도 (2차 출처)

한국 제도는 법령 원문을 읽지 못했고 보도와 해설로만 확인했다. 아래는 확인한 범위의 요약이며 모두 (2차 출처, 확인 필요)이다.

• 보안적합성 검증. 국가·공공기관이 도입하는 방화벽·네트워크 장비 같은 IT 보안제품의 안전성을 국가정보원이 검증하는 제도이다. 국정원법·전자정부법·사이버안보업무규정 등이 근거로 제시된다. 2022년에 기관의 중요도에 따라 가·나·다 세 그룹으로 나누어 검증 요건을 달리했고, '나' 그룹은 보안기능확인서·국내외 CC 인증서·성능평가결과확인서·신속확인서 중 하나만 있으면 검증을 생략할 수 있다고 보도되었다. 보안기능 확인서의 유효기간은 적용 기준에 따라 5년 또는 2년이다. 2024-04-01부터 IP 카메라·NVR 같은 영상정보처리기기도 대상이 되었다고 한다. 드론이 대상에 해당하는지, 해당한다면 어떤 범주인지는 확인하지 못했다.
• 정보통신망연결기기등 정보보호인증. 정보통신망법 제48조의6에 따른 IoT 기기 보안인증이며 8개 분야 중 교통(드론)이 있다. 2024-06에 과기정통부·KISA가 드론용 상세 해설서를 배포했고(정보보호산업진흥포털에서 내려받기), 2020-12에는 KISA가 일반 안내서인 '드론 사이버보안 가이드'를 발간했다고 한다. 인증기준의 항목은 확인하지 못했다.
• 소프트웨어 공급망 보안 가이드라인 1.0. 2024-05에 과기정통부·국정원·디지털플랫폼정부위원회가 KISA와 함께 공개했고, SBOM 작성부터 취약점 탐지·조치까지의 절차와 공급망 단계별 점검 항목 30개를 담았다고 한다. 법적 의무가 아닌 가이드라인이다.

한국 제도와 CRA의 대응을 비교하려면 국정원의 시험 기준과 인증기준 원문이 필요하다. 이 장은 비교하지 않고 확인한 사실만 적었다. 국내 항공보안·드론 보안 규제는 18.28이 다룬다.

8.13.12 설계 트레이드오프 — 갱신 방식

1. ① 정비소 로컬 적재. 정비 인원이 서명된 이미지를 유선·USB로 적재한다. 장점은 공격 표면이 좁고(무선 갱신 경로가 없다) 인증 제품의 FLS·ICA 절차와 같으며 큰 이미지에도 맞다는 점이다. 단점은 갱신 기회 $p$가 정비 주기에 묶여 노출이 길고(8.13.7의 분기 정비 예: $t_{95}=268$일), 정비 PC가 공급망의 약점이 된다는 점이다.
2. ② 무선 갱신(OTA). 지상국이나 클라우드가 서명된 이미지를 보낸다. 장점은 $p$가 높아져 노출이 짧다는 점이다(매일 운용 기단은 $t_{95}=8.4$일). 단점은 공격 표면이 늘고(원격 접근 경로, 갱신 서버), 서명 서버와 키 보관이 상시 운영 대상이 되며, 작은 텔레메트리 링크로는 큰 이미지를 보낼 수 없다(2.10)는 점이다.
3. ③ 하이브리드. 작은 패치와 파라미터는 OTA로, 큰 이미지와 안전 임계 갱신은 로컬 적재나 델타로 한다. 장점은 두 방식의 장점을 목적별로 취한다는 점이다. 단점은 정책이 둘이 되어 형상 관리(8.22)와 서명 체계가 복잡해진다는 점이다.

견해: 인증 제품은 ①을 기본으로 하고, 비인증 상용 기단은 ③으로 가되 안전 임계 갱신에는 기한을 둔다. 근거는 두 가지이다. 인증 제품의 소프트웨어 갱신은 FLS와 ICA 절차(8.8.5, 8.11.10)로 통제되고 형식 설계와의 적합성이 우선이며, 기단 노출은 갱신 기회가 정한다는 계산(8.13.7)은 매일 운용하는 상용 기단에서 OTA가 가장 큰 효과가 있음을 보이기 때문이다. 이것은 이 책의 견해이다.

8.13.13 세 축 비교

8.13.14 관련 규격·프로토콜

전체 지도는 A.6에 있다.

8.13.15 관련 규제·인증 요구와의 연결

• 감항 보안(8.11)·조직 보안(8.12). 인증 제품은 CRA 밖이고 두 장의 틀이 대상이다. 같은 제조자가 인증·비인증 제품을 함께 만들면 한 개발·릴리스 과정으로 두 체계를 만족하게 한다.
• 비행 소프트웨어 구조(2.10). 보안 부팅·이중 슬롯·롤백·확정은 SP 800-193의 RTU·RTD·RTRec에 대응한다.
• 소프트웨어·하드웨어 보증(8.8). FLS 규정과 SCI는 인증 제품의 갱신·구성의 기준이고, SBOM은 취약점 대응의 구성 목록이다.
• 형상 관리·변경 관리(8.22). 서명된 이미지, 버전, SBOM, 갱신 이력을 같은 형상 체계에서 관리한다.
• 비행데이터 기록(8.23). 적용 버전과 파라미터의 이력은 사고 조사와 신고의 근거이다.
• 사고·사건 보고(8.24). CRA의 24 h·72 h 신고와 Part-IS의 보고, 376/2014 체계를 한 절차로 맞춘다.
• 기단 사이버 운영(8.15). 취약점 감시, 사고 대응, 패치 정책(기한 강제)은 운영의 몫이다.
• 하이재킹 대응(8.16)·링크 서명(9.5). 링크 수준의 서명과 키 관리는 별도 장이다.
• 암호·키(9.19)·통신 보안(3.18). 서명 알고리즘·키 길이·키 관리 규격.
• 제품 규제·시장감시(17.18). 전파·EMC·CE와 CRA·RED의 통합 요구.
• 전파·적합성(18.16)·국내 보안 규제(18.28). 한국의 무선 설비 적합성과 보안 제도.

8.13.16 함정과 한계

미해결 문제. 개방 범주 C 등급 UAS의 CRA 적용(제2조(3)의 "인증"), 인증 제품과 비인증 구성품의 경계, 인증 UAS용 구성품의 SBOM 요구, 항공 인증과 CRA의 중복 부담, 한국 보안 인증기준과 CRA의 대응, 서명 키 폐기의 안전 영향은 이 장의 자료로 답할 수 없다 (확인 필요).

8.13.17 체크포인트·연구 질문

체크포인트:

1. 기단이 1,000대이고 $p=0.05$/일이면 $t_{95}$, 평균 시간, 노출 항공기·일을 구하라.
2. 서명 키 침해를 4일 뒤에 탐지하고 폐기 갱신 준비에 3일이 걸리며 $p=0.1$/일이면 95 % 적용까지의 일수를 구하라.
3. 악용 취약점을 2027-03-30 14:30 UTC에 알았고 수정이 5일 뒤에 제공될 때 CRA의 세 시한을 구하라.
4. 출시일 2029-06-01, 지원 기간 5년, 보안 업데이트를 출시 후 3년에 발행하면 보존 날짜들은 언제인가.
5. $\lambda=2$, 5단계 트리에서 3단계까지 나열한 SBOM의 포함 비율과, 직접 의존만 나열한 SBOM이 놓치는 비율을 구하라.
6. 인증된 eVTOL과 인증을 받지 않는 소형 UAS에 적용되는 제도를 표 8.13.10으로 비교해 설명하라.
7. SP 800-193의 RTU·RTD·RTRec를 UAS 비행 제어 컴퓨터의 보안 부팅·이중 슬롯과 대응시켜라.

연구 질문(25.7에 모은다):

• 개방·특정 범주 UAS가 CRA의 대상인지 정하는 기준은 무엇이며 항공 규정과 어떻게 조정되는가.
• 기단의 갱신 기회 $p$를 운용 데이터로 추정하고 안전 임계 갱신의 기한을 어떻게 정할 것인가.
• 서명 키 계층과 폐기를 안전 요구(롤백·가용성)와 함께 설계하는 방법은 무엇인가.
• SBOM의 깊이와 항공 인증의 구성 문서(SCI)를 어떻게 통합할 것인가.

1차 출처(이 장):

• EU, Commission Delegated Regulation (EU) 2022/30 (OJ L 7, 12.1.2022) — 제1·2·3조. 관보 PDF.
• NIST, SP 800-193 Platform Firmware Resiliency Guidelines (2018-05) — 1.3·3.6·4.1~4.2절. 무료 공개.
• NTIA, The Minimum Elements for an SBOM (2021-07) — 데이터 필드·자동화·실무와 절차. 무료 공개.
• EU, Regulation (EU) 2024/2847 (CRA) — 비공식 사본(cyberresilienceact.eu)의 제1~3·13·14·32·64·69·71조, 부속서 I·II·III·IV·VII 확인. 위원회 요약 페이지로 적용일·시한을 교차 확인했다 (관보 원문 대조 미확인).
• CISA 2025 SBOM 최소 요소 초안, EN 18031, ARINC 665·835, DO-326A·DO-356A, 한국 법령·지침 원문, 드론 정보보호인증 해설서 — 읽지 못함 (확인 필요).

다음 장: 8.14는 군 사이버 운용 인가(RMF·ATO)와 방산 공급망 보안(CMMC)으로 군사 중심 장이므로 건너뛴다(BK-08). 이어서 8.15 — 기단 사이버 운영: 보안관제·사고대응·침투시험으로 간다. 이 장이 제품과 갱신의 보안을 다루었다면, 8.15는 운용 중인 기단을 감시하고 사고에 대응하며 침투 시험을 하는 운영을 본다.