AI กำลังทำลายวัฒนธรรมช่องโหว่สองแบบ

 (jefftk.com)
6 คะแนน โดย GN⁺ 14 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังการเปิดเผย Copy Fail Hyunwoo Kim เห็นว่าการแก้ไขเดิมยังไม่เพียงพอ จึงแชร์แพตช์ในวันเดียวกัน แต่กระบวนการแก้ไขแบบเปิดเผยอย่างเงียบ ๆ สไตล์ Linux ถูกคนนอกค้นพบ ทำให้การปิดข่าวสิ้นสุดลง
  • ใน Linux โดยเฉพาะส่วนเครือข่าย มีธรรมเนียมที่จะแชร์ผลกระทบด้านความปลอดภัยในรายชื่อแบบปิด และแก้บั๊กอย่างรวดเร็วในที่สาธารณะ โดยพยายามคงการมีอยู่ของช่องโหว่จริงไว้ภายใต้ embargo เป็นเวลาหลายวัน
  • หลังจากมีคนอื่น ค้นพบ การเปลี่ยนแปลงที่เปิดเผยนั้นและวิเคราะห์ผลกระทบด้านความปลอดภัยได้ ก็มีการ เปิดเผย เรื่องนี้ และต่อมาจึงมีการเผยแพร่รายละเอียดทั้งหมด
  • เมื่อ AI ลดต้นทุนในการประเมินนัยด้านความปลอดภัยของแต่ละคอมมิตลง การค้นหาช่องโหว่จากการแก้ไขที่เปิดเผยอย่างเงียบ ๆ ก็ง่ายขึ้น และ อัตราส่วนสัญญาณต่อสัญญาณรบกวน ก็ดีขึ้น
  • การเปิดเผยแบบประสานงานตามกรอบ 90 วัน แบบดั้งเดิมก็กำลังอ่อนแรงลงเช่นกัน โดยในกรณีนี้หลังจาก Kim รายงานช่องโหว่ ESP เพียง 9 ชั่วโมง Kuan-Ting Chen ก็รายงานอย่างเป็นอิสระเช่นกัน ทำให้การปิดข่าวที่สั้นมากอาจเป็นทิศทางที่ดีกว่า

การปะทะกันระหว่าง Copy Fail กับแนวปฏิบัติการแก้ไขความปลอดภัยของ Linux

  • หลังช่องโหว่ Copy Fail ถูกเปิดเผย Hyunwoo Kim เห็นว่าการแก้ไขเดิมยังไม่เพียงพอ จึงแชร์แพตช์ ในวันเดียวกัน
  • Kim ปฏิบัติตามขั้นตอนที่พบได้บ่อยใน Linux โดยเฉพาะในส่วนเครือข่าย
    • แชร์ผลกระทบด้านความปลอดภัยในรายชื่อแบบปิดของวิศวกรความปลอดภัย Linux
    • แก้บั๊กในที่สาธารณะแบบเงียบ ๆ และรวดเร็ว
    • เป้าหมายคือคงการมีอยู่ของช่องโหว่ร้ายแรงไว้ภายใต้ embargo เป็นเวลาหลายวัน ในขณะที่เปิดเผยเฉพาะตัวแก้ไขจริง
  • หลังจากมีคนอื่น ค้นพบ การเปลี่ยนแปลงดังกล่าวและทราบผลกระทบด้านความปลอดภัย ก็ได้ เปิดเผย เรื่องนี้
  • เมื่อถือว่าช่องโหว่ถูกเปิดเผยแล้ว การปิดข่าวจึงสิ้นสุดลง และต่อมาจึงมีการเผยแพร่รายละเอียดทั้งหมด

