แรงกดดัน

 (daniel.haxx.se)
3 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การบำรุงรักษา curl ได้กลายเป็นงานเต็มเวลาที่ผสานทั้งประโยชน์สาธารณะ ความท้าทายทางวิศวกรรม และเป้าหมายด้านคุณภาพ และดำเนินต่อเนื่องมาโดยใช้เวลาราว 50 ชั่วโมงต่อสัปดาห์
  • curl เป็นไลบรารีและเครื่องมือสำหรับการรับส่งข้อมูลที่มี ฐานการติดตั้งราว 30,000 ล้านชุด ทำให้มีภาระอย่างมากที่จะต้องไม่ให้ความล้มเหลวด้านความปลอดภัยลุกลามไปถึงผู้ใช้
  • ขณะนี้จำนวนรายงานด้านความปลอดภัยที่ไหลเข้ามาสูงกว่าในปี 2024 ถึง 4–5 เท่า และมากกว่าปี 2025 สองเท่า โดยเฉลี่ยมากกว่าหนึ่งเรื่องต่อวัน จึงต้องจัดการทันที
  • การจัดการด้านความปลอดภัยครอบคลุมตั้งแต่การตรวจสอบข้อกล่าวอ้าง ประเมินความร้ายแรง เขียนแพตช์ หาว่าปัญหาถูกนำเข้ามาเมื่อใด เขียนคำแนะนำ ไปจนถึงการสื่อสารกับนักวิจัยและทีมความปลอดภัย
  • ก่อนถึงกำหนดรีลีสถัดไป มี ช่องโหว่ที่ยืนยันแล้ว 12 รายการ รออยู่แล้ว และแม้อยู่ภายใต้แรงกดดันที่ไม่เคยมีมาก่อน ข้อจำกัดด้านเงินทุนและกำลังคนก็เริ่มปรากฏชัด

ความรับผิดชอบต่อ curl และการบำรุงรักษาระยะยาว

  • งานโอเพนซอร์ส ไม่ใช่งานเพื่อเงินหรือชีวิตที่หรูหรา แต่เป็นสิ่งที่ดำเนินต่อไปเพราะมีความหมายทางสังคม มีประโยชน์สาธารณะ และเป็นความท้าทายทางวิศวกรรมในการทำให้ทุกคนใช้งานได้
  • งานกับ curl กลายเป็นงานเต็มเวลาตั้งแต่ปี 2019 และโดยทั่วไปใช้เวลาราว 50 ชั่วโมงต่อสัปดาห์ ทั้งช่วงกลางวัน ดึก วันธรรมดา และวันหยุดสุดสัปดาห์
  • เป้าหมายของ curl คือการเป็น ไลบรารีและเครื่องมือสำหรับการรับส่งข้อมูล ที่ดีที่สุดเท่าที่จะเป็นไปได้ และเป็นโครงการระดับแนวหน้าในด้านคุณภาพ ประสิทธิภาพ และความปลอดภัยของโอเพนซอร์ส
  • curl ไม่ใช่โครงการของคนคนเดียว และหากไม่มีสมาชิกทีม curl ก็คงไม่เป็นอย่างทุกวันนี้ แต่หลายคนยังคงเชื่อมโยง curl เข้ากับ Daniel Stenberg เป็นการส่วนตัวอย่างมาก
  • คำวิจารณ์ต่อ curl มักถูกรับรู้เหมือนเป็นคำวิจารณ์ต่อการตัดสินใจและทางเลือกที่ตนสนับสนุนหรือเลือกเอง และ curl ก็ได้กลายเป็นโครงการส่วนตัวที่เปลี่ยนชีวิตไปตลอดกาล
  • ปลายปี 2026 โครงการ curl จะมีอายุครบ 30 ปี และมีการกล่าวถึงจำนวนการติดตั้ง curl ทั่วโลกว่ามีราว 30,000 ล้านชุด

