Coordinated vulnerability disclosure

การเปิดเผยช่องโหว่แบบประสานงาน (CVD)

วิธีรายงาน รับ และประสานงานช่องโหว่ด้านความปลอดภัย พร้อมตัวอย่างนโยบาย

การเปิดเผยช่องโหว่แบบประสานงาน (Coordinated vulnerability disclosure, CVD) เป็นคำศัพท์ด้านความมั่นคงปลอดภัยคอมพิวเตอร์ ซึ่งอธิบายว่าผู้คนสามารถแบ่งปันรายงานเกี่ยวกับปัญหาความปลอดภัยได้อย่างไร ตัวอย่างเช่น รายงานข้อบกพร่อง ความเสี่ยงจากการบุกรุก คำเตือนการแฮ็ก ข้อมูลรั่วไหล การเจาะระบบเว็บไซต์ เป็นต้น

คำแปล: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

สารบัญ:

นโยบาย:

บทนำ

เอกสารนี้อธิบายการเปิดเผยช่องโหว่แบบประสานงานในแนวทางที่อาจช่วยให้ผู้คนทำงานร่วมกันได้

เป้าหมายของเอกสาร:

  1. ช่วยผู้ที่ค้นพบปัญหาความปลอดภัยและต้องการรายงาน

  2. ช่วยให้ตัวแทนของบริษัทเข้าใจความต้องการ เป้าหมาย แนวปฏิบัติ และกรณีพิเศษของการเปิดเผยอย่างรับผิดชอบ

  3. รวมตัวอย่างนโยบายการเปิดเผยช่องโหว่แบบประสานงานไว้ในโฟลเดอร์ของที่เก็บโค้ด (repository)

เรายินดีรับ pull request หรือ GitHub issue หรืออีเมลถึง security@joelparkerhenderson.com

การเปิดเผยช่องโหว่แบบประสานงานคืออะไร

การเปิดเผยช่องโหว่แบบประสานงานอธิบายสามขั้นตอนเมื่อมีผู้ค้นพบปัญหาความปลอดภัย (เช่น บั๊กของซอฟต์แวร์) และต้องการรายงานให้ผู้ผลิต (เช่น บริษัทที่สร้างซอฟต์แวร์นั้น)

ขั้นตอน:

  1. ผู้ค้นพบรายงานปัญหาเป็นการส่วนตัวด้วยความสุจริตใจให้ผู้ผลิต

  2. ผู้ผลิตพยายามปกป้องผู้ใช้ด้วยความสุจริตใจและพยายามแก้ไขปัญหา

  3. หลังจากผ่านไประยะเวลาที่กำหนด ปัญหาความปลอดภัยจะถูกเปิดเผยต่อสาธารณะ

ขั้นตอนที่ 1: รายงานปัญหา

ขั้นตอนที่ 1 เป็นหน้าที่ของผู้ค้นพบ: รายงานปัญหาเป็นการส่วนตัวด้วยความสุจริตใจ

  • ดี: ผู้ค้นพบส่งข้อมูลที่เกี่ยวข้องให้ผู้ผลิต เช่น ทางอีเมลไปยังที่อยู่อีเมลด้านความปลอดภัยของผู้ผลิต (โดยทั่วไปคือ "security@example.com") หรือผ่านแบบฟอร์มบนหน้าเว็บในเว็บไซต์ของผู้ผลิต (โดยทั่วไปคือ "https://www.example.com/security")

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

  • เคล็ดลับ: ผู้ค้นพบอาจเลือกที่จะไม่เปิดเผยตัวตน ผู้ผลิตก็อาจเลือกที่จะไม่เปิดเผยตัวตนได้เช่นกัน

หากต้องการ ให้ติดตามปัญหานั้นต่อไป

  • ดี: เปิดช่องทางการสื่อสาร หรือให้ข้อมูลติดตามผล หรือเฝ้าติดตามสถานการณ์

  • ไม่ดี: ลืมเรื่องปัญหานั้นไป

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

หากต้องการ ให้เปิดเผยปัญหานั้นแก่ผู้อื่น

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

  • ไม่ดี: ไม่เปิดเผยปัญหาแก่ผู้อื่น เว้นแต่คุณรู้สึกว่าการเปิดเผยจะก่อให้เกิดความเสี่ยงมากกว่าที่เทียบเคียงได้ต่อตัวคุณเองหรือผู้อื่น

  • เคล็ดลับ: หากสถานการณ์เปลี่ยนไป เช่น พบความเสี่ยงที่สูงขึ้นหรือมีการโจมตีใช้ประโยชน์จริง (in the wild) ผู้ค้นพบอาจเปิดเผยปัญหาแก่ผู้อื่นเร็วขึ้นได้