แรงกดดันที่ AI กำลังสร้างต่อวัฒนธรรมช่องโหว่สองแบบ

  • วัฒนธรรมการเปิดเผยแบบประสานงาน

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

  • วัฒนธรรม “บั๊กก็คือบั๊ก”

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

  • ความเสี่ยงของแนวทางแก้ไขแบบเปิดเผยเพิ่มขึ้นเพราะ AI

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

  • การปิดข่าวระยะยาวก็อ่อนแรงลง

    • ในอดีต ความเร็วในการตรวจจับช้ากว่า ดังนั้นเมื่อรายงานให้ vendor และตั้งกรอบเปิดเผย 90 วัน ก็มีโอกาสสูงที่คนอื่นจะยังไม่ค้นพบในช่วงนั้น
    • ตอนนี้สมมติฐานนั้นอ่อนลง เพราะกลุ่มที่ใช้ AI ช่วยสามารถสแกนหาช่องโหว่ซอฟต์แวร์ได้จำนวนมาก
    • ในกรณีนี้ หลังจาก Kim รายงานช่องโหว่ ESP ไปเพียง 9 ชั่วโมง Kuan-Ting Chen ก็รายงานอย่างเป็นอิสระ
    • การปิดข่าวอาจสร้างความรู้สึกว่าไม่เร่งด่วนอย่างผิด ๆ และเพิ่มความเสี่ยงด้วยการจำกัดผู้ที่สามารถแก้ข้อบกพร่องได้

  • ทิศทางที่เป็นไปได้และการทดสอบโมเดลอย่างง่าย

    • คำตอบยังไม่ชัดเจน แต่การปิดข่าวที่สั้นมากดูจะเป็นแนวทางที่ดี และเมื่อเวลาผ่านไปอาจต้องสั้นลงอีก
    • AI อาจทำให้ทั้งผู้โจมตีและผู้ป้องกันทำงานได้เร็วขึ้น จึงอาจทำให้การปิดข่าวที่ในอดีตสั้นเกินกว่าจะมีประโยชน์ กลายเป็นสิ่งที่ใช้ได้จริง
    • เมื่อให้ f4c50a403 กับ Gemini 3.1 Pro, ChatGPT-Thinking 5.5 และ Claude Opus 4.7 ทั้งสามโมเดลต่างตอบได้ทันทีว่าเป็น security patch
    • เมื่อให้เฉพาะ diff โดยไม่มีบริบทของคอมมิต Gemini มั่นใจว่าเป็นการแก้ไขด้านความปลอดภัย, GPT เห็นว่ามีโอกาสสูง, ส่วน Claude มองว่ามีโอกาสสูงที่จะไม่ใช่
    • การทดสอบนี้เป็นเพียงตัวอย่างอย่างรวดเร็วมาก โดยรันแต่ละโมเดลครั้งละหนึ่งครั้งด้วยพรอมป์ต์ "Without searching, does this look like a security patch?" และยากจะให้ความหมายมากกับการเปรียบเทียบระหว่างโมเดล

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

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

 
fastkoder 23 분 전

เมื่อเทียบระหว่างการกำหนดระยะเวลาเปิดเผยข้อมูลแบบสั้นมากกับแบบยาว ก็คงต้องไปทาง "การกำหนดระยะเวลาเปิดเผยข้อมูลแบบสั้นมาก" ดังนั้น AI agent ที่รับผิดชอบด้านความปลอดภัยก็น่าจะยุ่งมากขึ้นนะครับ
 