การเปลี่ยนแปลงของสภาพแวดล้อมรายงานด้านความปลอดภัย

  • ในช่วงไม่กี่ปีที่ผ่านมา สภาพแวดล้อมของรายงานความปลอดภัยของ curl ได้เปลี่ยนจากความไม่พอใจต่อ LLM ที่งี่เง่า ไปเป็น รายงาน AI slop, การยุติ bug bounty และ ความวุ่นวายคุณภาพสูง ที่เริ่มราวเดือนมีนาคม 2026
  • ทุกครั้งที่เกิดความล้มเหลวด้านความปลอดภัยครั้งใหญ่ซ้ำแล้วซ้ำเล่าในผลิตภัณฑ์อินเทอร์เน็ต โครงสร้างพื้นฐานซอฟต์แวร์ และโอเพนซอร์ส แรงกดดันก็ยิ่งเพิ่มขึ้นจากข้อเท็จจริงที่ว่า curl อยู่แทบทุกที่ และเรื่องแบบนั้นต้องไม่เกิดขึ้นกับ curl หรือผู้ใช้ของมัน
  • โครงการ curl ได้ค่อย ๆ ลดโอกาสที่ข้อบกพร่องจะเล็ดรอดหรือทำให้ระบบล่มลง ด้วยการเพิ่มการตรวจสอบ การทดสอบ และแนวทางปฏิบัติให้มากขึ้น

การตรวจสอบเข้มข้นและความเสี่ยงที่ยังคงเหลือ

  • หลังจากเหตุการณ์ Mythos พบเพียงปัญหาความร้ายแรงต่ำหนึ่งรายการในการสแกนครั้งแรก ก็มีการย้ำซ้ำ ๆ ว่า curl เป็นหนึ่งในโค้ดที่ถูกตรวจทาน ทำ fuzzing และตรวจสอบมากที่สุดเท่าที่จะจินตนาการได้
  • สถานะเช่นนี้ไม่ได้เกิดจากความบังเอิญหรือโชค แต่เป็นผลจากการทำงานอย่างมุ่งมั่นหลายทศวรรษ ความใส่ใจในรายละเอียด และการ ปรับปรุงแบบวนซ้ำ ที่ไม่สิ้นสุด
  • แม้จะมีการทบทวนและตรวจสอบมาก ก็ไม่ได้แปลว่าไม่มีบั๊กหรือปัญหาด้านความปลอดภัย เพราะ curl คือโค้ดภาษา C หลายแสนบรรทัดที่ทำงานเครือข่ายแบบขนานอย่างเข้มข้นบนหลายโปรโตคอล หลายระบบปฏิบัติการ และหลายสถาปัตยกรรม CPU
  • ทุกครั้งที่พบปัญหา ก็จะมีการแก้ไขและออกแพตช์ วนซ้ำเช่นนี้ต่อไป
  • ฐานการติดตั้งทั่วโลกราว 30,000 ล้านชุด หมายความว่า curl อาจอยู่ในโทรศัพท์ แท็บเล็ต รถยนต์ ทีวี เครื่องพิมพ์ เกมคอนโซล และเครื่องใช้ในครัวหลายครั้ง
  • ในอดีต โครงการที่มีบั๊กใหญ่จนทำให้โลกปั่นป่วนอยู่พักหนึ่งมักได้รับความสนใจ และบางโครงการก็ได้รับเงินทุนและกำลังคนจนสามารถจ้างวิศวกรเต็มเวลาได้หลายคน