ขั้นตอนที่ 2: ตรวจสอบช่องทางติดต่อ

ขั้นตอนที่ 2 เป็นหน้าที่ของผู้ผลิต: ตรวจสอบให้แน่ใจว่าช่องทางติดต่อใช้งานได้

  • ดี: ผู้ผลิตเผยแพร่ที่อยู่อีเมลติดต่อด้านความปลอดภัย (ตามธรรมเนียมคือ "security@example.com") และหากเป็นไปได้ควรมีกุญแจเข้ารหัสอีเมลที่ปลอดภัย

  • ดี: ผู้ผลิตเผยแพร่หน้าเว็บติดต่อด้านความปลอดภัย (ตามธรรมเนียมคือ "https://www.example.com/security") และหากเป็นไปได้ควรทำให้หน้านั้นค้นพบได้ง่าย เช่น ผ่านส่วนท้ายของเว็บไซต์ แผนผังเว็บไซต์ และการค้นหา

  • ไม่ดี: ผู้ผลิตไม่มีที่อยู่อีเมลหรือหน้าเว็บ หรือไม่ทำให้ค้นพบได้ง่าย

ตรวจสอบให้แน่ใจว่าเจ้าหน้าที่มีความสามารถ

  • ดี: ผู้ผลิตอบรมเจ้าหน้าที่ฝ่ายสนับสนุนว่าควรทำอย่างไรหากได้รับคำสอบถามด้านความปลอดภัย เช่น วิธีตอบกลับพร้อมข้อมูลติดต่อ หรือวิธีส่งต่อคำสอบถามไปยังทีมภายในที่ถูกต้อง

  • ดี: ผู้ผลิตตรวจสอบเป็นระยะว่าความสามารถของเจ้าหน้าที่ใช้งานได้

  • ไม่ดี: ผู้ผลิตไม่อบรมหรือไม่ตรวจสอบ

ตอบกลับผู้ค้นพบภายในกรอบเวลา

  • หากผู้ค้นพบไม่ได้ระบุกรอบเวลา ให้ใช้หนึ่งวันทำการ เพราะเป็นมาตรฐานอุตสาหกรรมและแนวปฏิบัติที่ดีที่สุดของอุตสาหกรรมในปัจจุบัน

  • หากผู้ค้นพบถามคำถาม ให้ตอบ โดยเฉพาะอย่างยิ่งหากผู้ค้นพบขออนุญาตทดสอบ ให้แน่ใจว่าคำตอบทั้งหมดชัดเจนและตรงไปตรงมา

ตอบกลับผู้ค้นพบผ่านผู้ติดต่อด้านความปลอดภัยที่ได้รับอนุญาต และ/หรือกระบวนการด้านความปลอดภัยที่ได้รับอนุญาต

  • ดี: การตอบกลับจากที่อยู่อีเมลเฉพาะด้านความปลอดภัย เช่น "security@example.com"

  • ตัวอย่างที่ไม่ดี: การตอบกลับจากที่อยู่อีเมลทั่วไป เช่น "help@example.com" หรือจากผู้ที่ไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัยที่ได้รับอนุญาต

แจ้งผู้ค้นพบว่าปัญหานั้นได้รับการรับรู้เป็นรายงานด้านความปลอดภัย

  • ดี: ถ้อยคำเฉพาะด้านความปลอดภัย เช่น "ทีมรักษาความปลอดภัยของเราได้รับรายงานการเปิดเผยอย่างรับผิดชอบของคุณแล้ว" หรือ "กระบวนการด้านความปลอดภัยของเรามีขั้นตอนถัดไปดังนี้" หรือ "ข้อมูลของคุณอยู่ในระบบติดตามด้านความปลอดภัยของเราแล้วด้วยหมายเลข id XYZ" เป็นต้น

  • ไม่ดี: ถ้อยคำทั่วไป เช่น "เราขอบคุณที่คุณใช้บริการ" หรือ "เราใส่ใจความปลอดภัยอย่างจริงจัง" ถ้อยคำที่โยนความรับผิดชอบ เช่น "เราส่งอีเมลของคุณไปยังแผนกอื่นแล้ว" เป็นต้น

