11장: 취약점 공개 및 보안 업데이트

FileBolt는 책임 있는 공개를 장려하며, 예측 가능한 수정과 소통 체계를 통해 신뢰를 쌓습니다. 동시에 보안 기능은 계속 발전할 수 있어야 합니다. 여기에는 웹 보안 정책, 서버 측 인증 메커니즘, 종단 간 암호화/프로토콜 구현(예: cryptoVersion 업그레이드)이 포함됩니다. 이 장에서는 공개 연락 채널, 처리 절차, 수정 배포 및 공지 원칙을 정리하고, 버전별 발전 방식과 지원 중단 전략을 설명합니다.

11.0 요약

MUST: 공개 취약점 제보 채널을 제공합니다(예: security.txt 및 지원 이메일).
SHOULD: 세부 내용을 안전하게 제보할 수 있도록 암호화된 제보 수단(예: PGP 키)을 제공합니다.
SHOULD: 명확한 대응 및 수정 주기(SLA/목표 일정)를 정하고, 필요할 때 상태 페이지를 통해 알립니다.
MUST: 영지식 약속에 영향을 줄 수 있는 취약점(XSS, 공급망 주입, 로그 조각 유출)을 최우선으로 처리합니다.
MUST: 버전별 발전 체계(cryptoVersion)를 구현하고, 호환성, 마이그레이션 및 지원 중단 전략을 정의합니다.

11.1 취약점 제보 채널 및 연락처

11.1.1 공개 접수 창구

MUST: 취약점 제보 채널, 만료일, 정책 링크를 /.well-known/security.txt에 제공합니다.
MUST: 연락 가능한 보안 담당 이메일을 제공합니다(예: support@filebolt.net 또는 전용 security@filebolt.net).
SHOULD: 보안 및 개인정보 보호 페이지에 간단한 안내와 제보 지침을 제공합니다.

11.1.2 암호화된 제보 및 민감 정보 처리

SHOULD: 연구자가 재현 세부 정보를 안전하게 제출할 수 있도록 PGP 공개 키(또는 이에 상응하는 수단)를 제공합니다.
MUST: 내부적으로 취약점 세부 정보는 최소 권한 원칙에 따라 열람 범위를 제한하고, 수정에 필요한 담당자에게만 공유합니다.
MUST: 연구자가 보고서에 사용자 평문, CEK, URL 프래그먼트, 또는 키 자료를 유추할 수 있는 정보를 포함하지 않도록 요청합니다. 실수로 포함된 경우 팀은 이를 민감한 사고로 취급하고 전파를 제한해야 합니다.

11.2 응답 일정 및 소통 원칙

일정은 팀 규모와 문제의 복잡도에 따라 달라지지만, 프로젝트는 예측 가능한 목표 주기를 제시하고 목표를 지키지 못할 경우 즉시 알려야 합니다(SHOULD). 권장 목표는 다음과 같습니다(실제 상황에 맞게 조정할 수 있으며 /security 또는 security.txt에 게시합니다).

최초 응답: 예: 48시간 이내에 접수 사실을 알리고 추적 ID를 부여합니다.
초기 평가: 예: 7일 이내에 심각도 등급 분류와 영향 범위 평가를 마칩니다.
수정 배포: 심각도에 따라 진행하며, P0/P1은 신속한 수정과 배포를 우선합니다.

SHOULD: 처리하는 동안 필요한 소통(예: 재현됨/재현되지 않음, 추가 정보 필요, 예상 수정 시기)을 이어 가고, 악용 가능한 세부 정보는 공개하지 않습니다.

11.3 공개 절차

접수: 보고 내용, 재현 절차, 영향, 연구자 연락처를 기록하고 담당자를 지정해 추적합니다.
검증: 격리된 환경에서 재현하고, 영향 범위, 악용 가능성, 영향받는 구성 요소(프런트엔드/백엔드/엣지/스토리지)를 평가합니다.
수정: 패치를 적용하고, 테스트/회귀 케이스를 추가하며, 필요하면 보호 규칙(WAF/속도 제한/정책 강화)을 추가합니다.
배포: 카나리 배포로 주요 지표를 모니터링하고, 회귀나 새로운 위험이 없음을 확인한 뒤 전체 배포합니다.
공지: 공격 표면을 넓히지 않는 범위에서 영향, 수정 내용, 사용자에게 필요한 조치(있는 경우)를 공개적으로 설명합니다.

치명적인 취약점이나 사용자 영향이 큰 사건의 경우, 10장의 사고 대응 절차에 맞춰 /status 를 통해 사건 업데이트나 사후 분석 보고서를 게시해야 합니다(SHOULD).

11.4 영지식 경계에 영향을 주는 취약점

영지식 약속의 핵심은 서버가 CEK에 접근할 수 없고, 다운로드/복호화 환경이 서드파티 스크립트 없이 최대한 격리된다는 점입니다. 따라서 다음 범주는 반드시 최우선으로 처리해야 합니다(MUST).

