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: 제출서류에 대한 간략한 안내 및 제출 지침을 제공합니다. 보안 및 개인정보 보호 page.

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

SHOULD: 연구자가 복제 세부정보를 안전하게 제출할 수 있도록 PGP 공개 키(또는 이에 상응하는 키)를 제공합니다.
MUST: 내부적으로 취약점 세부 정보에 대한 최소 권한 가시성을 적용하고 수정에 필요한 담당자에게만 공개합니다.
MUST: 연구원이 보고서에 사용자 일반 텍스트, CEK, URL 조각 또는 파생 가능한 키 자료를 포함하는 것을 금지합니다. 실수로 포함된 경우 팀은 이를 민감한 사건으로 처리하고 전파를 제한해야 합니다.

11.2 응답 일정 및 의사소통 원칙

타임라인은 팀 규모와 복잡성에 따라 다르지만 프로젝트는 예측 가능한 목표 속도를 제공하고 목표를 놓친 경우 즉시 전달해야 합니다. 권장 대상(현실에 따라 조정 가능하며 /security 또는 security.txt에 게시됨):

첫 번째 응답: 예: 48시간 이내에 영수증을 확인하고 추적 ID를 할당합니다.
초기 평가: 예: 7일 이내에 심각도 등급 및 영향 범위 평가를 완료합니다.
수정 릴리스: 심각도에 따른 진행 상황; 신속한 수정 및 릴리스를 위해 우선순위가 높은 P0/P1입니다.

SHOULD: 처리 중에 필요한 의사소통을 유지하고(예: 재생산/재생되지 않음, 추가 정보 필요, 예상 수정 기간) 악용 가능한 세부 정보를 공개적으로 공개하지 마십시오.

11.3 공개 프로세스

Receipt: 보고서 정보, 재현 단계, 영향, 연구자 연락처를 기록합니다. 소유자 및 추적을 할당합니다.
Verification: 격리된 환경에서 재현; 영향 범위, 악용 가능성 및 영향을 받는 구성 요소(프런트엔드/백엔드/에지/스토리지)를 평가합니다.
Remediation: 패치 구현, 테스트/회귀 사례 추가, 필요한 경우 보호 규칙 추가(WAF/속도 제한/정책 강화).
Release: Canary 릴리스 및 주요 지표 모니터링 회귀 또는 새로운 위험이 없음을 확인한 후 전체 릴리스.
Announcement: 공격 표면을 확대하지 않고도 영향, 수정 콘텐츠, 필요한 사용자 조치(있는 경우)를 공개적으로 설명합니다.

심각한 취약점 또는 사용자에게 큰 영향을 미치는 이벤트의 경우 SHOULD 다음을 통해 이벤트 업데이트 또는 사후 분석 게시 /status Chapter 10 IR 프로세스와 일치합니다.

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

영지식 약속의 핵심은 다음과 같습니다. 서버는 CEK에 액세스할 수 없으며, 다운로드/암호 해독 환경은 타사 스크립트 없이 최대한 격리됩니다. 따라서 다음 범주는 가장 높은 우선순위로 처리되어야 합니다.

XSS / 주입: 다운로드/암호 해독 페이지에서 임의 스크립트를 실행하고 조각이나 메모리 키 자료를 읽는 기능입니다.
공급망 주입: 종속성 중독, 빌드 아티팩트 교체, 스크립트 변조로 이어지는 CDN/Edge 주입.
로그/모니터링 유출: URL 조각, CEK, 토큰 또는 일반 텍스트가 실수로 기록되어 액세스할 수 있습니다.
잘못된 리소스 로딩 정책: 타사 스크립트를 가져오는 다운로드/암호 해독 페이지, CSP 완화 확장 실행 표면.

폐기에는 다음이 포함되어야 합니다. 즉시 봉쇄(오프라인 위험한 코드/정책 강화/금지 벡터), 신속한 수정 릴리스, 회고적 영향 분석, 그리고 "핵심 자료 또는 일반 텍스트가 잠재적으로 노출되었는지 여부"에 대한 발표의 명확한 진술.

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

MUST: 보안 관련 변경 사항(인증, 접근 제어, CSP, 로그 필터링, 암호화 흐름)에 대한 회귀 사례를 설정합니다.
SHOULD: 중요한 페이지(다운로드/암호 해독)에서 자동화된 검사를 수행하여 타사 스크립트 및 헤더 정책이 예상과 일치하지 않는지 확인합니다.
SHOULD: 수정 사항 릴리스 후 외부 검증 가능 항목 재테스트(예: TLS/보안 헤더 스캔)를 수행합니다.
SHOULD: 문서의 수정 사항(예: 이전 링크/이전 매니페스트)으로 인해 도입된 호환성 변경 사항을 명확하게 문서화합니다.

12장과 일치: 타사 스캔은 일부 웹 기준을 확인하지만 전체 영지식/E2EE 구현 세부 사항을 직접 증명할 수는 없습니다. 따라서 회귀 검증은 프로토콜 구현과 가시적인 기준선을 모두 다루어야 합니다.

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

FileBolt의 암호화 및 프로토콜 구현은 알고리즘 업그레이드를 촉진하고 구현 결함을 수정하며 더 강력한 격리를 도입하기 위해 버전 관리를 지원해야 합니다. 명시적인 필드를 사용하는 것이 좋습니다(예: cryptoVersion) 매니페스트/메타데이터에 바인딩됩니다.

명시적 버전: 모든 전송/명시에는 반드시 이를 선언해야 합니다. cryptoVersion 알고리즘, 매개변수, 인코딩 규칙을 결정합니다.
암시적 추론 없음: 클라이언트는 추측이나 대체 휴리스틱이 아닌 명시적 매니페스트 필드를 기반으로 구문 분석 및 암호 해독 논리를 결정해야 합니다.
실패 마감: 알 수 없는 버전이나 일관되지 않은 매개변수가 발생하면 실패 시 닫혀야 하며, 절대 안전하지 않은 모드로 다운그레이드해서는 안 됩니다.

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

11.7.1 이전 버전과의 호환성

SHOULD: 사용자 기록 링크에 대한 영향을 최소화하기 위해 전환 기간 동안 이전 전송 버전 읽기를 지원합니다.
MUST: 이전 버전에 대한 보안 경계, 제한 사항 및 지원 중단 계획을 공개적으로 명시합니다.

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

SHOULD: 이전 버전에서 새 버전으로 마이그레이션해야 하는 경우 "다시 업로드/재암호화" 사용자 측 경로를 제공합니다.
MUST: 마이그레이션 중 영지식 유지: 클라이언트에서 다시 암호화가 발생하고 서버는 CEK 또는 일반 텍스트에 액세스할 수 없습니다.

11.7.3 지원 중단 및 EOL

MUST: 더 이상 안전하지 않은 것으로 간주되는 버전에 대한 명확한 수명 종료 일정을 제공합니다.
SHOULD: 사용자에게 UI/문서에서 다시 업로드하라는 메시지를 표시하고 충분한 마이그레이션 기간을 제공합니다.
MUST: EOL 이후 더 이상 사용되지 않는 버전을 접하는 클라이언트는 명확하게 메시지를 표시해야 하며 암호 해독을 시도해서는 안 됩니다.

11.8 관련 청구 ID(예약됨)

이 장에서는 "취약성 공개 채널, 작업 흐름, 버전 관리 및 지원 중단"을 다룹니다. 해당 청구 ID가 부록: 청구 ID 마스터 목록 유일한 권위 있는 출처로 사용됩니다.