ขั้นตอนที่ 3: ทำงานด้วยความสุจริตใจ

ขั้นตอนที่ 3 เป็นหน้าที่ของผู้ค้นพบและผู้ผลิตร่วมกัน: ทำงานด้วยความสุจริตใจ

เข้าใจว่าการเปิดเผยช่องโหว่แบบประสานงานเป็นกระบวนการที่ตั้งอยู่บนความสุจริตใจ

  • เป้าหมายอันดับ 1 คือความสุจริตใจในการช่วยให้ผู้ใช้ปกป้องตนเองจากความเสี่ยงด้านความปลอดภัย

  • เป้าหมายอันดับ 2 คือความสุจริตใจในการแก้ไขปัญหาความปลอดภัย

  • ผู้ค้นพบและ/หรือผู้ผลิตอาจเลือกด้วยความสุจริตใจที่จะให้ผู้เชี่ยวชาญด้านความปลอดภัยคนอื่นเข้ามาเกี่ยวข้อง เช่น ติดต่อนักวิจัยด้านความปลอดภัยที่เกี่ยวข้องรายอื่นเพื่อช่วยแก้ปัญหา

เข้าใจว่าการเปิดเผยช่องโหว่แบบประสานงานไม่ก่อให้เกิดภาระผูกพันใด ๆ

  • ผู้ค้นพบและ/หรือผู้ผลิตอาจถอนตัวเมื่อใดก็ได้ ด้วยเหตุผลใดก็ได้ จะแจ้งล่วงหน้าหรือไม่ก็ได้ การแจ้งให้ผู้เกี่ยวข้องทุกคนทราบและอัปเดตข้อมูลอยู่เสมอเป็นมารยาทที่ดี แต่ก็ไม่ได้เป็นไปได้ ใช้ได้จริง หรือพึงประสงค์เสมอไป

  • การเปิดเผยช่องโหว่แบบประสานงานไม่ก่อให้เกิดข้อตกลงทางกฎหมายใด ๆ หากผู้ค้นพบและผู้ผลิตมีข้อตกลงทางกฎหมายอยู่แล้ว เราขอแนะนำให้ทุกฝ่ายที่เกี่ยวข้องปรึกษาทนายความที่เหมาะสม อย่าใช้เอกสารนี้เป็นคำแนะนำทางกฎหมาย

เข้าใจว่าการเปิดเผยช่องโหว่แบบประสานงานมุ่งใช้การสื่อสารที่ดีและมุ่งปฏิเสธการข่มขู่

  • การเปิดเผยช่องโหว่แบบประสานงานจะดีที่สุดเมื่อทุกฝ่ายที่เกี่ยวข้องเข้าใจว่าเป้าหมายอันดับ 1 คือการช่วยให้ผู้ใช้ปกป้องตนเองจากความเสี่ยงด้านความปลอดภัย และเป้าหมายอันดับ 2 คือการแก้ไขปัญหาความปลอดภัย

  • การเปิดเผยช่องโหว่แบบประสานงานปฏิเสธการข่มขู่ทุกรูปแบบ ไม่ว่าจะเป็นการแก้แค้น การขู่ให้กลัว การระงับ การเพิกถอน การกรรโชก ภาระในการติดตามผล หรือการโทษผู้เสียหาย

เข้าใจว่าการเปิดเผยช่องโหว่แบบประสานงานอาจมีความหมายต่างกันสำหรับแต่ละคน

  • ผู้ค้นพบและผู้ผลิตอาจมีความเข้าใจเกี่ยวกับการเปิดเผยช่องโหว่แบบประสานงานต่างกัน ความเข้าใจเหล่านี้อาจไม่ตรงกัน ความสุจริตใจรวมถึงการที่ทุกฝ่ายที่เกี่ยวข้องเข้าใจเรื่องนี้

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

เข้าใจว่าโดยทั่วไปผู้ค้นพบกำลังทำสิ่งที่เป็นประโยชน์ให้แก่ผู้เผยแพร่

  • โดยทั่วไปผู้ค้นพบไม่จำเป็นต้องขออนุญาตจากใครเพื่อเผยแพร่ช่องโหว่

  • โดยทั่วไปข้อมูลของผู้ค้นพบช่วยเหลือผู้เผยแพร่