ปริมาณรายงานความปลอดภัยที่ไม่เคยมีมาก่อน

  • ขณะนี้อัตราการไหลเข้าของรายงานด้านความปลอดภัยสูงกว่าปี 2024 ถึง 4–5 เท่า และเป็นสองเท่าของปี 2025 โดยเฉลี่ยมีรายงานเข้ามามากกว่าหนึ่งเรื่องต่อวัน
  • คุณภาพของรายงานสูงกว่าที่ผ่านมาอย่างมาก และส่วนใหญ่เขียนมาอย่างละเอียดและยาว
  • เนื่องจากรายงานยังคงเข้ามาอย่างต่อเนื่อง จึงต้องจัดการให้เร็วที่สุดทันทีที่มาถึง เพราะหากจัดการไม่ทันกับอัตราที่มันเข้ามา รายการปัญหาความปลอดภัยที่อาจเป็นไปได้ก็จะสะสมขึ้นเรื่อย ๆ
  • รายการปัญหาความปลอดภัยที่อาจเป็นไปได้และควบคุมไม่ได้ สร้างภาระทางจิตใจ
  • ขณะนี้เวลาส่วนใหญ่ถูกใช้ไปกับการจัดการรายการประเด็นความปลอดภัยที่รายงานผ่าน HackerOne
  • งานหลักประกอบด้วยการตรวจสอบข้อกล่าวอ้าง ประเมินความร้ายแรง เขียนแพตช์ หาว่าบั๊กถูกนำเข้ามาเมื่อใด ทำความเข้าใจช่องโหว่ เขียนประกาศแนะนำด้านความปลอดภัยอย่างละเอียด และสื่อสารกับนักวิจัยด้านความปลอดภัยรวมถึงทีมความปลอดภัยของ curl

แรงกดดันต่อสุขภาพและทีม

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

การสนับสนุนที่จำเป็นและข้อจำกัดเชิงโครงสร้าง

  • ในระยะสั้น งานที่ต้องจัดการมีมากเกินไปอยู่แล้ว จนสายเกินไปที่จะรับความช่วยเหลือทันที
  • หากบริษัทที่ใช้งานและพึ่งพา curl หรือ libcurl ในซอฟต์แวร์และบริการเชิงพาณิชย์สนับสนุนเงินทุนมากขึ้น ก็จะสามารถจ่ายให้แก่นักพัฒนาเพิ่มขึ้นเพื่อช่วยแบ่งเบาภาระงานได้
  • การทำให้ฝ่ายนายจ้างเป็นผู้จ่ายผ่านสัญญาสนับสนุน ก็เป็นอีกเส้นทางหนึ่งของการช่วยเหลือที่เป็นไปได้
  • มีลูกค้าที่ให้การสนับสนุนเช่นนี้อยู่แล้ว ทำให้สมาชิกบางคนสามารถทำงานกับ curl ได้แบบเต็มเวลา
  • อย่างไรก็ตาม ไม่ได้คาดหวังว่าจะเกิดการเปลี่ยนแปลงที่มีนัยสำคัญในด้านนี้ในเร็ว ๆ นี้ และแม้ในสถานการณ์ที่ไม่เคยมีมาก่อนและยากลำบากยิ่งขึ้น ก็มีแนวโน้มว่าสุดท้ายจะต้องฝ่าพายุนี้ไปด้วยตัวเอง
  • โครงการ curl ไม่ได้เป็นของบริษัทใด และไม่ได้อยู่ภายใต้องค์กรร่มใด ๆ
  • โครงสร้างเช่นนี้บางครั้งทำให้ทรัพยากรขาดแคลน แต่ขณะเดียวกันก็มอบอิสรภาพและความยืดหยุ่นสูงสุด
  • มาตรฐานในการดำเนินงานของโครงการมุ่งไปที่การทำให้ curl ดีที่สุดเท่าที่จะเป็นไปได้ เพื่อโลกและเพื่อผู้ใช้ curl

