취약점 공개 정책
한눈에 보기
섹션 제목: “한눈에 보기”이 페이지는 NextPDF의 조율된 취약점 공개 정책입니다. 신고자가 관리자에게 비공개로 연락하는 방법, 기대할 수 있는 대응 일정, 엠바고가 작동하는 방식을 안내합니다.
범위. 공개 정책은 프로세스에 대한 약속이며, 일정이나 결과를 보장하지 않습니다. 아래 목표는 관리자가 신고자에게 제시하는 선의의 약속입니다. 이는 프로젝트가 따르는 프로세스를 설명할 뿐, 특정 신고가 접수 확인을 받거나, 특정 날짜까지 분류, 수정 또는 공개된다는 계약상의 약속은 아닙니다. 조율된 공개 시점은 협의로 정해지며, 일방적으로 보장되지 않습니다.
해당 없음. 취약점을 신고하는 데는 아무것도 설치할 필요가 없습니다. 기계 판독 가능한 연락처 표면은 /.well-known/security.txt(RFC 9116)에 게시되어 있습니다. 사람이 읽을 수 있는 공식 정책은 저장소의 SECURITY.md입니다.
개념 개요
섹션 제목: “개념 개요”이 정책은 ISO/IEC 29147에 정의된 조율된 취약점 공개와 ISO/IEC 30111의 처리 프로세스(iso_iec_30111#x9.x43.p2)를 구현합니다. 즉, 비공개 접수, 분류 및 심각도 평가, 엠바고 상태에서의 수정 단계, 공동 공개 릴리스로 이루어집니다. 취약점이 여러 공급업체에 영향을 미치는 경우, 권고 시점은 일방적으로 정하는 것이 아니라 영향을 받는 당사자 간에 조율됩니다(iso_iec_29147#x3.x110.p13).
이 프로세스는 또한 EU 사이버 복원력법(EU Cyber Resilience Act)의 제조사 취약점 처리 의무(eu_cra#x1.p191) 및 NIST 안전한 소프트웨어 개발 프레임워크(NIST Secure Software Development Framework)의 “취약점 대응” 관행(nist_sp_800_218#x15)에도 부합합니다. 두 기준 모두 이를 반복 가능한 프로세스상의 의무로 규정하며, 개별 결과를 보장하는 보증으로 규정하지 않습니다.
API 표면
섹션 제목: “API 표면”해당 없음. 공개는 프로세스이며, API가 아닙니다. 기계 판독 가능한 검색 표면은 RFC 9116 security.txt 파일입니다. 도구는 이 파일의 Contact: 및 Expires: 필드를 구문 분석합니다. 이 페이지는 아래 채널 외에는 해당 파일의 내용을 중복해 다루지 않습니다.
코드 샘플 — 빠른 시작
섹션 제목: “코드 샘플 — 빠른 시작”해당 없음. 취약점을 신고하기 위해 실행할 코드는 없습니다. 비공개 채널을 사용하세요:
- GitHub Security Advisories(권장 — 저장 시 암호화, 감사 로그): 프로젝트의 GitHub Security 탭에서 초안 권고를 작성하세요.
- 이메일:
[email protected]로 보내되, 제목에[SECURITY]를 포함하세요. 종단 간 암호화가 필요하지만 게시된 OpenPGP 키가 아직security.txt에 등재되어 있지 않다면 GitHub Security Advisory 채널을 대신 사용하세요.
공개 이슈, 공개 메일링 리스트, 소셜 미디어 또는 채팅을 통해서는 신고하지 마세요. 수정 전에 공개하면 패치되지 않은 버전을 사용하는 사용자가 위험에 노출됩니다.
코드 샘플 — 프로덕션
섹션 제목: “코드 샘플 — 프로덕션”해당 없음.
엣지 케이스 및 주의 사항
섹션 제목: “엣지 케이스 및 주의 사항”- 목표는 약속이며, SLA가 아닙니다. 아래 일정은 프로젝트가 지향하는 바를 명시합니다. 여러 구성 요소가 얽힌 복잡한 문제나 업스트림 조율이 필요한 문제는 더 오래 걸릴 수 있으며, 신고자에게는 진행 상황을 계속 공유합니다.
- 엠바고 기간은 협의 가능하되, 상한이 있습니다. 기본 엠바고는 분류부터 수정 릴리스까지 적용됩니다. 더 긴 기간이 필요한 신고자는 권고를 작성할 때 이를 명시적으로 요청해야 합니다. 최대 기간이 지나면, 프로젝트는 업계의 조율된 공개 관행에 따라 수정 제공 여부와 관계없이 권고를 게시합니다. 이는 권고가 무기한 보류되는 상황에서 사용자를 보호합니다.
- 심각도가 일정을 좌우합니다. 적극적으로 악용되고 있는 심각한 문제는 단축된 일정으로 처리되며, 심각도가 낮은 강화 제안에는 같은 일정이 적용되지 않습니다. 심각도는 분류 단계에서 평가되며, 수정될 수 있습니다.
- CVE 발급은 분류 과정의 일부입니다. 관리자는 분류 단계의 일부로 프로젝트의 GitHub Security Advisory CNA 등록을 통해 CVE를 요청하므로, 신고자가 별도로 요청할 필요는 없습니다.
해당 없음.
보안 참고 사항
섹션 제목: “보안 참고 사항”대응 시간 목표는 신고자에게 제시하는 약속이며, 프로젝트의 취약점 처리 기준선을 형성합니다. 이는 목표이며, 보장이 아닙니다:
| 단계 | 목표 |
|---|---|
| 접수 확인 | 영업일 기준 1–2일 이내 |
| 초기 분류 + 심각도 평가 | 영업일 기준 약 5일 / 달력 기준 7일 이내 |
| 패치 개발 + 비공개 검토 | 일반적으로 영업일 기준 14일; 복잡성이 확인된 CVE의 경우 심각도에 따라 30–90일 |
| CVE 할당(승인된 경우) | 패치와 동시에 GitHub CNA 채널을 통해 |
| 조율된 공개 | 패치 릴리스 시점에 신고자와 공동으로 정한 날짜에 |
| 엠바고(분류부터 릴리스까지) | 기본 약 90일이며, 적극적인 악용이 진행 중인 경우 단축되고, 명시적 요청 시 정해진 최대치까지 연장 가능 |
검토자가 확인할 수 있는 프로세스 규칙:
- 비공개 우선. 어떤 공개 채널도 인정되는 접수 경로가 아닙니다. 인정되는 채널은 GitHub Security Advisory와 보안 이메일뿐입니다.
- 조율되며, 일방적이지 않습니다. 공개 시점은 신고자 및 함께 영향을 받는 모든 공급업체와 협의해 정합니다(
iso_iec_29147#x3.x110.p13). - 한정된 엠바고. 엠바고에는 기본값과 절대 상한이 있으며, 권고가 무기한 보류되지 않습니다.
- 요청 시 크레딧 부여. 연구자는 익명을 요청하지 않은 경우 엠바고가 해제되면 크레딧을 받습니다.
이러한 진술은 프로젝트가 따르기로 약속한 프로세스를 설명합니다. 이는 특정 신고가 수정, CVE 또는 특정 날짜까지의 공개로 이어진다는 보장이 아닙니다.
적합성
섹션 제목: “적합성”이 문서는 적합성 프로필이 아닙니다. 이 정책은 ISO/IEC 29147 및 ISO/IEC 30111, 그리고 위에서 인용한 CRA/SSDF 프로세스 의무에 부합합니다. “부합”이라는 표현은 의도적인 것으로, 프로젝트는 이러한 어떤 체계에 대해서도 인증을 주장하지 않습니다. 이러한 기준은 건전한 프로세스가 어떤 모습인지 정의하며, 이 페이지는 그러한 프로세스를 운영하겠다는 프로젝트의 약속을 문서화합니다.
함께 보기
섹션 제목: “함께 보기”- 신뢰 센터
- 엔진 위협 모델
- 서명 및 암호화 보안 모델
- 저장소
SECURITY.md및/.well-known/security.txt(RFC 9116)