ตรวจสอบความสำเร็จ

หลังจากปัญหาได้รับการแก้ไขแล้ว ผู้ผลิตต้องตรวจสอบความสำเร็จ

  • ทุกคนและทุกกระบวนการจัดการการเปิดเผยได้สำเร็จหรือไม่ ถ้าใช่ก็ดี ถ้าไม่ ให้พิจารณาทำการศึกษาหลังเหตุการณ์ เช่น การวิเคราะห์สาเหตุรากเหง้า (RCA) รายงานหลังเหตุการณ์ (post-mortem) แผนภูมิอิชิกาวะ หรือการวิเคราะห์เชิงเหตุและผลโดยอิงทฤษฎีระบบ (CAST)

  • ปัญหาที่ยังค้างอยู่ได้รับการคัดแยก (triage) และติดตามหรือไม่

  • ผู้ผลิตและผู้ค้นพบเข้าใจตรงกันหรือไม่ว่าต้องทำอะไรสำหรับขั้นตอนถัดไป เรื่องนี้สำคัญเป็นพิเศษที่ต้องทำให้ถูกต้อง ในกรณีที่อาจมีการเปิดเผยช่องโหว่แบบประสานงานต่อเนื่องอีก

แนวทาง

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

หากคุณกำลังมองหาแนวทาง คุณอาจสนใจสามด้านนี้ ซึ่งอธิบายไว้ด้านล่าง

  • ชาวสะมาเรียผู้ใจดี

  • หน้าที่ในการช่วยเหลือ

  • หน้าที่ในการใช้ความระมัดระวัง

ชาวสะมาเรียผู้ใจดี

Wikipedia: Good Samaritan law

กฎหมายชาวสะมาเรียผู้ใจดีให้ความคุ้มครองทางกฎหมายแก่ผู้ที่ให้ความช่วยเหลืออันสมควรแก่ผู้ที่ได้รับบาดเจ็บ เจ็บป่วย ตกอยู่ในอันตราย หรือไร้ความสามารถ หรือผู้ที่เขาเชื่อว่าเป็นเช่นนั้น การคุ้มครองนี้มีขึ้นเพื่อลดความลังเลของผู้อยู่ในเหตุการณ์ในการเข้าช่วยเหลือ เนื่องจากกลัวถูกฟ้องร้องหรือถูกดำเนินคดี

หน้าที่ในการช่วยเหลือ

Wikipedia: Duty to rescue

หน้าที่ในการช่วยเหลือเป็นแนวคิดที่อธิบายสถานการณ์ที่ฝ่ายหนึ่งอาจต้องรับผิดชอบเพราะไม่เข้าช่วยเหลืออีกฝ่ายที่ตกอยู่ในอันตราย หน้าที่ในการช่วยเหลืออาจมีมิติทางศีลธรรมและ/หรือทางกฎหมาย

หน้าที่ในการใช้ความระมัดระวัง

Wikipedia: Duty of care

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

กรณีพิเศษ

ทีมรักษาความปลอดภัยของเราพบกรณีพิเศษหลากหลายรูปแบบ

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

การเข้าถึงข้อมูลของผู้ใช้อื่น

ตัวอย่าง: คุณพบว่า URL หนึ่งมี user id ของคุณอยู่ในนั้น และเผยให้เห็นบั๊ก และคุณเชื่อว่าสามารถแก้ไข URL เพื่อเปลี่ยน user id ของคุณเป็น user id ของผู้ใช้คนอื่นได้

  • ผู้ค้นพบทำเช่นนี้ได้หรือไม่ เช่น ด้วยเป้าหมายเพียงอย่างเดียวคือค้นหาว่าส่งผลกระทบต่อผู้ใช้คนอื่นด้วยหรือไม่

  • การทำความเข้าใจขอบเขตของความเสี่ยงต่อผู้ใช้ทุกคนอย่างรวดเร็ว สำคัญกว่าการปกป้องผู้ใช้สองสามคนที่ข้อมูลอาจถูกแฮ็กเกอร์มองเห็นได้อยู่แล้วหรือไม่

  • ผู้ค้นพบทำกับผู้ใช้จำนวนมากเท่าที่ต้องการได้หรือไม่

  • ผู้ค้นพบพยายามติดต่อผู้ใช้เพื่อแจ้งให้ทราบว่าได้รับผลกระทบได้หรือไม่ การเสนอแนะแนวทางบรรเทาผลกระทบทำได้หรือไม่

