ความปลอดภัยทางไซเบอร์ในโค้ดที่สร้างโดยปัญญาประดิษฐ์

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

ความปลอดภัยทางไซเบอร์และโค้ดที่สร้างโดยปัญญาประดิษฐ์

La การเขียนโปรแกรมโดยใช้ปัญญาประดิษฐ์ช่วย สิ่งนี้ไม่ได้เป็นเพียงคำสัญญาในอนาคตอีกต่อไป แต่ได้กลายเป็นความจริงในชีวิตประจำวันของทีมพัฒนาหลายพันทีมแล้ว ในเวลาเพียงไม่กี่วินาที ผู้ช่วย AI สามารถสร้างฟังก์ชัน สคริปต์ และแม้แต่แอปพลิเคชันทั้งหมดได้ ซึ่งไม่เพียงแต่เพิ่มประสิทธิภาพการทำงานเท่านั้น แต่ยังเพิ่มความเสี่ยงอีกด้วย

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

โค้ดที่สร้างโดย AI: ผลผลิตสูงสุดและช่องโหว่การโจมตีที่ควบคุมไม่ได้

ในเวลาอันสั้น เราได้ก้าวเข้าสู่สถานการณ์ที่... ปัจจุบันโค้ดที่ใช้ในการผลิตจำนวนมากมีต้นกำเนิดมาจากโมเดล AIผลการศึกษาชี้ให้เห็นว่า นักพัฒนาซอฟต์แวร์หนึ่งในสามยอมรับว่ากว่า 60% ของสิ่งที่พวกเขาเขียนนั้นมาจากผู้ช่วยอัจฉริยะ และบริษัทต่างๆ กำลังเห็นผลผลิตที่เพิ่มขึ้นอย่างน่าทึ่งแล้วด้วยสิ่งที่เรียกว่า "การเขียนโค้ดตามความรู้สึก" หรือการเขียนโปรแกรมตามคำสั่ง

อีกด้านหนึ่งของเหรียญนั้นก็คือ ประมาณครึ่งหนึ่งของโค้ดที่สร้างขึ้นโดยอัตโนมัติมีช่องโหว่ช่องโหว่เหล่านี้มีตั้งแต่การโจมตีแบบ SQL injection ไปจนถึงข้อผิดพลาดทางด้านการเข้ารหัส และการควบคุมการเข้าถึงที่ออกแบบมาไม่ดี ในบางภาษา เช่น Java พบว่าโค้ดที่ AI สร้างขึ้นมากกว่า 70% มีช่องโหว่ด้านความปลอดภัย

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

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

ความเสี่ยงเหล่านี้หลายอย่างทวีความรุนแรงขึ้นจากปัจจัยต่างๆ ดังนี้ การหลั่งไหลเข้ามาอย่างมหาศาลของ "นักพัฒนาซอฟต์แวร์ภาคประชาชน"พนักงานที่ไม่มีพื้นฐานด้านวิศวกรรมซอฟต์แวร์ที่แข็งแกร่งต้องพึ่งพา AI ในการสร้างระบบอัตโนมัติ แอปพลิเคชันภายในขนาดเล็ก หรือการเชื่อมต่อระบบต่างๆ โค้ดที่ได้นั้นใช้งานได้จริง แต่บ่อยครั้งที่ขาดการรับประกันขั้นพื้นฐานด้านความปลอดภัยและคุณภาพ

ความเสี่ยงด้านความปลอดภัยหลักในโค้ดที่สร้างโดย AI

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

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

สิ่งที่น่าเป็นห่วงอีกประการหนึ่งคือ Ataques a la cadena de suministro เดอซอฟต์แวร์โมเดล AI มักแนะนำไลบรารีของบุคคลที่สามเพื่อแก้ปัญหาทั่วไป หากไม่ได้ตรวจสอบและวิเคราะห์ไลบรารีเหล่านี้ด้วยเครื่องมือวิเคราะห์องค์ประกอบซอฟต์แวร์ (SCA) ก็อาจเปิดช่องให้มีการแทรกไลบรารีที่เป็นอันตรายหรือเวอร์ชันที่ถูกบุกรุกเข้าไปในโปรเจกต์นับพันได้ด้วยการกระทำเพียงครั้งเดียว

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

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

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

