ชุมชนเคอร์เนลลินุกซ์กำลังเผชิญกับช่วงเวลาหนึ่ง การตรวจสอบเชิงลึกเกี่ยวกับวิธีการรายงานและจัดการช่องโหว่สาเหตุหลักมาจากผลกระทบโดยตรงของเครื่องมือ AI ต่อการตรวจสอบโค้ด การนำระบบเหล่านี้มาใช้อย่างแพร่หลายทำให้ปริมาณการแจ้งเตือนด้านความปลอดภัยเพิ่มขึ้นอย่างมาก แต่ก็ยังเผยให้เห็นปัญหาที่ร้ายแรงของการซ้ำซ้อน ข้อมูลที่ไม่จำเป็น และภาระเพิ่มเติมสำหรับผู้ดูแลระบบด้วย
ลินัส ทอร์วัลด์ส ซึ่งเป็นบุคคลสำคัญในโครงการนี้ ได้กล่าวถึงเรื่องนี้ไว้ (ใน บันทึกการเผยแพร่ Linux 7.1-rc4) รายการความปลอดภัยส่วนตัวของเคอร์เนล “แทบจะควบคุมไม่ได้เลย” เนื่องจากการรายงานที่ได้รับการสนับสนุนจาก AI จำนวนมหาศาลรายงานเหล่านี้จำนวนมากเป็นรายงานซ้ำซ้อนหรือจัดประเภทผิดพลาด เพื่อเป็นการแก้ไขปัญหาดังกล่าว โครงการจึงได้เผยแพร่เอกสารใหม่ที่รวมอยู่ใน Linux 7.1 ซึ่งกำหนดนิยามใหม่ของสิ่งที่ถือเป็นช่องโหว่ด้านความปลอดภัยที่แท้จริง และวิธีการจัดการกับรายงานที่สร้างขึ้นโดยใช้โมเดล AI
รายชื่อด้านความปลอดภัยที่เต็มไปด้วยรายงานซ้ำซ้อน
ในการสื่อสารล่าสุดเกี่ยวกับการพัฒนา Linux 7.1 นั้น Torvalds ได้เตือนว่ารายชื่อผู้รับจดหมายแจ้งช่องโหว่ได้กลายเป็น... ปัญหาคอขวดที่ประกาศสำคัญปะปนกับรายงานที่ซ้ำซ้อนจำนวนมากปัญหาไม่ได้อยู่ที่ปริมาณเพียงอย่างเดียว แต่เป็นเพราะว่าคนหลายคนใช้เครื่องมืออัตโนมัติแบบเดียวกัน แต่สุดท้ายก็ส่งผลการค้นพบที่เหมือนกันทุกประการ
เขาอธิบายว่า นักพัฒนาเสียเวลาไปมากกับการส่งต่อข้อความไปยังผู้ที่ควรได้รับ หรือชี้แจงว่าข้อผิดพลาดนั้นได้รับการแก้ไขแล้ว แก้ไขเมื่อหลายวันหรือหลายสัปดาห์ก่อนในสาขาเคอร์เนลสถานการณ์นี้ ซึ่งบางคนเปรียบเทียบกับ "น้ำท่วม" ของอีเมล บังคับให้ต้องทุ่มเททรัพยากรไปกับการตรวจสอบอีเมลซ้ำซ้อน แทนที่จะมุ่งเน้นไปที่ช่องโหว่ใหม่และร้ายแรง
Willy Tarreau ผู้ดูแลเคอร์เนลเวอร์ชันเสถียรที่มีประสบการณ์และเป็นที่รู้จักจากผลงานเกี่ยวกับ HAProxy ได้จัดเตรียมภาพประกอบไว้ดังนี้: เมื่อไม่กี่ปีที่ผ่านมา รายชื่อผู้รับจดหมายส่วนตัวได้รับรายงานเพียงสองถึงสามฉบับต่อสัปดาห์ในขณะที่ปัจจุบันมีการจัดการรายงานประมาณห้าถึงสิบฉบับต่อวัน หลายฉบับมาจากการวิเคราะห์โดยใช้ AI ซึ่งแม้ว่าบางครั้งจะชี้ให้เห็นถึงปัญหาที่แท้จริง แต่ก็มาในรูปแบบที่ไม่สะดวกใช้งานและไม่มีข้อมูลเพิ่มเติมที่เกี่ยวข้อง
ทอร์วัลด์ไม่ได้ต่อต้านปัญญาประดิษฐ์ แต่ต่อต้านการนำปัญญาประดิษฐ์ไปใช้ในทางที่ผิด
ถึงแม้ว่าอาจจะดูเหมือนเป็นอย่างอื่น แต่ทอร์วัลด์ได้ชี้แจงอย่างชัดเจนแล้วว่า องค์กรไม่คัดค้านการใช้ปัญญาประดิษฐ์เป็นเครื่องมือในการพัฒนาและตรวจสอบตัวเขาเองยอมรับว่าใช้ระบบประเภทนี้ในงานของเขา แต่ยืนยันว่าต้องใช้ระบบเหล่านี้อย่างมีความรับผิดชอบและรอบคอบ
ในข้อความที่เขาส่งถึงชุมชน เขาเน้นย้ำว่าเครื่องมือ AI นั้น “ยอดเยี่ยม” เมื่อมันช่วยได้จริง แต่จะกลายเป็นปัญหาเมื่อมันสร้างปัญหาขึ้นมา “ความเจ็บปวดที่ไม่จำเป็นและงานสมมุติที่ไร้ประโยชน์”กล่าวอีกนัยหนึ่ง การที่แบบจำลองอัตโนมัติชี้ให้เห็นถึงช่องโหว่ที่อาจเกิดขึ้นนั้น ไม่ได้หมายความว่าควรส่งรายงานที่ตรวจสอบไม่ดีหรือรายงานที่ขาดบริบททางเทคนิคจำนวนมากไปยังช่องทางรักษาความปลอดภัย
ทอร์วัลด์ยืนยันว่าใครก็ตามที่ใช้ AI ในการค้นหาข้อบกพร่องไม่ควรส่งต่อผลลัพธ์ดิบๆ เท่านั้น แต่ควร... อ่านเอกสารประกอบเคอร์เนล ทำความเข้าใจแบบจำลองภัยคุกคาม และหากเป็นไปได้ ให้จัดทำแพทช์หรืออย่างน้อยก็อธิบายผลกระทบอย่างละเอียดเป้าหมายคือให้มนุษย์เพิ่มคุณค่าให้กับงานอัตโนมัติ แทนที่จะทำหน้าที่เป็นเพียงตัวกลางระหว่างเครื่องมือกับรายชื่อผู้รับอีเมล
กฎใหม่ใน Linux 7.1: อะไรคือช่องโหว่ และอะไรไม่ใช่
เพื่อแก้ไขสถานการณ์นี้ โครงการเคอร์เนลจึงได้เพิ่มเอกสารประกอบที่ละเอียดมากขึ้นใน Linux 7.1 เกี่ยวกับเรื่องนี้ ข้อผิดพลาดใดบ้างที่ควรได้รับการพิจารณาว่าเป็นช่องโหว่ด้านความปลอดภัย และข้อผิดพลาดใดบ้างที่เป็นเพียงบั๊กที่ต้องได้รับการแก้ไขผ่านช่องทางปกติข้อความดังกล่าวซึ่งเขียนโดย Willy Tarreau เป็นส่วนหนึ่งของ Git tree ของเคอร์เนลอยู่แล้ว และสามารถใช้งานได้ก่อนการเปิดตัว Linux 7.1-rc4
คู่มือนี้เริ่มต้นจากแนวคิดง่ายๆ: ข้อผิดพลาดส่วนใหญ่ไม่ควรถูกส่งผ่านรายการความปลอดภัยส่วนตัวแต่ควรนำปัญหาเหล่านั้นมาพูดคุยกันอย่างเปิดเผยในรายชื่อผู้รับอีเมลสำหรับการพัฒนาซอฟต์แวร์ การพูดคุยปัญหาอย่างเปิดเผยจะดึงดูดผู้ตรวจสอบมากขึ้น ครอบคลุมกรณีการใช้งานมากขึ้น และโดยทั่วไปจะนำไปสู่โซลูชันที่มีคุณภาพสูงกว่า
เอกสารระบุว่า Linux มีอยู่แล้ว แบบจำลองภัยคุกคามที่กำหนดไว้อย่างชัดเจนปัจจุบันนี้ สิ่งนี้กลายเป็นจุดอ้างอิงหลักในการตัดสินใจว่าควรจัดการกับช่องโหว่ด้านความปลอดภัยเป็นการส่วนตัวหรือไม่ ช่องโหว่ด้านความปลอดภัยถูกนิยามว่า เป็นช่องโหว่ที่อนุญาตให้ผู้โจมตีได้รับความสามารถที่ระบบการผลิตที่ได้รับการกำหนดค่าอย่างถูกต้องไม่ควรมี เป็นช่องโหว่ที่สามารถใช้ประโยชน์ได้ง่าย และเป็นภัยคุกคามที่แท้จริงต่อผู้ใช้จำนวนมาก
ในทางปฏิบัติ ผู้ที่พบปัญหาจะถูกขอให้ถามตัวเองว่าข้อผิดพลาดนั้นเกิดจากอะไร มันเป็นการละเมิดความไว้วางใจอย่างแท้จริงในสถานการณ์ปกติหากคำตอบคือไม่ใช่ วิธีที่แนะนำคือตรวจสอบรายชื่อผู้รับจดหมายสาธารณะ (เช่น LKML และรายชื่อผู้รับจดหมายเฉพาะระบบย่อย) ไม่ใช่ช่องทางความปลอดภัยที่จำกัด ถึงกระนั้น คู่มือนี้ก็ยังอนุญาตให้ใช้ความระมัดระวังได้ในระดับหนึ่ง: เมื่อไม่แน่ใจ ควรตรวจสอบรายงานที่น่าสงสัยเป็นการส่วนตัวดีกว่าปล่อยให้ช่องโหว่ที่แท้จริงหลุดรอดไปได้
อีกประเด็นสำคัญของข้อความนี้คือ การส่งรายงานข้อผิดพลาดทั่วไปไปยังรายชื่อผู้รับอีเมลส่วนตัวไม่ได้ทำให้ข้อผิดพลาดเหล่านั้นได้รับการแก้ไขเร็วขึ้นแต่อย่างใดในทางตรงกันข้าม มันกลับไปแย่งเวลาในการคัดกรองปัญหาที่ทีมรักษาความปลอดภัยจำเป็นต้องใช้ในการจัดลำดับความสำคัญของความล้มเหลวที่ร้ายแรงจริงๆ การส่งข้อความปัญหาเล็กๆ น้อยๆ จำนวนมากไปยังช่องทางนั้น จะยิ่งทำให้การป้องกันโดยรวมของระบบที่ใช้ Linux แย่ลง ซึ่งรวมถึงเซิร์ฟเวอร์ โครงสร้างพื้นฐานคลาวด์ และอุปกรณ์อุตสาหกรรม
แบบจำลองภัยคุกคาม: การแยกสิทธิ์และการยกเว้นกรณีต่างๆ
เอกสารฉบับใหม่นี้ปรับปรุงและให้รายละเอียดเกี่ยวกับแบบจำลองภัยคุกคามระดับเคอร์เนล ซึ่งระบุถึงการรับประกันต่างๆ ที่หากถูกละเมิดจะถือว่าเป็นภัยคุกคาม ปัญหาด้านความปลอดภัยที่ควรได้รับการแก้ไขอย่างเร่งด่วนซึ่งรวมถึงการแยกพื้นที่ผู้ใช้และเคอร์เนล การแยกหน่วยความจำระหว่างกระบวนการ ข้อจำกัดของ ptrace การแยกกลไก IPC และเครือข่าย และการป้องกันที่เกี่ยวข้องกับความสามารถที่ละเอียดอ่อน เช่น CAP_SYS_ADMIN, CAP_NET_ADMIN หรือ CAP_SYS_PTRACE
มีการให้ความสำคัญเป็นพิเศษกับเนมสเปซของผู้ใช้ โดยการตั้งค่าต่างๆ เช่น CONFIG_USER_NS จะช่วยให้ผู้ใช้ที่ไม่มีสิทธิ์พิเศษสามารถสร้างสภาพแวดล้อมที่แยกต่างหากได้ โครงการคาดหวังว่า เหตุการณ์เหล่านั้นไม่สามารถทำลายระบบโดยรวมได้ดังนั้น การละเมิดการแยกส่วนดังกล่าวจึงกลายเป็นปัญหาด้านความปลอดภัย
นอกจากนี้ยังมีการวิเคราะห์อินเทอร์เฟซสำหรับการดีบัก เช่น /proc/kmsg, perf หรือ debugfs โดยคำนึงถึงว่าการเข้าถึงข้อมูลที่ละเอียดอ่อนผ่านกลไกเหล่านี้มีความเสี่ยง ต้องทำการบล็อกการเข้าถึง เว้นแต่จะได้รับอนุญาตอย่างชัดแจ้งจากผู้ดูแลระบบมิเช่นนั้น อาจมีความเสี่ยงที่จะเกิดการรั่วไหลของข้อมูล ซึ่งอาจถูกนำไปใช้เพื่อปรับปรุงการโจมตีหรือยกระดับสิทธิ์การเข้าถึงได้
นอกเหนือจากคำจำกัดความของการรับประกันแล้ว คู่มือนี้ยังอธิบายอย่างชัดเจนถึงปัญหาประเภทต่างๆ อีกด้วย ไม่ควรติดป้ายกำกับว่าเป็นช่องโหว่โดยอัตโนมัติหมวดหมู่นี้รวมถึงข้อผิดพลาดในสาขาเคอร์เนลที่ล้าสมัย ตัวเลือกการคอมไพล์ที่ไม่ปลอดภัยซึ่งเลือกโดยผู้ดูแลระบบ สิทธิ์ที่ไม่ถูกต้องใน sysctl หรือระบบไฟล์ ฟังก์ชันที่สงวนไว้สำหรับการดีบัก (LOCKDEP, KASAN, FAULT_INJECTION) และโค้ดทดลองในพื้นที่จัดเตรียม
ข้อบกพร่องที่ต้องใช้ สิทธิ์การใช้งานที่มากเกินไป สถานการณ์จำลองในห้องปฏิบัติการที่ห่างไกลจากการใช้งานจริง ฮาร์ดแวร์ที่ถูกดัดแปลง จำนวนครั้งที่พยายามที่ไม่สามารถจัดการได้ หรือการตั้งค่าที่ผู้ดูแลระบบที่มีเหตุผลจะไม่นำไปใช้ในสภาพแวดล้อมการใช้งานจริง ในทำนองเดียวกัน การรั่วไหลของข้อมูลโดยไม่มีช่องโหว่ที่ชัดเจน และปัญหาบางอย่างในอิมเมจระบบไฟล์ ซึ่งโดยทั่วไปจะจัดการโดยเครื่องมืออย่าง fsck นั้นอยู่นอกขอบเขตหลักของช่องทางการรักษาความปลอดภัย
ผลการค้นพบที่ได้รับความช่วยเหลือจาก AI: จากภาคเอกชนสู่ภาครัฐ
หนึ่งในความเปลี่ยนแปลงที่โดดเด่นที่สุดในการอัปเดตครั้งนี้คือแนวทางการจัดการกับข้อบกพร่องที่ค้นพบโดยใช้ AI เอกสารระบุว่า ข้อผิดพลาดที่ตรวจพบผ่านการวิเคราะห์อัตโนมัติควรได้รับการพิจารณาว่าเป็นข้อมูลสาธารณะโดยพื้นฐานแม้ว่าการจัดส่งครั้งแรกจะดำเนินการโดยไปรษณีย์ส่วนตัวก็ตาม
เหตุผลนั้นเป็นเรื่องในทางปฏิบัติล้วนๆ: ประสบการณ์ล่าสุดจากทีมรักษาความปลอดภัยแสดงให้เห็นว่าความล้มเหลวเหล่านี้มักเกิดขึ้น พร้อมกันนี้ อยู่ในมือของนักวิจัยหลายคน ผู้ที่กำลังทดลองใช้เครื่องมือที่คล้ายคลึงกัน เป็นเรื่องปกติที่จะได้รับอีเมลหลายฉบับภายในไม่กี่ชั่วโมง โดยอธิบายถึงอาการเดียวกัน แต่มีรูปแบบที่แตกต่างกันเล็กน้อย ทำให้การคาดหวังว่าจะรักษาความลับได้เป็นเวลานานนั้นเป็นไปไม่ได้
ความเป็นจริงใหม่นี้ทำให้ทอร์วัลด์ส์โต้แย้งว่า การมองว่าข้อค้นพบเหล่านี้เป็นความลับที่ต้องปกปิดไว้จนกว่าจะมีแพทช์ออกมานั้น ไม่สมเหตุสมผลเลยหาก AI ทั่วไปสามารถค้นพบช่องโหว่เหล่านี้ได้ ก็เป็นเรื่องสมเหตุสมผลที่จะสันนิษฐานว่าผู้เกี่ยวข้องอื่นๆ รวมถึงผู้โจมตีที่อาจเกิดขึ้น ก็สามารถค้นพบผลลัพธ์เดียวกันได้ การติดป้ายกำกับว่าเป็นช่องโหว่ที่สงวนไว้จะยิ่งเพิ่มภาระงานและทำให้การประสานงานซับซ้อนขึ้นเท่านั้น
นั่นไม่ได้หมายความว่าการเผยแพร่รายละเอียดทางเทคนิคทั้งหมดโดยไม่กรองนั้นเป็นสิ่งที่แนะนำ คู่มือแนะนำว่า ในกรณีที่ตรวจพบโดยใช้ AI ควรดำเนินการดังนี้ ยังไม่มีการแชร์ตัวอย่างเกมที่ใช้งานได้สำหรับแก้ไขบั๊กในทันที (ลำดับขั้นตอนหรือโค้ดที่ทำให้เกิดข้อผิดพลาดอย่างแม่นยำ) แนวทางที่เหมาะสมคือการระบุว่ามีข้อมูลนี้อยู่ และอนุญาตให้ผู้ดูแลระบบขอข้อมูลนี้เป็นการส่วนตัวหากเห็นว่าจำเป็นต่อการตรวจสอบความถูกต้องของการแก้ไข
ด้วยแนวทางนี้ โครงการจึงพยายามผสานสองประเด็นที่น่าสนใจเข้าด้วยกัน ได้แก่ ในด้านหนึ่ง หลีกเลี่ยงการเพิ่มข้อมูลที่ผู้อื่นทราบอยู่แล้วลงในรายชื่อส่วนตัวในทางกลับกัน สิ่งสำคัญคือไม่ควรเสนอ "สูตร" การโจมตีให้กับใครก็ตามโดยปราศจากมาตรการป้องกัน โปรแกรมเล่นสื่อได้รับการยอมรับว่าเป็นเครื่องมือที่มีค่าสำหรับการแก้ไขข้อบกพร่องและการประเมินผลกระทบ แต่ก็เป็นประเด็นที่ละเอียดอ่อนหากมีการเผยแพร่โดยปราศจากการควบคุมขั้นต่ำ
ข้อกำหนดด้านคุณภาพสำหรับรายงานที่สร้างโดย AI
เอกสารฉบับใหม่ได้อุทิศส่วนหนึ่งทั้งหมดให้กับวิธีการเขียนรายงานที่ใช้ AI ปัญหาที่ทีมบำรุงรักษามักพบเจออยู่เสมอคือ รายงานเหล่านี้จำนวนมากมาถึงในรูปแบบที่ไม่ถูกต้อง ขยายใหญ่เกินจริง มีคำอธิบายที่ซ้ำซ้อน และเน้นข้อมูลสำคัญน้อยมากซึ่งทำให้การอ่านและการจัดประเภทมีความซับซ้อนมากขึ้น
ประการแรก ขอให้ส่งรายงานดังต่อไปนี้ กระชับ ชัดเจน และเข้าใจง่ายทีมงานไม่สนับสนุนการใช้รูปแบบต่างๆ เช่น Markdown การตกแต่งเพิ่มเติม หรือโครงสร้างที่ซับซ้อนซึ่งไม่เหมาะสมกับการตอบกลับแบบต่อเนื่องในรายชื่อผู้รับอีเมล แนวคิดก็คือ เมื่อส่งต่อหรืออ้างอิงข้อความ ข้อมูลจะไม่สูญหาย และข้อความจะไม่กลายเป็นก้อนที่อ่านไม่ออก
ในส่วนของเนื้อหา แนะนำให้เริ่มต้นด้วย... สรุปอย่างง่ายที่ระบุไฟล์หรือระบบย่อยที่ได้รับผลกระทบ เวอร์ชันที่ได้รับผลกระทบ และผลกระทบที่สังเกตได้จากข้อผิดพลาดจากนั้นจึงสามารถเพิ่มรายละเอียดได้ แต่ต้องมีจุดประสงค์หลักคือเพื่อให้ผู้อ่านสามารถอ่านได้อย่างรวดเร็วและตัดสินใจได้ว่าปัญหาดังกล่าวเป็นเรื่องสำคัญหรือเป็นเพียงปัญหาเล็กน้อย
อีกแง่มุมที่สำคัญคือวิธีการอธิบายผลกระทบ นักพัฒนาเคอร์เนลเตือนว่ารายงานที่สร้างโดย AI จำนวนมาก... พวกเขามักจะกล่าวเกินจริงเกี่ยวกับผลลัพธ์ทางทฤษฎีการเชื่อมโยงสถานการณ์สมมติที่ไม่สอดคล้องกับแบบจำลองภัยคุกคามที่แท้จริงของโครงการ แทนที่จะสร้างเรื่องราวการโจมตีที่ซับซ้อน ผู้เข้าร่วมจะถูกขอให้ยึดติดกับข้อเท็จจริงที่ตรวจสอบได้ เช่น การอธิบายอย่างเป็นรูปธรรมว่าผู้ใช้จะได้รับความสามารถเพิ่มเติมอะไรบ้างในระบบที่กำหนดค่าตามมาตรฐาน
คู่มือดังกล่าวถึงกับแนะนำว่า หากเป็นไปได้ เครื่องมือ AI ควรจะอ่านเอกสารแบบจำลองภัยคุกคามของ Linux ล่วงหน้าด้วยซ้ำ เพื่อให้ข้อสรุปสอดคล้องกับเกณฑ์ที่โครงการได้กำหนดไว้แล้วเป้าหมายคือการลดความเข้าใจผิดและป้องกันไม่ให้ระบบรายงานอัตโนมัติเปลี่ยนข้อผิดพลาดที่มีผลกระทบจำกัดให้กลายเป็นช่องโหว่ร้ายแรงโดยไม่มีหลักฐานที่แท้จริง
ผู้เล่น แพทช์ และสามัญสำนึกในยุคแห่งระบบอัตโนมัติ
นอกเหนือจากวิธีการอธิบายความล้มเหลวแล้ว เอกสารฉบับนี้ยังเน้นถึงแง่มุมที่เป็นประโยชน์ในทางปฏิบัติอีกด้วย: การสร้างและการตรวจสอบความถูกต้องของผู้เล่นและแพทช์โดยใช้ AIเครื่องมือสมัยใหม่หลายอย่างสามารถสร้างโปรแกรมทดสอบหรือสคริปต์ขนาดเล็กที่ทำให้เกิดข้อผิดพลาด รวมถึงแนะนำการเปลี่ยนแปลงโค้ดเพื่อแก้ไขข้อผิดพลาดได้ แต่ก็ไม่ได้แม่นยำเสมอไป
ระบบหลักกำหนดว่า ก่อนที่จะส่งรายงานนั้น... นักวิจัยต้องตรวจสอบด้วยตนเองว่าเครื่องเล่นทำงานได้ตามที่อธิบายไว้หรือไม่หากลำดับขั้นตอนไม่ก่อให้เกิดความล้มเหลว หรือหาก AI ไม่สามารถสร้างวิธีการที่ทำซ้ำได้ ความถูกต้องของรายงานก็จะลดลงอย่างมาก การเผยแพร่ผลการค้นพบโดยปราศจากการตรวจสอบนี้จะยิ่งทำให้เกิดความสับสนและเสียเวลาของผู้ดูแลระบบเท่านั้น
ในส่วนของแพทช์นั้น ข้อความระบุว่า AI หลายตัวทำงานได้ดีขึ้นกว่าเดิมด้วยซ้ำ การเขียนโค้ดที่ประเมินผลกระทบของมันดังนั้น ผู้ใช้เครื่องมือเหล่านี้จึงควรสอบถามเครื่องมือเหล่านี้ไม่เพียงแต่เพื่อระบุปัญหาเท่านั้น แต่ยังควรเสนอแนวทางแก้ไขด้วย อย่างไรก็ตาม เน้นย้ำว่าผลลัพธ์จะต้องได้รับการตรวจสอบและทดสอบด้วยตนเองก่อนที่จะส่งไปยังรายชื่อผู้รับอีเมลสำหรับการพัฒนา
คู่มือนี้มีความชัดเจนในกรณีที่ทดสอบแพทช์ไม่ได้เนื่องจากขึ้นอยู่กับ... ฮาร์ดแวร์แปลกใหม่ โปรโตคอลเครือข่ายที่แทบจะสูญพันธุ์ หรือการกำหนดค่าที่หายากอย่างยิ่งหากข้อบกพร่องปรากฏให้เห็นเฉพาะในสภาพแวดล้อมที่จำกัดจนไม่มีใครสามารถตรวจสอบได้ง่ายๆ ก็มีความเป็นไปได้สูงว่าข้อบกพร่องนั้นไม่ได้จัดอยู่ในประเภทช่องโหว่ด้านความปลอดภัยที่เกี่ยวข้อง และไม่ควรเสียเวลาของช่องทางการสื่อสารส่วนตัวในการตรวจสอบ
เมื่อเสนอวิธีแก้ไข โครงการจะเตือนผู้ใช้ว่าต้องปฏิบัติตามแนวทางการส่งแพตช์เคอร์เนลมาตรฐาน รวมถึงป้ายกำกับด้วย “แก้ไข:” ระบุถึง commit ที่ทำให้เกิดข้อผิดพลาดนั้นขอแนะนำให้ใช้สามัญสำนึกด้วยเช่นกัน: หากไฟล์ที่ได้รับผลกระทบไม่ได้เปลี่ยนแปลงมานานกว่าหนึ่งปีและได้รับการดูแลโดยบุคคลเพียงคนเดียว เราอาจกำลังเผชิญกับส่วนประกอบที่มีผู้ใช้งานจริงน้อยมาก เช่น ไดรเวอร์ฮาร์ดแวร์เก่าหรือระบบไฟล์ที่ล้าสมัย
ในกรณีเหล่านี้ คำแนะนำนั้นชัดเจน: หากปัญหาเล็กน้อย ตรวจจับได้ง่าย และไม่มีผลกระทบที่เห็นได้ชัดในสภาพแวดล้อมทั่วไป แนวทางที่เหมาะสมที่สุดคือการแก้ไขปัญหาโดยตรงผ่านรายการพัฒนาสาธารณะ และไม่ได้อยู่ในรายชื่อที่จัดสรรไว้สำหรับด้านความปลอดภัย ด้วยวิธีนี้ ทรัพยากรที่สำคัญที่สุดจึงถูกสงวนไว้สำหรับเหตุการณ์ที่มีผลกระทบร้ายแรงได้
จากยุคของการทดสอบแบบฟัซซิ่ง สู่ยุคแห่งปัญญาประดิษฐ์ที่เฟื่องฟู: บทเรียนสำหรับซอฟต์แวร์โอเพนซอร์ส
สถานการณ์ปัจจุบันค่อนข้างชวนให้นึกถึงยุคที่เครื่องมือฟัซซิ่งอย่าง Syzkaller เริ่มต้นขึ้น ส่งรายงานข้อผิดพลาดที่ตรวจพบจำนวนมากไปยังเคอร์เนลในลักษณะกึ่งอัตโนมัติในเวลานั้น ชุมชนต้องเรียนรู้ที่จะบูรณาการข้อมูลใหม่ๆ ที่ได้มาอย่างต่อเนื่องเข้ากับกระบวนการพัฒนาของตน โดยไม่ทำให้งานประจำวันหยุดชะงัก
สิ่งที่คล้ายกันนี้เกิดขึ้นกับปัญญาประดิษฐ์ แต่ในระดับที่แตกต่างกัน ในปัจจุบัน ไม่เพียงแต่การสร้างข้อมูลป้อนเข้าที่ก่อให้เกิดข้อผิดพลาดจะเป็นไปโดยอัตโนมัติเท่านั้น แต่ยังรวมถึง... รวมถึงการร่างรายงาน การวิเคราะห์โค้ดแบบคงที่ และการเสนอแก้ไขข้อบกพร่องวิธีนี้ช่วยเร่งการค้นหาข้อบกพร่อง แต่ถ้าหากไม่ได้กรองและจัดลำดับความสำคัญอย่างเหมาะสม ก็จะทำให้จำนวนอีเมล การสนทนาคู่ขนาน และความคาดหวังเกี่ยวกับสิ่งที่ทีมพัฒนาเคอร์เนลสามารถรับมือได้เพิ่มขึ้นเป็นทวีคูณ
ภายในระบบนิเวศของลินุกซ์เอง ก็มีรายละเอียดปลีกย่อยในการประเมินปรากฏการณ์นี้ เกร็ก โครห์-ฮาร์ทแมน ผู้ดูแลเคอร์เนลคนสำคัญอีกคนหนึ่ง ได้ชี้ให้เห็นว่า รายงานที่สร้างโดย AI ได้พัฒนาอย่างรวดเร็วจากที่แทบจะไร้สาระกลายเป็นข้อมูลที่มีคุณค่าและเป็นประโยชน์มุมมองในแง่ดีนี้สอดคล้องกับความกังวลของทอร์วัลด์เกี่ยวกับการมีข้อมูลซ้ำซ้อนมากเกินไปและการโอเวอร์โหลดของรายการความปลอดภัย
แทนที่จะเป็นความขัดแย้ง ตำแหน่งเหล่านี้สะท้อนให้เห็นถึง... สองด้านของกระบวนการรับเลี้ยงบุตรบุญธรรมเดียวกันในด้านหนึ่ง AI มีประโยชน์อย่างมากในการค้นหาปัญหาที่แท้จริง ในอีกด้านหนึ่ง หากหลายคนใช้เครื่องมือเดียวกันกับโค้ดเดียวกันและส่งผลลัพธ์โดยไม่กรอง ผลรวมที่ได้จะเป็น "พายุ" ของการแจ้งเตือนที่ยากต่อการจัดการ
ตัวอย่างของการใช้ระบบอัตโนมัติอย่างมีความรับผิดชอบนั้นมาจากตัวของ Kroah-Hartman เอง ซึ่งได้เผยแพร่ระบบที่กำหนดเองสำหรับการสแกนเคอร์เนล การสร้างแพตช์ การทดสอบ และการส่งแพตช์ตามขั้นตอนการทำงานมาตรฐานของโครงการ ประเด็นสำคัญคือ ในกรณีเหล่านี้ ผู้พัฒนาเป็นผู้รับผิดชอบด้านเทคนิคทั้งหมดตลอดวงจรชีวิตของโครงการแทนที่จะส่งต่อโดยไม่ตรวจสอบว่าเครื่องมือดังกล่าวสร้างอะไรขึ้นมา
กระแสความเคลื่อนไหวทั้งหมดที่เกี่ยวข้องกับ Linux 7.1 แสดงให้เห็นว่าโครงการนี้ไม่ได้ปฏิเสธปัญญาประดิษฐ์แต่อย่างใด แต่กลับกำลัง... ปรับกระบวนการทำงานเพื่อให้ระบบอัตโนมัติทำงานเพื่อส่งเสริมความปลอดภัย ไม่ใช่เป็นอุปสรรคต่อความปลอดภัยด้วยการกำหนดเกณฑ์ที่เข้มงวดมากขึ้นสำหรับสิ่งที่ถือว่าเป็นช่องโหว่ กำหนดให้ต้องมีรายงานข้อความธรรมดาที่ตรวจสอบได้ และส่งเสริมให้ AI มีส่วนร่วมในการสร้างและทดสอบแพตช์ เคอร์เนลนี้จึงมุ่งหวังที่จะปกป้องเวลาของผู้ดูแลระบบ ลดสิ่งรบกวน และมุ่งเน้นความพยายามไปที่ข้อบกพร่องที่อาจส่งผลกระทบต่อระบบการผลิตได้จริง