Chính sách công bố lỗ hổng bảo mật

Tổng quan nhanh

Trang này quy định chính sách công bố lỗ hổng bảo mật theo quy trình phối hợp của NextPDF. Trang hướng dẫn bạn cách liên hệ riêng tư với người bảo trì, mốc thời gian phản hồi có thể kỳ vọng, và cách thức hoạt động của lệnh cấm công bố.

Giới hạn. Chính sách công bố là một cam kết về quy trình, không phải là bảo đảm về mốc thời gian hay kết quả. Các mục tiêu dưới đây là cam kết thiện chí của người bảo trì dành cho bạn với tư cách là người báo cáo; chúng mô tả quy trình mà dự án tuân theo, không phải là lời hứa mang tính hợp đồng rằng bất kỳ báo cáo cụ thể nào cũng sẽ được xác nhận, phân loại, khắc phục hay công bố vào bất kỳ ngày cụ thể nào. Thời điểm công bố theo quy trình phối hợp được thương lượng, không phải được bảo đảm đơn phương.

Cài đặt

Không áp dụng. Bạn không cần cài đặt bất cứ thứ gì để báo cáo một lỗ hổng. Điểm liên hệ ở dạng máy đọc được được công bố tại /.well-known/security.txt (Request for Comments (RFC) 9116). Tệp SECURITY.md trong kho lưu trữ là chính sách có thẩm quyền dành cho người đọc.

Tổng quan khái niệm