เราต้องไม่ลืมต้นตอของปัญหา: การออกแบบที่คำนึงถึงความปลอดภัยยังคงขาดหายไปเป็นส่วนใหญ่นักพัฒนาส่วนใหญ่ยอมรับว่าใช้เวลาแก้ไขบั๊กมากกว่าการคำนึงถึงข้อกำหนดด้านความปลอดภัยตั้งแต่ขั้นตอนการออกแบบ ในสภาพแวดล้อมที่ความเร็วในการส่งมอบเป็นสิ่งสำคัญยิ่ง แรงกดดันทางธุรกิจผลักดันให้นักพัฒนา "ปล่อยฟังก์ชันการทำงานออกมาเดี๋ยวนี้" และปล่อยเรื่องความปลอดภัยไว้ทีหลัง...หากเวลานั้นจะมาถึง

วิสัยทัศน์ของ CISOs สถาปนิก และผู้เชี่ยวชาญ: ยอมรับ AI แต่ต้องควบคุมได้

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

สิ่งที่พวกเขากำลังพิจารณาอยู่คือ วิธีลดความเสี่ยงโดยไม่ปิดกั้นนวัตกรรมหลายองค์กรกำลังส่งเสริมกลยุทธ์การพัฒนาที่ปลอดภัยโดยอิงตามแนวทาง "shift left": คือการนำการทดสอบความปลอดภัย การวิเคราะห์ SAST และการตรวจสอบความสัมพันธ์ของส่วนประกอบต่างๆ มาใช้ในขั้นตอนแรกสุดของวงจรชีวิตซอฟต์แวร์ ตั้งแต่ตอนที่นักพัฒนาหรือ AI กำลังเขียนโค้ดบรรทัดแรกๆ

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

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

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

ในบริษัทที่มีซอฟต์แวร์เก่าจำนวนมาก จุดสนใจจะอยู่ที่... ควบคุมช่องโหว่ที่ปรากฏในไลบรารีของบุคคลที่สาม และในระบบเก่าที่ไม่มีใครกล้าแตะต้อง ในส่วนนี้ เครื่องมือวิเคราะห์อัตโนมัติและเอเจนต์ AI ที่เชี่ยวชาญด้านความปลอดภัยเริ่มเข้ามาช่วยในการระบุความเสี่ยงและจัดลำดับความสำคัญว่าอะไรควรได้รับการแก้ไขก่อน

ปัญญาประดิษฐ์ในฐานะพันธมิตรด้านการป้องกัน: การตรวจจับ การจัดลำดับความสำคัญ และการตอบสนอง

เทคโนโลยีเดียวกันที่ทำให้การเขียนโค้ดที่ไม่ปลอดภัยง่ายขึ้น ก็กำลังเปลี่ยนแปลงวิธีการป้องกันการโจมตีเหล่านั้นอย่างสิ้นเชิงเช่นกัน ในศูนย์ปฏิบัติการด้านความปลอดภัย (SOC) แพลตฟอร์ม SIEM และเครื่องมือวิเคราะห์โค้ด ปัญญาประดิษฐ์เชิงสร้างสรรค์และโมเดลการเรียนรู้เชิงลึกกำลังกลายเป็นองค์ประกอบสำคัญ.

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

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

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

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

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

มัลแวร์และปัญญาประดิษฐ์: กระแสความนิยม ข้อจำกัดในปัจจุบัน และวิวัฒนาการที่เป็นไปได้