XSS / 인젝션: 다운로드/복호화 페이지에서 임의의 스크립트를 실행하여 프래그먼트나 메모리의 키 자료를 읽을 수 있는 경우.
공급망 주입: 의존성 오염, 빌드 산출물 교체, CDN/엣지 주입으로 인한 스크립트 변조.
로그/모니터링 유출: URL 프래그먼트, CEK, 토큰 또는 평문이 실수로 로그에 기록되어 접근 가능해지는 경우.
잘못된 리소스 로딩 정책: 다운로드/복호화 페이지가 서드파티 스크립트를 불러오거나, CSP 완화로 실행 가능한 범위가 넓어지는 경우.

대응에는 다음이 포함되어야 합니다. 즉각적인 차단(위험한 코드 내리기/정책 강화/공격 경로 차단), 신속한 수정 배포, 사후 영향 분석, 그리고 공지에 "키 자료나 평문이 노출되었을 가능성이 있는지"를 명확히 밝히는 것입니다.

11.5 보안 업데이트 및 회귀 검증

MUST: 보안 관련 변경(인증, 접근 제어, CSP, 로그 필터링, 암호화 흐름)에 대한 회귀 케이스를 마련합니다.
SHOULD: 핵심 페이지(다운로드/복호화)에 대해 자동 점검을 수행하여 서드파티 스크립트가 없고 헤더 정책이 기대와 일치하는지 확인합니다.
SHOULD: 수정 배포 후 외부에서 검증 가능한 항목(예: TLS/보안 헤더 스캔)을 다시 테스트합니다.
SHOULD: 수정으로 인해 생기는 호환성 변경(예: 이전 링크/이전 매니페스트)을 문서에 명확히 기록합니다.

12장과 같은 맥락에서, 서드파티 스캔은 일부 웹 기준을 검증할 수는 있지만 영지식/E2EE 구현의 세부 사항 전체를 직접 증명할 수는 없습니다. 따라서 회귀 검증은 프로토콜 구현과 외부에서 확인 가능한 기준을 모두 포함해야 합니다.

11.6 프로토콜 및 암호화 버전 관리(cryptoVersion)

FileBolt의 암호화 및 프로토콜 구현은 알고리즘 업그레이드, 구현 결함 수정, 더 강력한 격리 도입을 쉽게 하도록 버전 관리를 지원해야 합니다(MUST). 매니페스트/메타데이터에 묶인 명시적 필드(예: cryptoVersion)를 사용할 것을 권장합니다.

명시적 버전: 모든 전송/매니페스트는 알고리즘, 매개변수, 인코딩 규칙을 결정할 수 있도록 cryptoVersion을 반드시 선언해야 합니다.
암묵적 추론 금지: 클라이언트는 추측이나 대체 휴리스틱이 아니라 매니페스트의 명시적 필드를 근거로 파싱 및 복호화 로직을 결정해야 합니다.
안전하게 실패(Fail Closed): 알 수 없는 버전이나 일치하지 않는 매개변수를 만나면 반드시 안전하게 실패해야 하며, 안전하지 않은 모드로 절대 다운그레이드해서는 안 됩니다.

11.7 호환성, 마이그레이션 및 지원 중단

11.7.1 하위 호환성

SHOULD: 사용자의 기존 링크에 미치는 영향을 최소화하도록 전환 기간 동안 이전 전송 버전의 읽기를 지원합니다.
MUST: 이전 버전의 보안 경계, 한계, 지원 중단 계획을 공개적으로 밝힙니다.

11.7.2 마이그레이션(영지식 유지)

SHOULD: 이전 버전에서 새 버전으로 옮겨야 할 때 사용자가 직접 "다시 업로드/다시 암호화"할 수 있는 경로를 제공합니다.
MUST: 마이그레이션 중에도 영지식을 유지합니다. 재암호화는 클라이언트에서 이루어지며, 서버는 CEK나 평문에 접근할 수 없습니다.

11.7.3 지원 중단 및 EOL

MUST: 더 이상 안전하지 않다고 판단되는 버전에는 명확한 수명 종료(EOL) 일정을 제공합니다.
SHOULD: UI/문서에서 사용자에게 다시 업로드하도록 안내하고, 충분한 마이그레이션 기간을 제공합니다.
MUST: EOL 이후 지원 중단된 버전을 만난 클라이언트는 이를 명확히 안내해야 하며, 복호화를 시도해서는 안 됩니다.

11.8 관련 클레임 ID(예약)

이 장은 "취약점 공개 채널, 처리 절차, 버전 관리 및 지원 중단"을 다룹니다. 해당하는 클레임 ID는 부록: 클레임 ID 마스터 목록 에 추가되며, 이 목록이 유일한 기준 출처입니다.