ทำไมโค้ดที่สร้างโดย AI จึงทำลายโมเดลการจัดการความเสี่ยงของคุณ

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

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

ปัญหาในการพึ่งพาเป็นปัญหา AI

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

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

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

การสแกนหลังเหตุการณ์ไม่ใช่กลยุทธ์

โมเดลที่ครอบงำสำหรับความปลอดภัยของซอฟต์แวร์โอเพ่นซอร์สคือการสแกนและแก้ไข: รันเครื่องสแกน ตรวจสอบผลลัพธ์ อนุมัติ 티켓 และรอ โมเดลนี้มักจะตอบสนอง และใน môi trườngการพัฒนาที่เร่งด้วย AI มันถูกทิ้งไว้ข้างหลัง

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

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

การเปลี่ยนแปลงที่ทำงานจริงๆ: ควบคุมสิ่งที่เข้ามา

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

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

สิ่งนี้ดูเหมือนในทางปฏิบัติ

สำหรับผู้นำด้านความปลอดภัยที่ทำงานผ่านสิ่งนี้ สิ่งสำคัญคือ:

1. กำหนดชุดส่วนประกอบที่ได้รับการอนุมัติก่อนที่จะขยายการนำ AI มาใช้ หากเครื่องมือ AI ของคุณแก้ไขการพึ่งพาจากทะเบียนสาธารณะ กระบวนการอนุมัติของคุณมีเพียงบนกระดาษเท่านั้น ตั้งค่าทะเบียนภายในที่ถูกดูแลอย่างรอบคอบ ส่งทุกอย่างผ่านมัน และต้องการให้ส่วนประกอบถูกสร้างจากแหล่งที่มาโดยมีประวัติที่ตรวจสอบได้
2. รักษาการแก้ไขเป็นกระบวนการที่จัดการ ไม่ใช่คิวที่ต้องทำ องค์กรที่อยู่เหนือหนี้ความเสี่ยงไม่ได้เคลื่อนที่เร็วขึ้นในการแก้ไขด้วยตนเอง พวกเขาได้ลบการแก้ไขด้วยตนเองออกจากสมการ เมื่อมีการแก้ไขจากชุมชนอยู่ การแก้ไขจะถูกสร้างใหม่ในแค็ตตาล็อกโดยอัตโนมัติ นักพัฒนาจะได้รับการอัปเดตครั้งต่อไปที่พวกเขาใช้ ไม่มีการจัดสรรตั๋ว ไม่มีการรอ 60 วัน
3. แมปเครื่องมือ AI ของคุณกับภาระผูกพันทางความสอดคล้องก่อนที่คุณจะถูกบังคับให้ทำ ฉันเคยเห็นทีมสร้างบนเครื่องมือ AI เป็นเวลาหลายเดือน เพียงเพื่อพบกับกำแพงเมื่อลูกค้าต้องการความสอดคล้องกับ FedRAMP หรือหลักฐาน SOC 2 แค็ตตาล็อกที่ดูแลอย่างรอบคอบของคุณยังเป็นหลักฐานการตรวจสอบความสอดคล้องของคุณ SBOM และบันทึกย้อนกลับควรส่งมอบพร้อมกับส่วนประกอบทุกชิ้น ไม่ใช่รวมกันภายใต้แรงกดดันของเส้นตาย
4. กำหนดความเป็นเจ้าของที่ชัดเจนที่ระดับการกำกับดูแล ไม่ใช่ระดับตั๋ว ทีมที่เคลื่อนที่เร็วที่สุดในการแก้ไขไม่ใช่ทีมที่มีนักพัฒนามากที่สุด พวกเขาเป็นทีมที่ทีมความปลอดภัยเป็นเจ้าของนโยบาย ทีมแพลตฟอร์มเป็นเจ้าของการนำส่ง และไม่มีทีมใดรอการดำเนินการของทีมอื่น

ความปลอดภัยที่ช่วยให้สามารถทำได้มากกว่าการปิดกั้น

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

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