ควบคู่ไปกับการพัฒนาของ AI ด้านการป้องกันประเทศ เทคโนโลยีอื่นๆ ก็ได้เกิดขึ้นมาเช่นกัน ต้นแบบมัลแวร์ที่ผสานรวมโมเดลภาษา หรือใช้ประโยชน์จากบริการ AI เพื่อเปลี่ยนแปลงแบบไดนามิก การทดลองต่างๆ เช่น BlackMamba, EyeSpy หรือเวิร์ม Morris II ได้แสดงให้เห็นว่าในทางเทคนิคแล้วสามารถใช้ LLM เพื่อสร้างโค้ดที่เป็นอันตรายในระหว่างการทำงาน ประเมินเป้าหมาย หรือแพร่กระจายการโจมตีผ่านคำสั่งที่ฉีดเข้าไปได้

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

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

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

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

การรับประกันวงจรชีวิตของ AI ที่สมบูรณ์แบบ: ข้อมูล โมเดล และไปป์ไลน์

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

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

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

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

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

กรอบงาน SHIELD: การกำหนดขอบเขตที่ชัดเจนสำหรับการเขียนโปรแกรมโดยใช้ AI ช่วย

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

ตัวอักษร "S" ใน SHIELD หมายถึง การแบ่งแยกหน้าที่เป้าหมายคือการป้องกันไม่ให้เอเจนต์ AI มีสิทธิ์การใช้งานที่หลากหลายจนส่งผลกระทบต่อสภาพแวดล้อมการใช้งานจริง แนวทางที่เหมาะสมคือการจำกัดขอบเขตการใช้งานไว้เฉพาะการพัฒนาและการทดสอบ โดยไม่มีสิทธิ์การเข้าถึงระดับสูงหรือการเข้าถึงฐานข้อมูลจริงโดยตรง

ตัวอักษร “H” สอดคล้องกับ มนุษย์ในวงจรนี่หมายความว่าโค้ดที่สร้างโดย AI จะต้องได้รับการตรวจสอบและอนุมัติโดยบุคลากรที่มีคุณสมบัติเหมาะสมเสมอ โดยเฉพาะอย่างยิ่งเมื่อใช้งานโดยนักพัฒนาที่ไม่ใช่มืออาชีพ การเปลี่ยนแปลงที่สำคัญใดๆ ไม่ควรถูกรวมเข้าด้วยกันโดยปราศจากคำขอรวมโค้ด (pull request) ที่ได้รับการดูแล

ตัวอักษร “I” ชี้ไปที่ การตรวจสอบความถูกต้องของข้อมูลเข้าและข้อมูลออกจำเป็นต้องแยกคำสั่งที่เชื่อถือได้ออกจากข้อมูลที่ไม่น่าเชื่อถืออย่างชัดเจน ตรวจสอบความถูกต้องของข้อความแจ้งเตือน ควบคุมสิ่งที่ถามจากโมเดล และส่งผลลัพธ์ไปยังเครื่องมือต่างๆ เช่น SAST ก่อนที่จะนำไปรวมเข้ากับโค้ดเบส

ตัวอักษร “E” เน้นที่ โมเดลเสริมที่เน้นความปลอดภัยแทนที่จะพึ่งพาตัวช่วยอเนกประสงค์เพียงตัวเดียว ควรเสริมด้วยเครื่องมือเฉพาะทางสำหรับการสแกนความลับ การตรวจสอบการควบคุม SCA การตรวจจับการพึ่งพาที่มองไม่เห็น และการตรวจสอบการกำหนดค่าโครงสร้างพื้นฐานในรูปแบบโค้ด

ตัวอักษร “L” หมายถึง หลักการ “ตัวแทนน้อยที่สุด” หรือตัวแทนขั้นต่ำเอージェนต์ AI ควรทำงานโดยมีสิทธิ์การเข้าถึงน้อยที่สุดเท่าที่จะเป็นไปได้: ห้ามเข้าถึงไฟล์ที่ละเอียดอ่อน จำกัดคำสั่งที่อาจก่อให้เกิดความเสียหายอย่างเข้มงวด และห้ามทำการเปลี่ยนแปลงใดๆ ในสภาพแวดล้อมที่สำคัญโดยอัตโนมัติ

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

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

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

บทความที่เกี่ยวข้อง:
ฟรีระบบปฏิบัติการ 10 อย่าง ที่คุณไม่รู้แน่นอน!