นโยบายการเปิดเผยช่องโหว่

โดยสรุป

หน้านี้ระบุนโยบายการเปิดเผยช่องโหว่แบบประสานงานของ NextPDF โดยอธิบายวิธีติดต่อผู้ดูแลโครงการแบบส่วนตัว กรอบเวลาการตอบสนองที่คาดหวังได้ และวิธีทำงานของการระงับการเปิดเผย

ขอบเขต นโยบายการเปิดเผยเป็นข้อผูกพันเชิงกระบวนการ ไม่ใช่กรอบเวลา หรือการรับประกันผลลัพธ์ เป้าหมายด้านล่างเป็นข้อผูกพันโดยสุจริตใจของผู้ดูแลโครงการ ที่มีต่อคุณในฐานะผู้รายงาน โดยอธิบายกระบวนการที่โครงการ ปฏิบัติตาม ไม่ใช่คำมั่นตามสัญญาว่ารายงานใดรายงานหนึ่งจะได้รับการตอบรับ คัดแยก แก้ไข หรือเปิดเผยภายในวันที่ใดวันที่หนึ่งโดยเฉพาะ กำหนดเวลาการเปิดเผยแบบประสานงาน เป็นสิ่งที่ตกลงร่วมกัน ไม่ใช่การรับประกันฝ่ายเดียว

การติดตั้ง

ไม่เกี่ยวข้อง คุณไม่จำเป็นต้องติดตั้งสิ่งใดเพื่อรายงานช่องโหว่ ช่องทางการติดต่อที่เครื่องอ่านได้เผยแพร่อยู่ที่ /.well-known/security.txt (Request for Comments (RFC) 9116) ไฟล์ SECURITY.md ในที่เก็บโค้ดเป็นนโยบายฉบับทางการที่มนุษย์อ่านได้

ภาพรวมเชิงแนวคิด