Chính sách này triển khai việc công bố lỗ hổng theo quy trình phối hợp như được định nghĩa trong ISO/IEC 29147 và quy trình xử lý trong ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): tiếp nhận riêng tư, phân loại và đánh giá mức độ nghiêm trọng, khắc phục trong thời gian cấm công bố, và phát hành công khai chung. Nếu một lỗ hổng ảnh hưởng đến nhiều nhà cung cấp, các bên bị ảnh hưởng sẽ phối hợp thời điểm thông báo thay vì tự ấn định đơn phương (iso_iec_29147#x3.x110.p13).

Quy trình này cũng phù hợp với các nghĩa vụ xử lý lỗ hổng của nhà sản xuất trong Đạo luật Khả năng phục hồi mạng (CRA) của Liên minh châu Âu (EU) (eu_cra#x1.p191) và thực hành “ứng phó với lỗ hổng” trong Khung Phát triển phần mềm an toàn (SSDF) của Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) (nist_sp_800_218#x15). Cả hai đều mô tả những điều này là các nghĩa vụ quy trình có thể lặp lại, chứ không phải sự bảo đảm cho bất kỳ kết quả riêng lẻ nào.

Bề mặt API

Không áp dụng. Công bố là một quy trình, không phải là một giao diện lập trình ứng dụng (API). Bề mặt khám phá ở dạng máy đọc được là tệp theo chuẩn RFC 9116, tức security.txt; công cụ sẽ đọc các trường Contact: và Expires: của tệp. Ngoài các kênh được nêu bên dưới, trang này không lặp lại nội dung của tệp đó.

Mẫu mã — Bắt đầu nhanh

Không áp dụng. Không có mã nào cần chạy khi bạn báo cáo một lỗ hổng. Hãy dùng kênh riêng tư:

GitHub Security Advisories (ưu tiên — mã hóa khi lưu trữ, có nhật ký kiểm toán): mở một thông báo nháp trong tab GitHub Security của dự án.
Email: [email protected] với [SECURITY] trong tiêu đề. Nếu bạn cần mã hóa đầu cuối và chưa có khóa OpenPGP công bố nào được liệt kê trong security.txt, hãy dùng kênh GitHub Security Advisory để thay thế.

Tuyệt đối không báo cáo qua các issue công khai, danh sách gửi thư công khai, mạng xã hội hay chat. Công bố công khai trước khi có bản vá sẽ khiến người dùng đang chạy phiên bản chưa được vá gặp rủi ro.

Mẫu mã — Môi trường production

Không áp dụng.

Trường hợp biên & điểm cần lưu ý

Mục tiêu là cam kết, không phải là thỏa thuận mức dịch vụ (SLA). Các mốc thời gian dưới đây nêu rõ những gì dự án hướng tới. Một vấn đề phức tạp gồm nhiều thành phần, hoặc một vấn đề cần phối hợp với bên thượng nguồn, có thể mất nhiều thời gian hơn; dự án sẽ luôn thông báo cho người báo cáo.
Thời gian cấm công bố có thể thương lượng, nhưng có giới hạn trên. Thời gian cấm công bố mặc định kéo dài từ khi phân loại đến khi phát hành bản vá. Nếu bạn cần thời gian dài hơn, hãy nêu rõ yêu cầu đó khi mở thông báo. Khi đạt đến mức tối đa, dự án sẽ công bố thông báo bất kể đã có bản vá hay chưa, phù hợp với các chuẩn mực công bố theo quy trình phối hợp của ngành. Điều này bảo vệ người dùng khỏi việc một thông báo bị giữ lại vô thời hạn.
Mức độ nghiêm trọng quyết định lịch trình. Một vấn đề nghiêm trọng đang bị khai thác tích cực sẽ được xử lý theo mốc thời gian rút gọn; một đề xuất tăng cường bảo mật mức độ thấp thì không. Mức độ nghiêm trọng được đánh giá trong quá trình phân loại và có thể được điều chỉnh.
Việc cấp mã Lỗ hổng và Phơi nhiễm phổ biến (CVE) là một phần của quá trình phân loại. Người bảo trì yêu cầu cấp một CVE qua Cơ quan cấp số CVE (CNA) của GitHub Security Advisory của dự án như một phần của bước phân loại; người báo cáo không cần yêu cầu cấp riêng.

Hiệu năng

Không áp dụng.

Ghi chú bảo mật

Các mục tiêu về mốc thời gian phản hồi là cam kết với người báo cáo và tạo thành mức cơ sở xử lý lỗ hổng của dự án. Đây là các mục tiêu, không phải là sự bảo đảm:

Giai đoạn	Mục tiêu
Xác nhận đã nhận	trong vòng 1–2 ngày làm việc
Phân loại ban đầu + đánh giá mức độ nghiêm trọng	trong vòng ~5 ngày làm việc / 7 ngày theo lịch
Phát triển bản vá + đánh giá riêng tư	thường là 14 ngày làm việc; 30–90 ngày đối với các CVE phức tạp đã xác nhận, tùy theo mức độ nghiêm trọng
Gán CVE (nếu được chấp nhận)	đồng thời với bản vá, qua kênh CNA của GitHub
Công bố công khai theo quy trình phối hợp	khi phát hành bản vá, vào một ngày được ấn định chung với người báo cáo
Lệnh cấm công bố (từ khi phân loại đến khi phát hành)	mặc định ~90 ngày, rút ngắn khi đang bị khai thác tích cực, có thể gia hạn theo yêu cầu rõ ràng cho đến một mức tối đa cố định

Người đánh giá có thể kiểm tra các quy tắc quy trình này:

Ưu tiên riêng tư. Không kênh công khai nào được chấp nhận để tiếp nhận. Chỉ GitHub Security Advisory và email bảo mật là các kênh được chấp nhận.
Phối hợp, không đơn phương. Thời điểm công bố được thương lượng với người báo cáo và bất kỳ nhà cung cấp nào cùng bị ảnh hưởng (iso_iec_29147#x3.x110.p13).
Lệnh cấm công bố có giới hạn. Lệnh cấm công bố có một giá trị mặc định và một giới hạn trên cứng; dự án không giữ lại một thông báo vô thời hạn.
Ghi nhận công lao theo yêu cầu. Các nhà nghiên cứu được ghi nhận công lao sau khi lệnh cấm công bố được gỡ bỏ, trừ khi họ yêu cầu ẩn danh.

Các tuyên bố này mô tả quy trình mà dự án cam kết tuân theo. Chúng không bảo đảm rằng một báo cáo nhất định sẽ dẫn đến một bản vá, một CVE, hay một lần công bố vào ngày cụ thể.

Tuân thủ

Không phải là một hồ sơ tuân thủ. Chính sách này phù hợp với ISO/IEC 29147, ISO/IEC 30111, cùng các nghĩa vụ quy trình của CRA và SSDF được trích dẫn ở trên; cụm từ “phù hợp với” được dùng một cách có chủ đích. Dự án không khẳng định đã được chứng nhận theo bất kỳ chương trình nào trong số này. Các chuẩn và nghĩa vụ đó định nghĩa một quy trình hợp lý; trang này ghi lại cam kết của dự án về việc vận hành một quy trình như vậy.

Xem thêm

Trung tâm tin cậy
Mô hình mối đe dọa của engine
Mô hình bảo mật chữ ký và mã hóa
Tệp SECURITY.md trong kho lưu trữ và /.well-known/security.txt (RFC 9116)