GN⁺ 14 시간 전
ความคิดเห็นบน Hacker News

  • การเปลี่ยนแปลงนี้มีสัญญาณมานานมากแล้ว และรอยร้าวที่เห็นตอนนี้ก็พอคาดการณ์ได้ตั้งแต่ก่อนเราจะรู้จักด้วยซ้ำว่า LLM คืออะไร
    ตัวเร่งคือความโปร่งใสของซอฟต์แวร์ที่เพิ่มขึ้น การใช้โอเพนซอร์สและซอฟต์แวร์ที่เปิดเผยซอร์สโค้ดเพิ่มขึ้นมาก และเครื่องมือรีเวิร์สเอนจิเนียริงกับดีคอมไพล์ก็เก่งขึ้นมากด้วย ยุคที่ซอฟต์แวร์ปิดซอร์สแบบสำเร็จรูปทั่วไปยังซ่อนจากผู้โจมตีจริงจังได้อย่างมีนัยสำคัญนั้นจบไปเกิน 10 ปีแล้ว
    ตั้งแต่ BinDiff เป็นต้นมา ปัญหานี้ก็ค่อย ๆ ดำเนินมาเรื่อย ๆ เมื่อมีการแพตช์ซอฟต์แวร์ ก็แทบเลี่ยงไม่ได้ที่จะเปิดเผยช่องโหว่ไปพร้อมกัน ที่ผ่านมาทุกคนพยายามปฏิเสธเรื่องนี้ เพราะการจะมองออกว่าแพตช์เท่ากับการเปิดเผยช่องโหว่นั้นต้องมีความเชี่ยวชาญระดับหนึ่ง แต่ AI ได้ลบข้ออ้างนั้นทิ้งไปแล้ว
    ตอนนี้ทุกครั้งที่มีอะไรถูก merge เข้า mainline Linux ก็มีหลายองค์กรเอา diff นั้นไปใส่ใน พรอมป์ต์ LLM แล้วประเมินเชิงรุกว่าเป็นการแก้ช่องโหว่หรือไม่ พร้อมสร้างคู่มือ exploit ขึ้นมา และอีกไม่นานโปรเจกต์โอเพนซอร์สหลักส่วนใหญ่ เช่น nginx, OpenSSL, Postgres ก็คงจะเจอแบบเดียวกัน
    แนวปฏิบัติเรื่องการเปิดเผยแบบประสานงานกันไม่ได้ถูกออกแบบมาสำหรับสภาพแวดล้อมแบบนี้ และจริง ๆ แล้วผมคิดว่ามันก็ไม่เข้ากับโลกจริงมาสิบปีแล้วด้วย
    แปลกดีที่ผมไม่ได้รู้สึกไม่สบายใจกับเรื่องนี้นัก เพราะผมมองว่าแนวปฏิบัติการเปิดเผยแบบประสานงานกันมักยอมรับโดยไม่ตั้งคำถามเสมอว่าการเลื่อนการเปิดเผยเพื่อความสะดวกของผู้ดูแลระบบนั้นเป็นเรื่องดี ซึ่งสมมติฐานนี้ก็น่ากังขา การชะลอการเปิดเผยคือการพรากข้อมูลไปจากผู้ดูแลระบบที่ยังมีทางเลือกอื่นนอกจากแค่ลงแพตช์

    • ข้อความที่ว่า “ยุคที่ซอฟต์แวร์ปิดซอร์สแบบสำเร็จรูปทั่วไปยังซ่อนจากผู้โจมตีจริงจังได้อย่างมีนัยสำคัญนั้นจบไปเกิน 10 ปีแล้ว” นั้นแทบจะชัดเจนอยู่แล้ว แต่แนวป้องกันด่านสุดท้ายคือไม่แจกจ่ายซอฟต์แวร์ออกไป และพึ่งพา สถาปัตยกรรมเซิร์ฟเวอร์-ไคลเอนต์ แทน
      ถ้าช่องโหว่ถูกตรวจพบและนำไปใช้โจมตีได้ง่ายขึ้น วิธีแบบนี้ก็อาจกลายเป็นเรื่องปกติมากขึ้น แน่นอนว่ามันไม่ได้ทำได้เสมอไป
      ตลอด 11 ปีที่ผ่านมา การที่ไบนารีเกมไคลเอนต์ซึ่งถูกทำให้สับสนด้วย ProGuard ถูกดีคอมไพล์หลายครั้งแล้วถูกอัปขึ้น GitHub เป็นเรื่องน่ารำคาญพอสมควร มีแต่โค้ดฝั่งเซิร์ฟเวอร์ที่ไม่ได้ถูกแจกจ่ายเท่านั้นที่ยังคงเป็นความลับ
      ที่น่าสนใจก็คือ จนกระทั่งเราเลิกเปลี่ยน network protocol ทุกสัปดาห์ ผู้โจมตีก็แทบไม่มีปัญหาในการรีเวิร์สเอนจิเนียร์สิ่งนี้เลย ตอนนี้ถ้าเป็นผู้โจมตีที่มี LLM ช่วย ก็ดูเหมือนว่าจะตามความเร็วระดับนั้นได้เช่นกัน
    • ผมเข้าใจเหตุผลทางธุรกิจที่ทำให้เกิด การเปิดเผยช่องโหว่แบบประสานงานกัน มาตลอด และในที่ทำงานก็ไม่มีทางเลือกนอกจากต้องทำตามนโยบายนั้น แต่ในทางส่วนตัวผมอยู่ฝั่งเปิดเผยเต็มรูปแบบมาตลอด ผมรอการเปลี่ยนแปลงนี้มานานมากแล้ว

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

    • ที่ว่า “ผู้คนเปรียบเทียบ diff ของเคอร์เนลเพื่อหาอยู่นานแล้วว่าอันไหนคือ security fix” นั้นจริง แต่ต้องอาศัยทักษะ และปกติก็ไม่ได้ทำกันอย่างสม่ำเสมอหรือเป็นระบบ หากมี AI ใคร ๆ ก็ทำแบบนี้กับซอฟต์แวร์อะไรก็ได้
      ส่วน “ไม่แน่ใจว่าการลดช่วงเวลา embargo จะช่วยได้ไหม” ประเด็นคือทำไมต้อง 90 วัน และทำไมไม่ใช่ 2 ปี ข้อโต้แย้งของบทความคือปัจจัยที่ใช้ชั่งดุลนั้นเปลี่ยนไปแล้ว เพราะการค้นพบพร้อมกันเกิดบ่อยขึ้น หากอย่างไรเสียก็จะมีคนจำนวนมากนอกช่วง embargo หาช่องทาง exploit เจออยู่ดี ช่วงเวลา embargo ก็เป็นเพียงภาพลวงตา ไม่ใช่หน้าต่างเวลาจริง
      ผมเห็นด้วยกับประเด็นที่ว่า “การสร้าง exploit ราคาถูกทำให้การเปิดเผยแบบประสานงานกันสำคัญขึ้น” แต่ในขณะเดียวกันก็ทำให้มันทำได้จริงน้อยลงด้วย ถ้าแม้แต่สคริปต์คิดดี้ก็หาซีโร่เดย์และนำไปใช้โจมตีได้ ความสามารถในการประสานงานก็พังทลายลง
      วัฒนธรรม whitehat มีจริยธรรมแบบกิลด์ช่างฝีมืออยู่เสมอ ถ้ากิลด์นั้นแตกสลาย พื้นที่ของจริยธรรมนั้นก็หายไปด้วย
    • ผมไม่ได้ตามภาพรวมการพัฒนา Linux มาตลอด แต่ไม่แน่ใจว่าในอดีตเคยมีกรณีที่ exploit ใช้งานได้จริง ถูกเปิดเผยบน mailing list ตั้งแต่ก่อนแพตช์จะเข้าเคอร์เนลหรือไม่
      ผมไม่เคยเห็น และแม้จะเผื่อความเวอร์ไว้บ้าง ก็ยังให้ความรู้สึกว่าต่อไปเรื่องแบบนี้คงเกิดบ่อยขึ้นเพราะ LLM
    • Torvalds เคยบอกว่าเมื่อพบปัญหาสำคัญ สิ่งที่ต้องทำก็แค่เปิดเผยบั๊กนั้น ไม่จำเป็นต้องมีละครตามหลังมาอีก [1]
      ดังนั้นการที่ Dirtyfrag ถูกเปิดเผยผ่านการแก้ไขใน Linux kernel จึงไม่น่าแปลกใจ [2]
      [1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
      [2] https://afflicted.sh/blog/posts/copy-fail-2.html
    • น่าจะถูกกว่าถ้าจะบอกว่าเป็น ปัญหาเก่าที่ AI ทำให้แย่ลง
    • เหมือนผมจะเขียนเรื่องแนวนี้ซ้ำทุกสัปดาห์ ถ้าอนุญาตให้ขี้เกียจนิดหนึ่ง ผมจะขอแชร์เวอร์ชันที่เคยเขียนไว้ก่อนหน้านี้
      https://news.ycombinator.com/item?id=47921829

  • เกิดปัญหาใหญ่ขึ้นแล้ว
    สหรัฐฯ อยู่ในภาวะสงคราม และตอนนี้โลกส่วนใหญ่ก็ทำสงครามในระดับ การโจมตีไซเบอร์ อยู่ด้วยเช่นกัน ทั้งสหรัฐฯ สหภาพยุโรป ตะวันออกกลางส่วนใหญ่ อิสราเอล และรัสเซีย
    บริการสำคัญอย่าง Ubuntu, GitHub, Let’s Encrypt, Stryker ถูกโจมตีจนล่มครั้งละหลายวัน และระบบของโรงพยาบาลทั้งระบบก็ถูกทำให้หยุดชะงักบางส่วนด้วย
    ท่ามกลางสถานการณ์นี้ AI ได้เร่งความเร็วในการสร้างการโจมตีให้เร็วขึ้นมาก เร็วกว่าที่ฝั่งป้องกันจะตอบสนองได้ แต่ก่อนการโจมตีแบบ zero-day เป็นเรื่องหายาก ตอนนี้กลายเป็นเรื่องธรรมดาไปแล้ว
    มันจะแย่ลงก่อนจะดีขึ้น และบางทีมันอาจแย่ลงได้อีกมาก

    • ผมไม่รู้เลยว่ามันจะดีขึ้นได้อย่างไร

  • ตรงที่บอกว่า “ตอนนี้มี security fix ออกมามากเกินไป จนการไล่ดูคอมมิตน่าสนใจขึ้น เพราะอัตราส่วนสัญญาณต่อสัญญาณรบกวนสูงขึ้น” ฟังดูน่าสงสัยว่าทำไมถึงเป็นแบบนั้น
    ประเด็นหลักคือ “AI ทำให้ต้นทุนในการประเมินแต่ละคอมมิตถูกลงและมีประสิทธิภาพขึ้นเรื่อย ๆ” เมื่อมี AI สมมติฐานที่ว่า “มีการเปลี่ยนแปลงเยอะเกินไป คนคงไม่สังเกตหรอก” ก็พังลง

  • การทดสอบแบบเร็ว ๆ นี้ไม่ได้บอกอะไรได้มากนัก ถ้าถามตรง ๆ ว่า “นี่คือ security patch หรือเปล่า” คุณก็กำลังชี้นำและโน้มน้าวให้ AI ตอบตามสมมติฐานนั้น
    confusion matrix น่าจะมีประโยชน์กว่า แน่นอน ผมเข้าใจว่านี่ไม่ใช่บทความทดสอบความสามารถ AI แบบละเอียด

    • เห็นด้วยว่าไม่ได้เป็นหลักฐานเพิ่มเติมที่หนักแน่นนัก ถ้าใครสักคนเอาคอมมิต N ตัวจากรายการนั้นมารันทดสอบแบบเดียวกันรวมคอมมิตนี้ด้วย ผมคงอยากเห็นผลมาก
    • ในอุดมคติ เราควรมี ค่าสัมประสิทธิ์ phi หรือ MCC ที่คำนวณได้จาก confusion matrix ของผลลัพธ์ที่ LLM จำแนก diff ของเคอร์เนลทั้งหมดเป็นใช่/ไม่ใช่
      คำนวณได้จากจำนวน true positive, true negative, false positive และ false negative

  • เราต้องมี วงจรการแพตช์และออกรีลีสแบบอัตโนมัติ
    จนถึงตอนนี้ เรายังพึ่งกระบวนการแบบแมนนวลที่ช้าอย่างไม่น่าเชื่อในการรับรายงาน สืบสวน ตรวจสอบ แพตช์ และเตรียมรีลีส เป็นเรื่องปกติมากที่กว่าจะออกเวอร์ชันแก้ไขได้ต้องใช้เวลาหลายเดือน ซึ่งช้าเกินไปสำหรับยุคที่ผู้โจมตีปล่อย exploit ใหม่ได้ภายในไม่กี่ชั่วโมง
    หากต้องการลดค่าเฉลี่ยเวลาจนถึงการแพตช์ เราต้องปรับปรุงคอขวดในห่วงโซ่มูลค่าอย่างต่อเนื่อง
    หลังได้รับรายงานบั๊ก เราควรสามารถไปถึงผลิตภัณฑ์ที่ถูกแพตช์และพร้อมให้ QA ทดสอบได้ภายใน 1 ชั่วโมง และควรทำให้สิ่งนี้เป็นมาตรฐานหรือทำเป็นโอเพนซอร์ส เพื่อให้ซัพพลายเชนซอฟต์แวร์ทั้งหมดตั้งแต่ Linux kernel → ดิสโทร → ผลิตภัณฑ์ที่ใช้ดิสโทร → ผู้ใช้ นำไปใช้ AI มีอยู่แล้ว ไม่มีเหตุผลว่าทำไม่ได้ มีแต่เราเองที่ช้าเกินไป

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

    • SaaS แบบรวมศูนย์และปิดซอร์สจะมีข้อได้เปรียบด้านความปลอดภัยอย่างมาก
      ถ้าช่องโหว่ remote code execution ใน dependency โอเพนซอร์สทำให้ทุกคนตกอยู่ในความเสี่ยงเหมือนกันทันทีที่มีการเปิดเผย security patch ผมก็ไม่เข้าใจว่าทำไมเรื่องนี้ถึงยังเป็นประเด็นถกเถียง
    • องค์กรที่ใช้ Linux อาจรวมตัวกันใช้เงินก้อนหนึ่งเพื่อให้ AI สแกน dependency ของตัวเองต่อเนื่องและคอยแพตช์ พร้อมส่งต่อแพตช์และผลการสแกนให้กัน กลายเป็น web of trust ระหว่างกันก็ได้

  • คำกล่าวเก่าของ Tony Hoare เรื่อง “ไม่มีบั๊กที่เห็นชัด” กับ “เห็นชัดว่าไม่มีบั๊ก” นั้นเข้ากับ ยุค LLM ได้ดีกว่าที่เคย

  • คำอธิบายที่มองว่าบั๊กก็เป็นแค่บั๊ก อ่านแล้วส่วนตัวรู้สึกไม่ค่อยสมเหตุสมผลนัก แต่ผมก็รู้ว่าในโลกของ Linux มีคนจำนวนมากที่ให้ความสำคัญกับหลักการมากกว่าปัญหาเชิงปฏิบัติ
    ถึงอย่างนั้น 90 วัน ก็ดูยาวไปอยู่ดี
    สุดท้ายแล้วบริษัท AI รายใหญ่คงต้องเข้ามาช่วยคนที่ดูแลโครงสร้างพื้นฐานหลักของอินเทอร์เน็ต การเอา AI ที่ใหม่ที่สุดและดีที่สุดไปรันกับของอย่าง nginx น่าจะเป็นประโยชน์ร่วมกันของพวกเราทุกคน

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

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