การปฏิเสธการให้บริการ

ตัวอย่าง: คุณพบบั๊กที่ทำให้บัญชีของคุณถูกระงับโดยไม่ตั้งใจ เช่น ทำให้รหัสผ่านถูกล็อก

  • กรณีนี้ถือเป็นการโจมตีแบบปฏิเสธการให้บริการหรือไม่

อีเมลที่ไม่ได้รับการร้องขอ

ตัวอย่าง: คุณพยายามรายงานปัญหาความปลอดภัยแก่บุคคลในบริษัทที่คุณคิดว่าเกี่ยวข้อง และคุณค้นพบจากการค้นคว้าใน LinkedIn, Facebook เป็นต้น หรือจากการใช้รูปแบบการตั้งชื่อเช่น "webmaster@example.com" หรือ "security@example.com"

  • ทำเช่นนี้ได้หรือไม่

  • กรณีนี้ถือเป็นอีเมลที่ไม่ได้รับการร้องขอหรือไม่

  • กรณีนี้ถือเป็นอีเมลที่ไม่ได้รับอนุญาตหรือไม่

กลุ่มที่ถูกกีดกัน

ตัวอย่าง: คุณอยู่ในกลุ่มที่ถูกกีดกัน เช่น เป็นผู้เยาว์ หรืออยู่ในรายชื่อการคว่ำบาตร หรืออยู่ในประเทศที่อยู่ในรายชื่อการคว่ำบาตร

  • คุณรายงานได้หรือไม่

  • รายงานโดยไม่เปิดเผยตัวตนได้หรือไม่

  • การจงใจเปลี่ยนแปลงข้อมูลที่อาจระบุตัวตนได้ เช่น เพื่อหลุดพ้นจากกลุ่มที่ถูกกีดกัน และด้วยเป้าหมายเพื่อช่วยให้การเปิดเผยไปถึงบุคคลที่ถูกต้อง ทำได้หรือไม่

บุคคลที่สาม

ตัวอย่าง: คุณพบว่าซอฟต์แวร์ของบริษัทหนึ่งมีบั๊กที่เกี่ยวข้องกับบุคคลที่สาม เช่น การเชื่อมต่อกับซอฟต์แวร์อื่นหรือเว็บไซต์อื่น

  • คุณรายงานข้อมูลทั้งหมดที่พบให้ทั้งสองฝ่ายได้หรือไม่

  • จำเป็นต้องทำการเปิดเผยอย่างรับผิดชอบสองครั้งที่ต่างกันหรือไม่ เช่น รายงานหนึ่งฉบับให้บริษัทหนึ่ง และรายงานอีกฉบับให้บริษัทบุคคลที่สาม เพื่อจำกัดข้อมูลที่ส่งให้แต่ละบริษัท

  • ผู้ค้นพบแนะนำให้บริษัทเหล่านั้นติดต่อกันเองได้หรือไม่

ซอฟต์แวร์ที่สร้างความเสียหาย

ตัวอย่าง: คุณมีความสามารถพอที่จะเขียนไวรัสที่คุณเชื่อว่าน่าจะช่วยให้ผู้ใช้ปกป้องตนเองจากความเสี่ยงด้านความปลอดภัย หรือระบุว่าพวกเขามีความเสี่ยงหรือไม่ หรือแก้ไขความเสี่ยงด้านความปลอดภัยนั้น

  • ทำได้หรือไม่

  • ผู้ค้นพบชี้ให้ผู้ใช้ไปยังซอฟต์แวร์เช่นนี้ และ/หรือคู่มือหรือบทช่วยสอนที่อธิบายวิธีสร้างซอฟต์แวร์ประเภทนี้ได้หรือไม่

การเปิดเผยช่องโหว่แบบประสานงาน เทียบกับ การเปิดเผยอย่างรับผิดชอบ

การเปิดเผยช่องโหว่แบบประสานงานเป็นคำที่นิยมใช้

  • แง่มุมที่สำคัญที่สุดคือการประสานงานระหว่างผู้ค้นพบและผู้ผลิต

การเปิดเผยอย่างรับผิดชอบ (responsible disclosure) เป็นคำที่เลิกแนะนำให้ใช้แล้ว

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

การติดตาม