นโยบายนี้นำแนวทางการเปิดเผยช่องโหว่แบบประสานงานตามที่กำหนดไว้ใน ISO/IEC 29147 และกระบวนการจัดการใน ISO/IEC 30111 (iso_iec_30111#x9.x43.p2) มาใช้ ได้แก่ การรับเรื่องแบบส่วนตัว การคัดแยกและการประเมินความรุนแรง การแก้ไขภายใต้การระงับการเปิดเผย และการเผยแพร่สู่สาธารณะร่วมกัน หากช่องโหว่ส่งผลกระทบต่อผู้ขายหลายราย ฝ่ายที่ได้รับผลกระทบจะร่วมกันประสานกำหนดเวลาของคำแนะนำด้านความปลอดภัย แทนที่จะกำหนดฝ่ายเดียว (iso_iec_29147#x3.x110.p13)

กระบวนการนี้ยังสอดคล้องกับภาระหน้าที่ด้านการจัดการช่องโหว่ของผู้ผลิตใน European Union (EU) Cyber Resilience Act (CRA) (eu_cra#x1.p191) และแนวปฏิบัติ “respond to vulnerabilities” ใน National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) (nist_sp_800_218#x15) ทั้งสองแหล่งอธิบายเรื่องเหล่านี้ว่าเป็นหน้าที่เชิงกระบวนการที่ทำซ้ำได้ ไม่ใช่การรับประกันว่าผลลัพธ์ในกรณีใดกรณีหนึ่งจะเกิดขึ้นแน่นอน

พื้นผิว API

ไม่เกี่ยวข้อง การเปิดเผยเป็นกระบวนการ ไม่ใช่ application programming interface (API) พื้นผิวการค้นพบที่เครื่องอ่านได้คือไฟล์ RFC 9116 security.txt เครื่องมือจะอ่านฟิลด์ Contact: และ Expires: หน้านี้ไม่ได้นำเนื้อหาของไฟล์นั้นมาทำซ้ำ นอกเหนือจากช่องทางด้านล่าง

ตัวอย่างโค้ด — เริ่มต้นอย่างรวดเร็ว

ไม่เกี่ยวข้อง ไม่มีโค้ดที่ต้องรันเมื่อคุณรายงานช่องโหว่ โปรดใช้ช่องทางส่วนตัว:

GitHub Security Advisories (แนะนำ — เข้ารหัสลับขณะจัดเก็บและมีบันทึกการตรวจสอบ): เปิดร่างคำแนะนำด้านความปลอดภัยในแท็บ GitHub Security ของโครงการ
อีเมล: [email protected] โดยใส่ [SECURITY] ในหัวเรื่อง หากคุณต้องการการเข้ารหัสลับแบบ end-to-end และยังไม่มีคีย์ OpenPGP ที่เผยแพร่ไว้ใน security.txt ให้ใช้ช่องทาง GitHub Security Advisory แทน

โปรด อย่า รายงานผ่าน issue สาธารณะ รายชื่อผู้รับจดหมายสาธารณะ โซเชียลมีเดีย หรือแชต การเปิดเผยสู่สาธารณะก่อนมีการแก้ไขจะทำให้ผู้ใช้ที่ยังอยู่บนเวอร์ชันที่ไม่ได้แพตช์ตกอยู่ในความเสี่ยง

ตัวอย่างโค้ด — การใช้งานจริง

ไม่เกี่ยวข้อง

กรณีขอบและข้อควรระวัง

เป้าหมายเป็นข้อผูกพัน ไม่ใช่ข้อตกลงระดับการให้บริการ (service-level agreements: SLAs) กรอบเวลาด้านล่างระบุสิ่งที่โครงการมุ่งดำเนินการ ปัญหาที่ซับซ้อนซึ่งมีหลายองค์ประกอบ หรือปัญหาที่ต้องประสานงานกับต้นทาง อาจใช้เวลานานกว่า โดยโครงการจะแจ้งข้อมูลให้ผู้รายงานทราบอย่างต่อเนื่อง
ระยะเวลาของการระงับการเปิดเผยตกลงกันได้ โดยมีเพดานกำหนดไว้ การระงับการเปิดเผยตามค่าเริ่มต้นจะนับตั้งแต่การคัดแยกไปจนถึงการออกการแก้ไข หากคุณต้องการระยะเวลานานกว่านี้ ให้ร้องขออย่างชัดเจนเมื่อคุณเปิดคำแนะนำด้านความปลอดภัย หลังจากครบระยะเวลาสูงสุด โครงการจะเผยแพร่คำแนะนำด้านความปลอดภัยไม่ว่าจะมีการแก้ไขพร้อมแล้วหรือไม่ ซึ่งสอดคล้องกับบรรทัดฐานการเปิดเผยแบบประสานงานของอุตสาหกรรม แนวทางนี้ช่วยปกป้องผู้ใช้จากการระงับคำแนะนำด้านความปลอดภัยไว้อย่างไม่มีกำหนด
ความรุนแรงเป็นตัวกำหนดตารางเวลา ปัญหาที่ร้ายแรงและกำลังถูกใช้โจมตีจริงจะได้รับการจัดการตามกรอบเวลาที่กระชับ ส่วนข้อเสนอแนะเพื่อเสริมความแข็งแกร่งที่มีความรุนแรงต่ำจะไม่เป็นเช่นนั้น ความรุนแรงจะได้รับการประเมินระหว่างการคัดแยกและสามารถปรับแก้ได้
การออก Common Vulnerabilities and Exposures (CVE) เป็นส่วนหนึ่งของการคัดแยก ผู้ดูแลโครงการจะร้องขอ CVE ผ่านการลงทะเบียน CVE Numbering Authority (CNA) ของ GitHub Security Advisory ของโครงการในฐานะส่วนหนึ่งของขั้นตอนการคัดแยก ผู้รายงานไม่จำเป็นต้องร้องขอแยกต่างหาก

ประสิทธิภาพ

ไม่เกี่ยวข้อง

หมายเหตุด้านความปลอดภัย

เป้าหมายของกรอบเวลาการตอบสนองเป็นข้อผูกพันต่อผู้รายงานและเป็นเกณฑ์พื้นฐานในการจัดการช่องโหว่ของโครงการ รายการเหล่านี้เป็นเป้าหมาย ไม่ใช่การรับประกัน:

ขั้นตอน	เป้าหมาย
ตอบรับว่าได้รับเรื่องแล้ว	ภายใน 1–2 วันทำการ
การคัดแยกเบื้องต้น + การประเมินความรุนแรง	ภายในประมาณ 5 วันทำการ / 7 วันตามปฏิทิน
การพัฒนาแพตช์ + การตรวจทานแบบส่วนตัว	โดยทั่วไป 14 วันทำการ; 30–90 วันสำหรับ CVE ที่ซับซ้อนและได้รับการยืนยันแล้ว ขึ้นอยู่กับความรุนแรง
การกำหนด 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)