ด้านบวกและสถานะปัจจุบัน

  • การแก้บั๊กและปัญหาในตัวมันเองเป็นเรื่องดี และปัญหาที่ถูกรายงานหนึ่งรายการก็หมายถึงประเด็นหนึ่งที่กำลังจะถูกแก้ไข
  • ยิ่งมีรายงานมากขึ้น curl ก็ยิ่งกลายเป็นผลิตภัณฑ์ที่ดีขึ้น
  • ช่องโหว่ของ curl ที่ถูกค้นพบในช่วงไม่กี่ปีที่ผ่านมา ถูกประเมินว่ามีความร้ายแรงระดับ LOW หรือ MEDIUM ทั้งหมด และแทบไม่พบช่องโหว่ที่ร้ายแรงมาก
  • นี่ไม่ได้หมายความว่าจะไม่มี HIGH โผล่มาอีกในอนาคต แต่ก็ถือว่าเป็นสิ่งที่พบได้ไม่บ่อยอย่างน้อยในตอนนี้
  • CVE ของ curl ที่มีความร้ายแรงสูงล่าสุดคือ CVE-2023-38545 ซึ่งเปิดเผยเมื่อเดือนตุลาคม 2023
  • ขณะนี้ทีม curl กำลังเผชิญแรงกดดัน และบางครั้งการตอบสนองอาจล่าช้าได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Lobste.rs

  • หวังว่า Daniel และคนอื่น ๆ จะผ่านสถานการณ์ยากลำบากนี้ไปได้ด้วยดีโดยไม่ส่งผลเสียร้ายแรงต่อ สุขภาพหรือครอบครัว
    แต่ก็คิดว่าน่าสนใจทีเดียวว่าจากนี้เรื่องจะพัฒนาไปอย่างไร นี่ไม่ใช่ครั้งแรกที่วิธีวิเคราะห์อัตโนมัติแบบใหม่ค้นพบช่องโหว่จำนวนมากในหลายโครงการ FOSS และตอนนี้ก็ให้ความรู้สึกคล้ายกับตอนที่ greybox fuzzing ปรากฏขึ้นในช่วงปี 2010 มีความเป็นไปได้อยู่สามแบบ: A) นักพัฒนาเริ่มนำ LLM เข้าไปในกระบวนการวิจัยด้านความปลอดภัย ทำให้จำนวนช่องโหว่ใหม่ที่ LLM หาเจอลดลงมาก ขณะที่ช่องโหว่ซึ่ง LLM เข้าไม่ถึงยังคงถูกค้นพบต่อไป เป็นสถานการณ์แบบฟัซเซอร์ B) คล้าย A แต่หลังจาก LLM กวาดตรวจแล้ว การค้นพบช่องโหว่ก็แทบหยุดลง กลายเป็นสถานการณ์ที่ “LLM แก้ปัญหางานวิจัยด้านความปลอดภัยได้แล้ว” C) ในโครงการขนาดใหญ่อย่าง curl ยังมีการพบช่องโหว่ต่อเนื่องในอัตราสูง เป็นสถานการณ์แบบ “การล้างแค้นของ Tony Hoare” ที่จำนวนบั๊กในโครงการโค้ดระดับหลายแสนบรรทัดนั้นแทบไม่มีที่สิ้นสุด

    • ในความเป็นจริงคิดว่าน่าจะเป็น สถานการณ์ A
      ในสแนปช็อตของโค้ดเบสหนึ่ง ๆ จำนวนบั๊กด้านความปลอดภัยย่อมมีจำกัดอยู่แล้ว เมื่อพื้นที่ค้นหาบั๊กด้านความปลอดภัยถูกใช้จนหมด กระแสที่ถาโถมเข้ามาก็น่าจะซาลง จากนั้นก็อาจเหลือเพียงบั๊กที่ค่อย ๆ โผล่มาจากการรวมโค้ด การเพิ่ม test harness ใหม่ หรือการปรับปรุงโมเดล
      สำหรับสถานการณ์ C ในโครงการ curl มองว่าบั๊กที่พบมีความรุนแรงต่ำ เพราะเดิมทีมาตรฐานของการทดสอบด้านความปลอดภัยและเทคนิคการค้นพบบั๊กแบบดั้งเดิมนั้นสูงอยู่แล้ว สิ่งนี้แสดงให้เห็นว่าการลงทุนอย่างต่อเนื่องในการค้นหาบั๊กยังคงให้ผลตอบแทนในระยะยาว ไม่ว่าจะเป็นวิธีค้นหาแบบใดในวันนี้หรืออนาคตก็ตาม
      หากยืมคำพูดของ Marcus Hutchins มาใช้ ก็จะใกล้เคียงกับแนวคิดที่ว่า “คอขวดไม่เคยอยู่ที่การพบบั๊ก แต่เป็นการที่องค์กร ตัดสินใจไม่ลงทุนในนักวิจัยด้านความปลอดภัย” มากกว่า LLM เพียงแค่ทำให้การลงทุนนั้นมีต้นทุนถูกลง และจริง ๆ แล้วองค์กรก็สามารถลงทุนเพิ่มเพื่อหาบั๊กได้มากกว่านี้มาตั้งแต่แรก สุดท้ายแล้วมันคือการตัดสินใจเชิงนโยบาย

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

    • ถ้าบอกว่า “CVE ที่ LLM ค้นพบก็แค่ไม่ต้องไปจัดการ” ผู้ใช้ Linux จะอยากให้มี ช่องโหว่ยกระดับสิทธิ์ในเครื่อง หลายตัวค้างอยู่ในเคอร์เนลมากกว่าหรือ?
      รู้ว่านี่ไม่ใช่ประเด็นแกนกลางเสียทีเดียว แต่ปัญหาของ LLM CVE คือใครก็ตามที่ใช้เครื่องมือเดียวกันก็น่าจะหาสิ่งเดียวกันเจอได้เหมือนกัน ถ้ามีปัญหาร้ายแรงถูกค้นพบจริง ก็หมายความว่าคนอีกจำนวนมากสามารถนำมันไปสร้างสิ่งที่เป็นอันตรายได้เช่นกัน
      แน่นอนว่านี่ไม่ได้แปลว่าใช้ได้เหมือนกันหมดกับกรณีของ curl ที่มีประเด็นความรุนแรงต่ำหรือไม่ใช่เรื่องความปลอดภัยทะลักเข้ามา แต่ถึงอย่างนั้นก็ยังต้องมีการตัดสินจริง ๆ ว่าประเด็นไหนควรได้ลำดับความสำคัญสูง ซึ่งก็พากลับไปที่จุดเริ่มต้นอีกครั้ง
    • กรณีของ Zig ต่างจาก Curl
      Zig ยังอยู่ระหว่างการพัฒนาอย่างแข็งขัน และทุกครั้งที่ฟีเจอร์อย่าง incremental compilation หรือ asynchronous I/O ถูกทำให้เป็นรูปเป็นร่าง ก็มีโอกาสสูงที่จะใส่บั๊กใหม่เข้าไป พร้อมกันนั้นก็อาจลบบั๊กที่เกิดจาก implementation เดิมที่ยังไม่สมบูรณ์ออกไปด้วย
      ในช่วงการพัฒนานี้ ถ้ามีใครเอาอะไรอย่าง Mythos มารันกับ Zig ด้วยแนวคิดแบบ “หาบั๊กทั้งหมดให้เจอและอย่าพลาดเลย” ก็น่าจะมีรายงานออกมามหาศาล แต่มีโอกาสสูงที่ทั้งหมดนั้นจะไร้ประโยชน์สำหรับเราในทางปฏิบัติ ทุกวันนี้คุณค่าหลักของรายงานบั๊กคือการส่งสัญญาณว่ามีผู้ใช้ที่ติดขัดอยู่กับกรณีใช้งานบางอย่าง และถ้าเราตัดสินใจให้ความสำคัญ เราก็สามารถช่วยปลดล็อกให้ผู้ใช้คนนั้นได้
      แน่นอนว่าสถานะนี้จะไม่อยู่ตลอดไป ฟีเจอร์สำคัญของคอมไพเลอร์จำนวนมากกำลังเข้าที่เข้าทาง และเมื่อมันเสถียรแล้ว การหาบั๊กทั้งหมดและแก้ไขมันจะกลายเป็นสิ่งสำคัญสูงสุด ตอนนั้นข้อเท็จจริงที่ว่าบั๊กถูกค้นพบแล้วจะสำคัญโดยไม่เกี่ยวกับวิธีที่ใช้ค้นพบ แต่ปัญหานั้นจะไปจัดการกันในเวลานั้น
      ในระหว่างนี้ นโยบายก็ง่าย ๆ คือ แบน LLM
    • ถ้าบอกว่า “ปล่อยให้คนที่อยากทำเป็นคนรับไป” พวก black hat ก็คงยินดีรับประเด็นด้านความปลอดภัยนั้นไปจัดการเอง เพียงแต่มันอาจไม่ใช่วิธีที่ทุกคนต้องการ
      เข้าใจได้ว่าทำไมถึงแบนการมีส่วนร่วมจาก LLM แต่ก็ไม่เห็นด้วย ช่องโหว่ด้านความปลอดภัยก็คือช่องโหว่ ไม่ว่าจะถูกค้นพบด้วยวิธีใด
      คิดว่าวิธีที่ Daniel ทำอยู่ดีที่สุดแล้ว คือแก้บั๊กที่แก้ได้เพื่อให้ผู้ใช้ปลอดภัยขึ้น พร้อมกับสื่อสารว่าต้นทุนของเรื่องนี้สูงมากและขอการสนับสนุน แม้เขาอาจแทบไม่มีโอกาสได้อ่านข้อความนี้ แต่ก็อยากสนับสนุนและแนะนำให้จำกัดปริมาณงานเพื่อให้ความสำคัญกับสุขภาพกายและใจเป็นอันดับแรก เชื่อว่าคนส่วนใหญ่ในโลกจะเข้าใจ และมีเพียงส่วนน้อยเท่านั้นที่จะบ่น
    • ถ้า CVE นั้นเป็นของจริง วิธีที่มันถูกค้นพบ ก็ไม่สำคัญ ดังนั้นจึงยังไม่ชัดเจนว่าวิธีนี้จะใช้ได้อย่างไร
    • เคยเห็นท่าทีคล้ายกันนี้กับบั๊กด้านความปลอดภัยที่คนจาก Project Zero ค้นพบ
      ดูเหมือนว่ามีประเด็นสำคัญหายไปสองข้อ 1) ไม่ใช่ว่าบริษัท LLM หรือ Project Zero เป็นคนใส่บั๊กความปลอดภัยนั้นลงในโค้ด 2) การแก้บั๊กความปลอดภัยไม่ได้ทำเพื่อบริษัท LLM หรือ Project Zero แต่ทำเพื่อ ผู้ใช้ ถ้าบั๊กความปลอดภัยถูกนำไปใช้โจมตี ผู้ใช้ต่างหากที่จะเป็นฝ่ายเสียหาย
      โดยเฉพาะในกรณีของบั๊กที่ LLM ค้นพบ ตอนนี้มีสัญญาณแล้วว่าคนอื่นที่ใช้ LLM เดียวกันในหลายโครงการโอเพนซอร์สกำลังส่งรายงานซ้ำเข้ามา ดังนั้นถ้าฝ่ายป้องกันปล่อยมือ ก็ต้องสมมติว่าฝ่ายโจมตีก็จะรับรู้บั๊กที่ LLM พบเช่นกัน

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

  • ไม่แน่ใจว่านี่เหมาะกับโครงการอย่าง curl ไหม แต่การ freeze ฟีเจอร์ ไว้ช่วงหนึ่งแล้วโฟกัสเฉพาะรายงานบั๊ก/CVE ที่ไหลเข้ามาจะช่วยได้หรือเปล่า?
    ถ้าเป็นชุดฟีเจอร์ที่ถูกกำหนดตายตัว จำนวนบั๊ก/CVE ที่เป็นไปได้ก็น่าจะมีจำกัด และถ้าไล่แก้ไปเรื่อย ๆ ก็น่าจะเข้าใกล้ 0 ได้
    ไม่ว่าอย่างไร ก็ขอให้พวกเขาโชคดี การดูแลซอฟต์แวร์ที่สำคัญขนาดนั้นในช่วงเวลาแบบนี้คงไม่ใช่เรื่องง่าย

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