ซอฟต์แวร์โอเพนซอร์สได้กลายเป็นรากฐานของการพัฒนาซอฟต์แวร์สมัยใหม่ แอปพลิเคชันในปัจจุบันเกือบทุกตัวต้องพึ่งพาเครือข่ายที่ซับซ้อนของไลบรารี เฟรมเวิร์ก โมเดล และเครื่องมือสร้างซอฟต์แวร์จากภายนอก ความจริงข้อนี้เพียงอย่างเดียวก็ก่อให้เกิดปัญหาสำคัญมากมายแล้ว software supply chain security ความท้าทาย ในขณะเดียวกัน ปัญญาประดิษฐ์ก็ได้เข้ามามีบทบาทแล้ว วงจรชีวิตการพัฒนาซอฟต์แวร์ ในฐานะตัวเร่งความเร็วที่มีประสิทธิภาพ สามารถสร้างโค้ด แนะนำการพึ่งพา แก้ไขปัญหาโดยอัตโนมัติ และแม้กระทั่งมีอิทธิพลต่อการออกแบบสถาปัตยกรรมcisไอออน ซอฟต์แวร์โอเพนซอร์สและปัญญาประดิษฐ์ (AI) ร่วมกันเปลี่ยนแปลงวิธีการสร้างซอฟต์แวร์ และหลีกเลี่ยงไม่ได้ที่จะเปลี่ยนแปลงวิธีการโจมตีซอฟต์แวร์ด้วย จุดตัดระหว่างความปลอดภัยของ AI, AI และความปลอดภัยของซอฟต์แวร์ และ software supply chain security เรื่องนี้ไม่ใช่เรื่องทางทฤษฎีอีกต่อไปแล้ว แต่เป็นหนึ่งในแหล่งที่มาหลักของความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์ที่องค์กรด้านวิศวกรรมต้องเผชิญ
ความเป็นจริงดังกล่าวเป็นกรอบในการจัดงาน SafeDev Talk ครั้งล่าสุดของเรา: โอเพนซอร์ส ปัญญาประดิษฐ์ และช่องทางการโจมตีรูปแบบใหม่: โค้ดที่ใช้เป็นอาวุธ และระบบป้องกันที่ชาญฉลาดกว่าเดิมโดยมีผู้นำด้านความปลอดภัยจาก Red Hat, TikTok และ Xygeni เข้าร่วม การสนทนามุ่งเน้นไปที่สิ่งที่ทีมรักษาความปลอดภัยและทีมวิศวกรรมกำลังเผชิญอยู่ในสภาพแวดล้อมการใช้งานจริง โดยเฉพาะอย่างยิ่งเกี่ยวกับการโจมตีห่วงโซ่อุปทานโอเพนซอร์ส แพ็กเกจโอเพนซอร์สที่เป็นอันตราย และความตึงเครียดที่เพิ่มขึ้นระหว่างความเร็วและการควบคุมในการพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วย AI สิ่งที่ปรากฏออกมาคือภาพที่ชัดเจน: พื้นที่การโจมตีขยายตัวเร็วกว่าที่แบบจำลองความปลอดภัยแบบดั้งเดิมจะรับมือได้ทัน และ AI ทำหน้าที่ทั้งเป็นตัวเร่งปฏิกรรมและเป็นบททดสอบความกดดันสำหรับสมมติฐานที่มีมายาวนานในด้านความปลอดภัยของ AI software supply chain security.
หากคำอธิบายนี้ฟังดูคล้ายกับวิธีการที่องค์กรของคุณสร้างซอฟต์แวร์ในปัจจุบันอย่างน่าตกใจ นั่นไม่ใช่เรื่องบังเอิญ หลายทีมเพิ่งตระหนักว่าความไว้วางใจได้เปลี่ยนไปอยู่กับระบบอัตโนมัติมากแค่ไหนหลังจากที่เกิดปัญหาขึ้น
ความปลอดภัยของ AI และ Software Supply Chain Security ปัญหายังคงเหมือนเดิม
ประเด็นสำคัญที่เกิดขึ้นซ้ำๆ ตลอดการสนทนาคือ ความปลอดภัยของ AI ไม่สามารถถูกมองว่าเป็นศาสตร์ที่แยกต่างหากจากด้านอื่นๆ ได้อีกต่อไป software supply chain securityระบบ AI ไม่ได้ทำงานอย่างโดดเดี่ยว แต่ถูกสร้าง ฝึกฝน ใช้งาน และบูรณาการผ่านกระบวนการเดียวกัน pipelineระบบต่างๆ ที่มีการพึ่งพาและลงทะเบียนไว้แล้ว ซึ่งต่างก็ประสบปัญหาจากการโจมตีห่วงโซ่อุปทานโอเพนซอร์สอยู่แล้ว
ในการพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วย AI โมเดลจะแนะนำโค้ด สร้างวิธีแก้ไข และเลือกส่วนประกอบที่จำเป็นโดยอัตโนมัติ กระบวนการเหล่านี้cisไอออนส่งผลโดยตรง การจัดการการพึ่งพาแบบโอเพนซอร์สโดยส่วนใหญ่มักเกิดขึ้นโดยปราศจากเจตนาของมนุษย์อย่างชัดเจน ส่งผลให้ความเสี่ยงจากการพึ่งพาไม่ได้ขึ้นอยู่กับการเลือกของนักพัฒนาเพียงอย่างเดียวอีกต่อไป แต่ได้รับอิทธิพลจากพฤติกรรมของ AI มากขึ้นเรื่อยๆ
การบรรจบกันนี้หมายความว่า ความล้มเหลวในด้านปัญญาประดิษฐ์และความปลอดภัยของซอฟต์แวร์ มักปรากฏออกมาในรูปแบบของเหตุการณ์ในห่วงโซ่อุปทานแบบดั้งเดิม เช่น การพึ่งพาที่ถูกบุกรุก ไฟล์การสร้างที่ปนเปื้อน หรือช่องโหว่ CI/CD กระบวนการต่างๆ เครื่องมืออาจจะใหม่ แต่ความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์นั้นเป็นเรื่องจริงและยากที่จะคาดเดาได้มากขึ้นเรื่อยๆ
หากแบบจำลองภัยคุกคามของคุณยังคงแยก “ความเสี่ยงจาก AI” ออกจาก “ความเสี่ยงจากห่วงโซ่อุปทาน” อาจคุ้มค่าที่จะทบทวนว่าขอบเขตนั้นอยู่ที่ใดในขั้นตอนการสร้างและใช้งานของคุณ
การโจมตีห่วงโซ่อุปทานแบบโอเพนซอร์สด้วยความเร็วระดับเครื่องจักร
การโจมตีห่วงโซ่อุปทานแบบโอเพนซอร์สไม่ใช่เรื่องใหม่ แต่ AI เปลี่ยนแปลงเศรษฐศาสตร์ของการโจมตีเหล่านั้น ผู้โจมตีไม่จำเป็นต้องใช้เทคนิคใหม่ ๆ พวกเขาต้องการขนาดที่ใหญ่ขึ้น AI ช่วยให้สามารถวิเคราะห์ระบบนิเวศได้อย่างรวดเร็ว ค้นพบจุดอ่อนของความสัมพันธ์โดยอัตโนมัติ และพัฒนาเพย์โหลดการโจมตีได้อย่างรวดเร็ว
จากมุมมองเชิงรุก การพัฒนาเทคโนโลยีการสอดแนมในระดับอุตสาหกรรมนี้ช่วยเพิ่มอัตราความสำเร็จของการโจมตีที่เกี่ยวข้องกับแพ็กเกจโอเพนซอร์สที่เป็นอันตรายอย่างมาก ส่วนประกอบต่างๆ ที่ก่อนหน้านี้อาจไม่ถูกตรวจพบ ตอนนี้สามารถถูกค้นพบ วิเคราะห์ และใช้ประโยชน์ได้อย่างรวดเร็ว บ่อยครั้งก่อนที่ฝ่ายป้องกันจะรู้ตัวว่ามีการใช้งานอยู่
นี่คือเหตุผลที่ software supply chain security ไม่สามารถพึ่งพาสัญญาณที่ล่าช้าเพียงอย่างเดียวได้ การลงทะเบียน คำแนะนำ และการเปิดเผยข้อมูลภายหลังนั้นดำเนินการตามกรอบเวลาของมนุษย์ ในขณะที่ผู้โจมตีดำเนินการด้วยความเร็วของเครื่องจักรมากขึ้นเรื่อยๆ ช่วงเวลาการเปิดเผยข้อมูลที่เกิดขึ้นนี้จึงเป็นปัจจัยโดยตรงที่ทำให้ความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์เพิ่มสูงขึ้น
หากสัญญาณการตรวจจับหลักของคุณคือ “รีจิสทรีได้ลบแพ็กเกจแล้ว” แสดงว่าคุณกำลังดำเนินการตามหลังไทม์ไลน์ของผู้โจมตีแล้ว
ต้องการศึกษาเจาะลึกเกี่ยวกับการโจมตีห่วงโซ่อุปทานซอฟต์แวร์โอเพนซอร์สหรือไม่?
ความเสี่ยงด้านการพึ่งพาในซอฟต์แวร์ที่ขับเคลื่อนด้วย AI
หนึ่งในความเสี่ยงที่ชัดเจนที่สุดที่ถูกกล่าวถึงในงาน SafeDev Talk คือความเสี่ยงด้านการพึ่งพา โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมที่พึ่งพาการพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วย AI อย่างมาก ผู้ช่วยเขียนโค้ด AI นั้นถูกออกแบบมาเพื่อความสะดวกและรวดเร็ว ไม่ใช่เพื่อลดพื้นที่การโจมตีให้เหลือน้อยที่สุด
ในทางปฏิบัติ สิ่งนี้ส่งผลให้เกิดการเพิ่มการพึ่งพาไลบรารีอย่างรวดเร็ว มีการเพิ่มไลบรารีใหม่แทนที่จะนำฟังก์ชันการทำงานที่มีอยู่มาใช้ซ้ำ การพึ่งพาแบบส่งต่อ ขยายตัวอย่างเงียบๆ และเป็นโอเพนซอร์ส การจัดการการพึ่งพา กลายเป็นการตอบสนองต่อสถานการณ์มากกว่าการวางแผนอย่างตั้งใจ เมื่อเวลาผ่านไป ทีมงานจะสูญเสียความสามารถในการใช้เหตุผลเกี่ยวกับสิ่งที่พวกเขากำลังดำเนินการอยู่จริง ๆ
นี่ไม่ใช่แค่ปัญหาด้านสุขอนามัยเท่านั้น การพึ่งพาซอฟต์แวร์ใหม่แต่ละครั้งจะเพิ่มความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์ สร้างข้อสมมติฐานด้านความไว้วางใจใหม่ และเปิดโอกาสใหม่สำหรับการโจมตีห่วงโซ่อุปทานโอเพนซอร์ส เมื่อการพึ่งพาซอฟต์แวร์ลดลงcisกระบวนการต่างๆ ถูกทำให้เป็นระบบอัตโนมัติและตรวจสอบอย่างผิวเผิน ความเสี่ยงในการติดยาจึงกลายเป็นเรื่องของระบบมากกว่าที่จะเป็นเรื่องบังเอิญ
หากแผนผังความสัมพันธ์ของข้อมูลเติบโตเร็วกว่าความสามารถของทีมในการอธิบาย นี่ไม่ใช่ปัญหาของเครื่องมือ แต่เป็นปัญหาเรื่องความไว้วางใจ
ผู้ช่วยเขียนโค้ด AI, ความปลอดภัย และการล่มสลายของการตรวจสอบ
อีกหนึ่งรูปแบบความล้มเหลวที่ถูกกล่าวถึงคือ การลดลงของการตรวจสอบโดยผู้ทรงคุณวุฒิเมื่อมีโค้ดที่สร้างโดย AI เข้ามาเกี่ยวข้อง ความปลอดภัยของผู้ช่วยเขียนโค้ด AI ไม่ได้หมายถึงแค่การแทรกโค้ดโดยทันทีหรือการใช้โมเดลในทางที่ผิดเท่านั้น แต่ยังหมายถึงปริมาณตรรกะที่ไม่ได้รับการตรวจสอบที่เข้าสู่ระบบการผลิตด้วย
การเปลี่ยนแปลงที่สร้างโดย AI มักมีขนาดใหญ่ สอดคล้องกัน และตรวจสอบได้ยากภายใต้แรงกดดันด้านเวลา ส่งผลให้การตรวจสอบโดยผู้เชี่ยวชาญกลายเป็นเรื่องผิวเผินหรือเป็นเพียงสัญลักษณ์ การล่มสลายอย่างเงียบๆ นี้ได้ทำลายหนึ่งในกลไกควบคุมที่มีประสิทธิภาพที่สุด software supply chain security.
ปัญหาไม่ได้อยู่ที่ความประมาทของนักพัฒนา แต่อยู่ที่ความไม่สอดคล้องกันของขั้นตอนการทำงาน เมื่อความเร็วได้รับการยกย่องและความยุ่งยากถูกลงโทษ ปัญญาประดิษฐ์และระบบควบคุมความปลอดภัยของซอฟต์แวร์ที่ต้องอาศัยความใส่ใจของมนุษย์ย่อมอ่อนแอลงอย่างหลีกเลี่ยงไม่ได้ ผู้โจมตีไม่จำเป็นต้องหลีกเลี่ยงการตรวจสอบหากการตรวจสอบไม่สามารถทำหน้าที่เป็นกำแพงกั้นได้อีกต่อไป
หลายทีมคิดว่าการตรวจสอบยังคงได้ผลเพราะกระบวนการนั้นมีอยู่แล้ว แต่มีน้อยทีมที่ตั้งคำถามว่ามันยังคงทำหน้าที่เป็นกลไกควบคุมที่มีความหมายอยู่หรือไม่
แพ็กเกจโอเพนซอร์สที่เป็นอันตรายและความเชื่อผิดๆ เกี่ยวกับความนิยม
ความเชื่อทั่วไปในการจัดการการพึ่งพาของซอฟต์แวร์โอเพนซอร์สคือ โครงการยอดนิยมมีความปลอดภัยกว่า แต่ในความเป็นจริง ความนิยมมักจะเพิ่มความเสี่ยง ไลบรารีที่ใช้งานกันอย่างแพร่หลายจึงเป็นเป้าหมายที่มีมูลค่าสูงสำหรับภัยคุกคาม การโจมตีห่วงโซ่อุปทานแบบโอเพนซอร์ส, สำหรับcisเพราะการประนีประนอมจะส่งผลกระทบในวงกว้างต่อผู้ที่เกี่ยวข้อง
โครงการยอดนิยมหลายโครงการได้รับการดูแลโดยทีมงานขนาดเล็กหรือบุคคลเพียงคนเดียว แม้ว่าจะตรวจพบปัญหาแล้วก็ตาม แพ็กเกจโอเพนซอร์สที่เป็นอันตรายมักจะยังคงใช้งานได้เป็นเวลาหลายชั่วโมงหรือหลายวันก่อนที่จะถูกลบออก ในระหว่างนั้น องค์กรต่างๆ ก็ยังคงนำแพ็กเกจเหล่านั้นไปใช้ผ่านการสร้างอัตโนมัติ
ความล่าช้านี้ตอกย้ำความจำเป็นในการดำเนินการเชิงรุก software supply chain security การควบคุม การพึ่งพาความนิยม ชื่อเสียง หรือการดำเนินการตามทะเบียนเพียงอย่างเดียวไม่เพียงพอเมื่อเผชิญกับความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์สมัยใหม่
คำว่า “ใช้กันอย่างแพร่หลาย” ไม่ได้มีความหมายเหมือนกับคำว่า “มีการป้องกันอย่างแข็งขัน” และการเข้าใจผิดเช่นนั้นเป็นหนึ่งในความเข้าใจผิดที่พบได้บ่อยที่สุดในห่วงโซ่อุปทาน
ที่มาของข้อมูลในห่วงโซ่อุปทานซอฟต์แวร์และความปลอดภัยของ AI
ตลอดการสนทนา ประเด็นความจำเป็นในการตรวจสอบแหล่งที่มาในห่วงโซ่อุปทานซอฟต์แวร์ปรากฏขึ้นซ้ำแล้วซ้ำเล่า ในสภาพแวดล้อมที่ใช้ AI ช่วยเหลือ การระบุแหล่งที่มาอาจไม่ชัดเจน โค้ดอาจถูกสร้างขึ้นโดยแบบจำลอง ถูกแก้ไขโดยมนุษย์ ถูกรวมเข้าด้วยกันโดยระบบอัตโนมัติ และถูกนำไปใช้งานโดยไม่มีความรับผิดชอบที่ชัดเจน
หากไม่มีหลักฐานที่มาที่ตรวจสอบได้ องค์กรต่างๆ ก็ต้องอาศัยความเชื่อมั่นในสิ่งประดิษฐ์เหล่านั้นโดยปริยาย ความปลอดภัยของ AI เรียกร้องให้เปลี่ยนจากการเชื่อถือไปสู่การตรวจสอบยืนยัน: สิ่งประดิษฐ์ที่ลงนามแล้ว build attestationsและมีแหล่งที่มาที่ตรวจสอบได้ แม้ว่าการระบุแหล่งที่มาจะไม่สามารถป้องกันพฤติกรรมที่เป็นอันตรายได้อย่างสิ้นเชิง แต่ก็ช่วยลดความคลุมเครือและจำกัดความสามารถในการหลบหลีกของผู้โจมตีได้อย่างมาก
หลักการนี้ใช้ได้กับทั้งโมเดล ข้อมูล และโค้ด ในการพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วย AI แหล่งที่มาของข้อมูลเป็นข้อกำหนดพื้นฐานสำหรับทั้ง AI และความปลอดภัยของซอฟต์แวร์
SBOM และความปลอดภัยของ AI ในยุคสมัยใหม่ Pipelines
บทบาทของ SBOM และความปลอดภัยของ AI ก็เป็นอีกประเด็นหนึ่งที่แฝงอยู่ SBOMs ช่วยให้มองเห็นภาพรวมของกราฟความสัมพันธ์ได้ชัดเจนยิ่งขึ้นแต่การมองเห็นเพียงอย่างเดียวไม่เพียงพอ ในสภาพแวดล้อมที่ใช้ AI อย่างหนัก SBOMระบบต้องพัฒนาเพื่อรองรับไม่เพียงแค่ไลบรารี แต่ยังรวมถึงโมเดล ขั้นตอนการสร้าง และการพัฒนาอัตโนมัติด้วยcisไอออน
เมื่อรวมกับ การวิเคราะห์พฤติกรรมและที่มา, SBOM และการรักษาความปลอดภัยด้วย AI กลายเป็นเครื่องมือที่มีประสิทธิภาพในการลดความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์ ช่วยให้องค์กรสามารถตรวจจับการเปลี่ยนแปลงที่ไม่คาดคิด วิเคราะห์ผลกระทบ และตอบสนองต่อการโจมตีห่วงโซ่อุปทานโอเพนซอร์สได้อย่างมีประสิทธิภาพมากขึ้น
CI/CD Pipeline Security ภายใต้แรงกดดันจากระบบอัตโนมัติ
ในที่สุด CI/CD pipeline security ปรากฏออกมาเป็นระนาบควบคุมที่สำคัญ Pipelineบุคคลจำนวนมากขึ้นเรื่อยๆ ดำเนินการตามคำแนะนำหรือคำสั่งของระบบ AI หากบุคคลเหล่านั้น pipelineหากขาดการควบคุมตัวตนที่เข้มแข็ง การตรวจสอบความถูกต้องของหลักฐาน และการบังคับใช้นโยบาย สถานที่เหล่านั้นจะกลายเป็นจุดเข้าโจมตีที่เหมาะสมอย่างยิ่งสำหรับผู้ไม่ประสงค์ดี
ไม่เพียงพอ CI/CD pipeline security อนุญาตให้แพ็กเกจโอเพนซอร์สที่เป็นอันตรายส่งผลกระทบไม่เพียงแต่ระบบการผลิตเท่านั้น แต่ยังรวมถึงสภาพแวดล้อมการพัฒนาและโครงสร้างพื้นฐานการสร้างด้วย เมื่อระบบอัตโนมัติเพิ่มมากขึ้น pipelineสินทรัพย์เหล่านี้ต้องได้รับการปฏิบัติเสมือนเป็นสินทรัพย์มูลค่าสูง software supply chain security โปรแกรม
รับชม SafeDev Talk
เพื่อรับฟังข้อมูลเชิงลึกเพิ่มเติมโดยตรงจากผู้เชี่ยวชาญที่กำลังกำหนดทิศทางในสาขานี้ โปรดชมวิดีโอฉบับเต็ม SafeDev Talk: โอเพนซอร์ส ปัญญาประดิษฐ์ และช่องทางการโจมตีรูปแบบใหม่: โค้ดที่ใช้เป็นอาวุธ และระบบป้องกันที่ชาญฉลาดกว่าเดิมจัดแต่งด้วย โรมัน ซูคอฟ (หมวกแดง), ลีออน จอห์นสัน (ติ๊กต็อก)และ หลุยส์ โรดริเกซ แบร์โซซ่า (ซิเจนี่).
ผลกระทบเชิงปฏิบัติสำหรับการรักษาความปลอดภัยของ AI และ Software Supply Chain Security
ผลกระทบในทางปฏิบัติของการเปลี่ยนแปลงเหล่านี้ไม่ได้จำกัดอยู่แค่เพียงเครื่องมือเท่านั้น องค์กรต่างๆ ต้องตระหนักว่าความปลอดภัยของ AI ความปลอดภัยของ AI และซอฟต์แวร์ และ software supply chain security ตอนนี้ทั้งสองสิ่งเกี่ยวพันกันอย่างลึกซึ้งแล้วcisกระบวนการที่เคยถูกมองว่ามีความเสี่ยงต่ำ เช่น การอัปเดตส่วนประกอบ การสร้างโค้ด และระบบอัตโนมัติ ปัจจุบันกลับมีความเสี่ยงด้านห่วงโซ่อุปทานซอฟต์แวร์อย่างมีนัยสำคัญ โดยเฉพาะอย่างยิ่งเมื่อกระบวนการเหล่านั้น...cisไอออนเกิดขึ้นโดยปริยายจากเครื่องมือ มากกว่าเกิดจากมนุษย์โดยตรง
ในระหว่างการบรรยาย SafeDev Talk ประเด็นนี้ได้รับการสรุปอย่างกระชับ โดยวิทยากรท่านหนึ่งกล่าวว่า เมื่อระบบ AI เข้ามามีส่วนร่วมในการพัฒนาซอฟต์แวร์ ทีมรักษาความปลอดภัยจะไม่เพียงแต่รักษาความปลอดภัยของโค้ดเท่านั้น แต่ยังรักษาความปลอดภัยของระบบโดยรวมอีกด้วยcisระบบอัตโนมัติไม่ได้ขจัดความรับผิดชอบ แต่เป็นการกระจายความรับผิดชอบใหม่
ในทางปฏิบัติ หมายความว่าต้องฟื้นฟูเจตนารมณ์ในจุดที่ความสะดวกสบายเข้ามาครอบงำ การจัดการการพึ่งพาของโอเพนซอร์สต้องคำนึงถึงพฤติกรรมที่ขับเคลื่อนด้วย AI แทนที่จะสันนิษฐานถึงการไตร่ตรองของมนุษย์ ความเสี่ยงด้านการพึ่งพาไม่สามารถถูกมองว่าเป็นเพียงการตรวจสอบเป็นครั้งคราวอีกต่อไปcise. CI/CD pipeline security ต้องบังคับใช้การตรวจสอบ ไม่ใช่สันนิษฐานว่าข้อมูลที่ป้อนเข้ามานั้นไม่มีอันตราย และแหล่งที่มาในห่วงโซ่อุปทานซอฟต์แวร์ต้องเปลี่ยนจากความปรารถนาไปเป็นมาตรฐานที่แท้จริง
อีกประเด็นสำคัญที่ได้จากการสนทนาคือ ความเร็วไม่ใช่สิ่งที่เป็นกลางอีกต่อไป ความล้มเหลวส่วนใหญ่ในห่วงโซ่อุปทานไม่ได้เกิดจากความผิดพลาดครั้งใหญ่เพียงครั้งเดียวcisไอออน แต่มาจากตัวเลือกอัตโนมัติเล็กๆ จำนวนมากที่ไม่มีใครอนุมัติอย่างชัดเจน นี่คือพรีcisอธิบายว่าทำไมโมเดลความไว้วางใจแบบดั้งเดิมจึงล้มเหลวภายใต้การพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วย AI
นี่ไม่ได้หมายความว่าเราควรละทิ้งโอเพนซอร์สหรือ AI ตรงกันข้าม มันเป็นการยอมรับบทบาทสำคัญของสิ่งเหล่านี้ในวิศวกรรมสมัยใหม่ แต่หากปราศจากการพัฒนาสมมติฐานด้านความปลอดภัย องค์กรอาจเสี่ยงที่จะปล่อยให้ระบบอัตโนมัติกำหนดความน่าเชื่อถือโดยปริยาย
สรุป…
วิธีคิดที่เป็นประโยชน์เกี่ยวกับความเปลี่ยนแปลงนี้คือว่า software supply chain security เรื่องนี้ไม่ได้เกี่ยวกับการปกป้องโบราณวัตถุเพียงอย่างเดียวอีกต่อไปแล้ว มันเกี่ยวกับการปกป้อง... decisเส้นทางไอออนในโลกที่ขับเคลื่อนด้วย AI คำถามด้านความปลอดภัยที่สำคัญที่สุดไม่ใช่แค่ “ส่วนประกอบนี้มีความเสี่ยงหรือไม่?” แต่เป็น “เหตุใดจึงมีการนำส่วนประกอบนี้เข้ามา โดยใครหรืออะไร และภายใต้ข้อจำกัดใด?” องค์กรที่ปรับตัวให้เข้ากับกรอบความคิดนี้จะไม่สามารถกำจัดความเสี่ยงได้ทั้งหมด แต่พวกเขาจะประหลาดใจกับความเสี่ยงน้อยลงอย่างแน่นอน
