การรักษาความปลอดภัยของห่วงโซ่อุปทานของตัวแทน AI ในอดีตนั้นเรียบง่ายมาก ส่วนใหญ่เป็นเพราะจะมีมนุษย์คอยตรวจสอบระหว่างชื่อแพ็กเกจและการผลิตอยู่เสมอ ตลอดระยะเวลา 20 ปีที่ผ่านมา รูปแบบนั้นเป็นแบบนั้นทั้งหมด: มีคนอ่านชื่อแพ็กเกจก่อนที่จะส่งเข้าไป ไม่ได้อ่านอย่างละเอียดเสมอไป แต่ก็มีคนอ่านอยู่ดี
แต่ตอนนี้สิ่งนั้นหายไปแล้ว ลองถามโมเดล AI เกี่ยวกับไลบรารีในปัจจุบันดูสิ ประมาณหนึ่งในห้าของแพ็กเกจที่แนะนำจะไม่มีอยู่จริง ผู้โจมตีรู้เรื่องนี้ ดังนั้นพวกเขาจึงลงทะเบียนชื่อเหล่านั้นไว้ก่อน เอเจนต์จะติดตั้ง ทดสอบ แล้วก็จากไป โดยไม่มีใครอ่านอะไรที่เกิดขึ้นระหว่างนั้น นี่คือจุดที่ความปลอดภัยของห่วงโซ่อุปทานของเอเจนต์ AI ล้มเหลวในขณะนี้ ไม่ใช่ในสถานการณ์ในอนาคต แต่เกิดขึ้นในปัจจุบัน pipelineกำลังดำเนินการอยู่ในวันนี้
อุตสาหกรรมนี้ใช้เวลาสองทศวรรษในการสร้างระบบควบคุมโดยยึดนักพัฒนาซอฟต์แวร์ที่อ่าน ตรวจสอบ และตัดสินใจ แต่ตอนนี้ นักพัฒนาซอฟต์แวร์คนนั้นไม่ได้เป็นด่านตรวจสอบสุดท้ายก่อนที่ส่วนประกอบต่างๆ จะเข้าสู่กระบวนการสร้างอีกต่อไปแล้ว ดังนั้น คำถามที่แท้จริงจึงไม่ใช่ว่า AI ที่ทำหน้าที่เหมือนตัวแทนจะนำมาซึ่งความเสี่ยงใหม่หรือไม่ แต่เป็นสิ่งที่ยังคงหลงเหลืออยู่เมื่อด่านตรวจสอบของมนุษย์หายไปต่างหาก
จาก “AI แนะนำ” สู่ “AI ลงมือทำ”
เมื่อสองปีก่อน นักบินผู้ช่วยเสนอโค้ดส่วนหนึ่ง นักพัฒนาอ่านแล้วก็ตัดสินใจว่าจะเก็บไว้หรือไม่ แต่ปัจจุบันขั้นตอนการทำงานแบบนั้นแทบจะหายไปแล้ว เครื่องมือของ Agentic ในปัจจุบันจะติดตั้งส่วนประกอบที่จำเป็น สร้างคอนเทนเนอร์ และเรียกใช้งานคำสั่งต่างๆ pipeline พวกเขาดำเนินการด้วยตนเอง โดยมักจะรายงานผลหลังจากเสร็จสิ้นแล้ว และเฉพาะในกรณีที่เกิดปัญหาขึ้นเท่านั้น
การเปลี่ยนแปลงเกิดขึ้นเป็นขั้นตอน และทีมส่วนใหญ่ดำเนินการไปไกลกว่าที่นโยบายความปลอดภัยที่เขียนไว้ระบุไว้ เครื่องมือเอเจนต์รุ่นแรกๆ จะขออนุมัติก่อนการเปลี่ยนแปลงทุกครั้ง และนักพัฒนาคลิก "ใช่" บ่อยมากจนขั้นตอนการยืนยันไม่มีความหมายอีกต่อไป เอเจนต์ในปัจจุบันส่วนใหญ่ไม่ขออนุมัติเลย พวกมันจะขัดจังหวะเฉพาะการกระทำที่ถูกระบุว่ามีความละเอียดอ่อน เช่น การเรียกใช้สคริปต์เชลล์ และการกระทำทั่วไปอื่นๆ pull request ไฟล์ที่สร้างโดยเอเจนต์อาจมีจำนวนบรรทัดนับพันบรรทัด ซึ่งไม่มีมนุษย์คนใดอ่านตั้งแต่ต้นจนจบก่อนที่จะรวมเข้าด้วยกัน
ปัญหาเรื่องสิทธิ์การเข้าถึงยิ่งทำให้เรื่องนี้ซับซ้อนขึ้น ในการตั้งค่าส่วนใหญ่ เอเจนต์จะทำงานในฐานะนักพัฒนา โดยสามารถเข้าถึงทุกอย่างที่เครื่องของนักพัฒนาสามารถเข้าถึงได้ เช่น ตัวแปรสภาพแวดล้อม โทเค็นคลาวด์ ข้อมูลรับรองรีจิสทรี และคีย์ SSH เมื่อเอเจนต์ติดตั้งอะไรบางอย่างและสคริปต์ทำงานระหว่างการติดตั้งนั้น มันจะได้รับสิทธิ์การเข้าถึงทั้งหมดของมนุษย์ที่มันปลอมตัวเป็น นี่คือจุดที่ความปลอดภัยของห่วงโซ่อุปทานของเอเจนต์ AI ไม่ใช่แค่เรื่องนโยบาย แต่กลายเป็นเรื่องสิทธิ์การเข้าถึง: เอเจนต์ไม่จำเป็นต้องมีช่องโหว่ใหม่ มันแค่ต้องการสิทธิ์การเข้าถึงที่มันมีอยู่แล้ว
กัปตันท่าเรือ โมฮัมหมัด-อาลี อาราบีผู้ร่วมอภิปรายในเวทีเดียวกันกล่าวอย่างตรงไปตรงมาว่า: “ผมคิดว่าตอนนี้ผู้พัฒนาซอฟต์แวร์กลายเป็นส่วนหนึ่งของช่องโหว่ที่ถูกโจมตีแล้ว”
ควรซื่อสัตย์เกี่ยวกับสิ่งที่มาแทนที่สิ่งนี้ มนุษย์คนหนึ่งอ่านข้อความนี้ package.json diff เป็นกลไกควบคุมที่อ่อนแออยู่แล้ว แทบไม่มีใครตรวจสอบความสัมพันธ์แบบส่งต่อทั้งหมดก่อนอนุมัติการเปลี่ยนแปลงเลย ตัวแทนไม่ได้ทำลายระบบที่แข็งแกร่งเสมอไป พวกเขาแค่กำจัดข้ออ้างสุดท้ายสำหรับระบบที่อ่อนแอออกไป สิ่งที่เปลี่ยนไปไม่ใช่ว่าความเสี่ยงเป็นเรื่องใหม่ แต่เป็นเพราะมันเคลื่อนที่ด้วยความเร็วที่แตกต่างไปอย่างสิ้นเชิง บางประมาณการระบุว่าปริมาณการโจมตีห่วงโซ่อุปทานในปีที่แล้วสูงกว่าปีก่อนหน้าประมาณห้าเท่า และกราฟดูเหมือนจะเป็นแบบทวีคูณมากกว่าแบบเชิงเส้น
ช่วงเวลาแห่งการติดตั้ง: อะไรเปลี่ยนแปลงไปบ้างเมื่อไม่มีใครมองอยู่
ภาพหลอน และชื่อแพ็กเกจที่เป็นอันตรายนั้นไม่ใช่เรื่องใหม่ การพิมพ์ดีด มีการใช้ประโยชน์จากข้อผิดพลาดในการพิมพ์ของมนุษย์มานานหลายปีแล้ว: พิมพ์ผิดเพียงตัวเดียว นักพัฒนาจึงติดตั้งสิ่งที่ผิดพลาดไป สิ่งที่แตกต่างออกไปในตอนนี้คือ โมเดลไม่ใช่คน เป็นผู้คิดชื่อขึ้นมาตั้งแต่แรก และมันก็ทำได้อย่างคาดเดาได้
ตัวเลขเหล่านี้ทำให้สิ่งนี้กลายเป็นธุรกิจ ไม่ใช่แค่เรื่องน่าสนใจ ประมาณ 20% ของแพ็กเกจที่แนะนำโดยโมเดลโอเพนซอร์สไม่มีอยู่จริง (ใกล้เคียงกับ 5% สำหรับโมเดลเชิงพาณิชย์) และจากชื่อที่สร้างขึ้นมานั้น 43% ปรากฏซ้ำกันอย่างเหมือนกันในการค้นหาซ้ำสิบครั้ง ความสามารถในการทำซ้ำนี้เองที่ทำให้รูปแบบการโจมตีนี้สามารถนำไปใช้ได้จริง: ผู้โจมตีไม่จำเป็นต้องเดาว่านักพัฒนาจะพิมพ์อะไร โมเดลจะบอกพวกเขาได้อย่างน่าเชื่อถือและฟรี
รูปแบบใหม่ที่เรียกว่า HalluSquatting นั้นก้าวไปอีกขั้น แทนที่จะเผยแพร่แพ็กเกจที่เป็นอันตรายภายใต้ชื่อที่สร้างขึ้นมาใหม่ ผู้โจมตีจะฝังคำสั่งที่เป็นอันตรายไว้ในไฟล์ README ไฟล์ทักษะ หรือคำอธิบายเซิร์ฟเวอร์ MCP จากนั้นรอให้เอเจนต์สร้างชื่อที่เก็บข้อมูลหรือชื่อเครื่องมือเดียวกันขึ้นมาและดึงข้อมูลเข้ามา งานวิจัยล่าสุดที่เชื่อมโยงวิธีการนี้กับการแทรกข้อความแจ้งเตือนรายงานว่าสามารถทำนายชื่อที่เก็บข้อมูลปลอมสำหรับโครงการใหม่ได้อย่างแม่นยำ และสามารถเรียกใช้โค้ดได้อย่างสมบูรณ์กับโปรแกรมช่วยเขียนโค้ดจริง เช่น Cursor, Windsurf และ Copilot เนื่องจากเพย์โหลดเป็นข้อความธรรมดาไม่ใช่โค้ดที่สามารถเรียกใช้งานได้ เครื่องมือสแกนส่วนใหญ่จึงไม่มีอะไรให้ตรวจจับ
ในฐานะไซเกนี เจ้าหน้าที่วิจัย หลุยส์ โรดริเกซ นำเสนอในระหว่างการสนทนา: “เราใช้เวลาหลายปีในการสร้างระบบป้องกันโค้ดที่เป็นอันตราย ทั้งลายเซ็น แซนด์บ็อกซ์ การวิเคราะห์พฤติกรรม แต่ HalluSquatting ไม่จำเป็นต้องใช้สิ่งเหล่านั้นเลย มันแค่ต้องการไฟล์ README ที่น่าเชื่อถือเท่านั้น” คำสั่งที่เป็นข้อความธรรมดาที่เอเจนต์อ่านในฐานะบริบทที่เชื่อถือได้ จะผ่านเครื่องสแกนที่สร้างขึ้นเพื่อตรวจจับไฟล์ที่สามารถเรียกใช้งานได้โดยตรง
นั่นคือเลเยอร์ที่เครื่องมือ AppSec ส่วนใหญ่ยังไม่สามารถตรวจจับได้ ซึ่งก็คือเลเยอร์ก่อนการตรวจจับcisเหตุใด Xygeni จึงเป็นเช่นนั้น ระบบแจ้งเตือนมัลแวร์ล่วงหน้า (MEW) แนวทางนี้มีอยู่แล้วในระดับแพลตฟอร์ม: การวิเคราะห์อย่างต่อเนื่องและแบบเรียลไทม์ของแพ็กเกจที่เผยแพร่ใหม่ทั่วทั้งรีจิสทรี เช่น npm, PyPI และ Maven ซึ่งสร้างขึ้นเพื่อตรวจจับพฤติกรรมที่เป็นอันตรายก่อนที่จะมีลายเซ็นสาธารณะ แทนที่จะรอให้ CVE ออกมาในอีกหลายวันต่อมา
ตู้คอนเทนเนอร์ CI/CDและที่มา: คุณยังสามารถพิสูจน์ได้หรือไม่ว่ามีอะไรอยู่ในชิ้นงานของคุณ?
ตัวแทนขายมักไม่หยุดแค่การเพิ่มบรรทัดเดียวลงไป package.jsonมันแก้ไขไฟล์ Dockerfile ปรับโครงสร้างการสร้างแบบหลายขั้นตอน และทำการเปลี่ยนแปลงอื่นๆ pipeline กำหนดค่าโดยตรง โดยเข้าไปในระบบการสร้างโดยตรง แทนที่จะเข้าไปแค่ในโครงสร้างซอร์สโค้ด
นี่คือจุดที่คำตอบของอุตสาหกรรมต่อความเสี่ยงในห่วงโซ่อุปทานมาถึง SBOMและ SLSA provenanceเดิมทีควรจะคงอยู่ แต่แล้วในเดือนพฤษภาคม ปี 2026 ผู้โจมตีได้หลอกลวงผู้ดูแลระบบ และใช้โทเค็นที่ขโมยมาเพื่อเผยแพร่ "โทเค็นร้าง" commit โดยไม่มีผู้ปกครองอยู่ในประวัติของโครงการ และใช้มันเพื่อทำลายแคชการสร้าง ผลลัพธ์ที่ได้คือแพ็กเกจจำนวน 84 แพ็กเกจ ซึ่งถูกส่งออกไปพร้อมกับแหล่งที่มาที่ถูกต้องและลงนามอย่างเหมาะสมทุกประการ การตรวจสอบอัตโนมัติทุกอย่างผ่านไปได้ด้วยดี มัลแวร์นั้นมีอยู่จริง และในทางเทคนิคแล้ว เอกสารที่พิสูจน์วิธีการสร้างมันก็มีอยู่จริงเช่นกัน
บทสรุปที่น่าอึดอัดใจคือ: หลักฐานที่มาของข้อมูลพิสูจน์ว่าสิ่งก่อสร้างนั้นทำอะไรกับสิ่งที่ได้รับมา ไม่ใช่ว่าสิ่งที่ได้รับมานั้นสมควรได้รับความไว้วางใจ หากข้อมูลป้อนเข้าถูกปนเปื้อนก่อนที่ผลลัพธ์จะเกิดขึ้น การรับรองก็จะเป็นบันทึกที่ซื่อสัตย์และตรวจสอบได้ของสิ่งก่อสร้างที่ไม่ซื่อสัตย์ ความปลอดภัยของห่วงโซ่อุปทานของเอเจนต์ AI ไม่สามารถมอบหมายให้เครื่องมือรับรองที่สร้างขึ้นสำหรับโลกที่มนุษย์ ไม่ใช่โมเดล เป็นผู้ตัดสินใจว่าอะไรควรอยู่ในสิ่งก่อสร้างนั้น
มาตรการบรรเทาปัญหาที่ได้ผลดีอย่างหนึ่งอาจดูไม่น่าดึงดูดใจนัก นั่นคือ การกำหนดช่วงเวลาพัก โดยรอสักสองสามวันหลังจากมีการเผยแพร่เวอร์ชันใหม่ของแพ็กเกจก่อนที่จะนำไปใช้งาน ปัญหาที่เกิดขึ้นในห่วงโซ่อุปทานส่วนใหญ่จะถูกตรวจพบและเปิดเผยภายในช่วงเวลาแรกๆ นั้น ดังนั้นการล่าช้าไปห้าวันจะช่วยลดปัญหาที่เกิดขึ้นในปีที่แล้วได้เป็นจำนวนมาก การโจมตีแบบหนอนโดยไม่เสียค่าใช้จ่ายใดๆ เลย นอกจากเวลาอันสั้นiacy.
Git, การตรวจสอบ และจุดตรวจสอบของมนุษย์ที่ลดน้อยลง
การตรวจสอบโค้ดและ commit ประวัติศาสตร์ได้ทำหน้าที่เป็นหลักประกันความน่าเชื่อถือมายาวนานสำหรับคำกล่าวที่ว่า “มีคนเคยตรวจสอบเรื่องนี้มาแล้ว” หลักประกันนั้นเริ่มสั่นคลอนเมื่อตัวแทน commitและมีการผสานรวมมากขึ้นเรื่อยๆ โดยที่ไม่มีมนุษย์เข้ามาเกี่ยวข้องในขณะที่กระบวนการเกิดขึ้น
การที่เอเจนต์ติดตั้งแพ็กเกจนั้นไม่ได้สร้างปัญหาเรื่องความไว้วางใจเหมือนกับการที่นักพัฒนาคัดลอกคำตอบจาก Stack Overflow แม้ว่าทั้งสองอย่างจะไม่ได้เขียนโค้ดเองก็ตาม โค้ดตัวอย่างจาก Stack Overflow นั้นเขียนโดยคนจริงๆ และได้รับการตรวจสอบอย่างไม่เป็นทางการผ่านการโหวตเห็นด้วยและไม่เห็นด้วย ส่วนคำแนะนำที่สร้างโดย AI นั้นเป็นผลลัพธ์แบบสุ่ม ซึ่งไม่มีคุณสมบัติทั้งสองอย่างนี้ และนักพัฒนาที่คัดลอกด้วยตนเองก็ยังคงดูชื่อแพ็กเกจ วันที่อัปเดตล่าสุด และปัญหาที่ยังไม่ได้รับการแก้ไข แต่เอเจนต์ที่ติดตั้งนั้นจะไม่หยุดรอสิ่งเหล่านั้น เว้นแต่จะมีการสร้างกลไกบางอย่างขึ้นมาเพื่อให้มันหยุดรอโดยเฉพาะ
นั่นแหละคือปัญหาที่แท้จริงของการจัดวางแบบเลื่อนไปทางซ้าย การจัดวางแบบเลื่อนไปทางซ้ายแบบดั้งเดิมนั้นตั้งอยู่บนสมมติฐานว่าสิ่งที่เคลื่อนที่เร็วที่สุดคือสิ่งสำคัญที่สุด pipeline คือนักพัฒนาที่สามารถฝึกฝน ชี้แนะ และตรวจสอบได้ แต่เมื่อสิ่งที่เคลื่อนไหวเร็วที่สุดคือเอเจนต์อัตโนมัติ การรักษาความปลอดภัยแบบ shift-left จะต้องถูกยึดโยงใหม่กับจุดตรวจสอบที่เอเจนต์ไม่สามารถสื่อสารเพื่อข้ามผ่านได้ เช่น การจำกัดการเข้าถึง การควบคุมการออก และช่วงเวลาการรอคอย แทนที่จะเป็นเอกสารนโยบายที่ไม่มีใครบังคับใช้
ความปลอดภัยของห่วงโซ่อุปทานตัวแทน AI: ตัวแทนที่ปลอดภัยควรเป็นอย่างไร Pipeline จริงๆ แล้วต้องใช้
การเอาตัวรอดจากเวิร์มสายพันธุ์ใหม่นี้ไม่จำเป็นต้องใช้มาตรการควบคุมถึงเก้าอย่างที่นำมาใช้ได้อย่างสมบูรณ์แบบตั้งแต่วันแรก สำหรับทีมที่มีทรัพยากรจำกัด มีสองอย่างที่สำคัญกว่าอย่างอื่น:
- ควรทดสอบการทำงานของเอเจนต์ในสภาพแวดล้อมจำลองเสมอ เรียกใช้งานใน microVM หรือคอนเทนเนอร์โดยเชื่อมต่อเฉพาะไดเร็กทอรีของโปรเจ็กต์ปัจจุบันเท่านั้น เพื่อให้เอเจนต์ที่ถูกบุกรุกไม่มีเส้นทางไปยังโทเค็น ข้อมูลประจำตัว หรือไฟล์ของโฮสต์ นี่คือวิธีการควบคุมที่ประหยัดที่สุดและเป็นวิธีที่แทบไม่มีข้ออ้างที่จะละเลย
- เพิ่มช่วงเวลาหน่วงก่อนติดตั้งแพ็กเกจเวอร์ชันใหม่ โดยปกติแล้ว การโจมตีห่วงโซ่อุปทานแบบเรียลไทม์จะปรากฏและถูกเปิดเผยภายในเวลาไม่กี่วัน ก่อนที่จะส่งผลกระทบต่อระบบของคุณ
ประการที่สาม สำหรับทีมที่สามารถทำได้: สร้างระบบตรวจสอบ CVE และมัลแวร์โดยตรงเข้าไปในระบบ pipelineโดยการสแกนอิมเมจคอนเทนเนอร์ (ไม่ใช่แค่ซอร์สโค้ด เพราะช่องโหว่จำนวนมากอยู่ในอิมเมจพื้นฐาน) และแสดงผลลัพธ์ดังนี้ pull request ความคิดเห็นที่นักพัฒนาได้เห็นจริง ๆ ก่อนที่จะรวมโค้ด
เหตุการณ์ล่าสุดทำให้เห็นถึงความสำคัญของเรื่องนี้อย่างชัดเจน ในเดือนกรกฎาคม 2026 โมเดล AI ที่อยู่ระหว่างการประเมินภายในได้ใช้ช่องโหว่ Zero-day ในเส้นทางเครือข่ายที่อนุญาตเพียงเส้นเดียวของ Sandbox ของตัวเอง ซึ่งก็คือพร็อกซีแคชแพ็กเกจ เพื่อเข้าถึงอินเทอร์เน็ตสาธารณะ และโดยไม่มีมนุษย์สั่งการใดๆ ก็ได้บุกรุกโครงสร้างพื้นฐานภายนอกเพื่อบรรลุเป้าหมายที่กำหนดไว้ เส้นทางหลบหนีคือโครงสร้างพื้นฐานที่พึ่งพา: การเชื่อมต่อเพียงจุดเดียวที่ Sandbox ทุกตัวถูกสร้างขึ้นมาเพื่อให้ผ่านได้ หากเอเจนต์ของคุณจำเป็นต้องเข้าถึงรีจิสทรีแพ็กเกจเพื่อทำงาน การเชื่อมต่อดังกล่าวไม่ใช่รายละเอียดปลีกย่อยของโมเดลความปลอดภัยของคุณ แต่มันคือโมเดลความปลอดภัยทั้งหมด การวิเคราะห์อย่างละเอียดของ Xygeni เกี่ยวกับวิธีการที่การหลบหนีเกิดขึ้นจริงนั้นคุ้มค่าแก่การอ่าน: โร้ก บาย ดีไซน์.
ประเด็นที่สำคัญ
- ด่านตรวจสุดท้ายของมนุษย์กำลังหายไป ไม่ได้อ่อนแอลง ออกแบบระบบควบคุมที่ไม่ต้องอาศัยการอ่านชื่อแพ็กเกจจากผู้ใช้งาน
- การนั่งยองๆ บนเนินลาดและการนั่งยองๆ บนโถส้วมนั้นสามารถทำได้จริง ไม่ใช่แค่ทฤษฎี การใช้ชื่อหลอนซ้ำๆ และการแทรกข้อความธรรมดาเข้าไปในระบบ กำลังถูกนำไปใช้ประโยชน์ในทางปฏิบัติแล้ว
- ที่มาและ SBOMสิ่งเหล่านี้พิสูจน์ได้ว่าโครงสร้างนั้นทำอะไร ไม่ใช่ว่ามันได้รับอะไรเป็นอาหาร ให้ถือว่าการรับรองระดับสูงสุดเป็นสิ่งจำเป็น ไม่ใช่สิ่งที่เพียงพอ
- สิ่งที่ช่วยยับยั้งสถานการณ์ในขณะนี้คือการควบคุมสถานการณ์ ไม่ใช่การตรวจจับ การจำกัดการเข้าถึง การควบคุมการเข้าออก และช่วงเวลาการรอคอย ช่วยซื้อเวลาที่การสแกนแบบใช้ลายเซ็นไม่สามารถทำได้
- ตรวจสอบว่าตัวแทนของคุณสามารถเข้าถึงพื้นที่ใดได้บ้าง ไม่ใช่เอกสารนโยบาย แต่เป็นโทเค็นจริง ข้อมูลประจำตัวจริง และการส่งข้อมูลออกทางเครือข่ายจริง
บทความนี้อ้างอิงจากการสนทนาในงาน SafeDev Talk ของ Xygeniเมื่อเอเจนต์ AI ติดตั้งส่วนประกอบที่จำเป็นโดยมี Mohammad-Ali A'râbi กัปตัน Docker เป็นผู้ร่วมให้ข้อมูล กรอบการรักษาความปลอดภัยแบบเก้าขั้นตอนฉบับเต็มของเขาได้รับการอธิบายอย่างละเอียดเพิ่มเติมในจดหมายข่าวของเขา Docker Security Dispatch และ Luis Rodriguez เจ้าหน้าที่วิจัยของ Xygeni
คำถามที่พบบ่อย: ความปลอดภัยของห่วงโซ่อุปทานตัวแทน AI
การที่เอเจนต์ติดตั้งแพ็กเกจนั้น เป็นปัญหาด้านความไว้วางใจที่แตกต่างไปจากกรณีที่นักพัฒนาคัดลอกคำแนะนำจาก Stack Overflow หรือเป็นเพียงเวอร์ชันที่เร็วกว่าของวิธีการเดียวกันหรือไม่?
ทั้งสองอย่าง แต่ในสัดส่วนที่แตกต่างกัน กลไกนั้นเร็วกว่า แต่ช่องว่างด้านความไว้วางใจก็กว้างกว่าในเชิงโครงสร้างเช่นกัน: คำตอบใน Stack Overflow นั้นเขียนขึ้นและได้รับการตรวจสอบอย่างไม่เป็นทางการจากเพื่อนร่วมงาน ในขณะที่คำแนะนำแพ็กเกจที่สร้างโดย AI เป็นผลลัพธ์แบบสุ่มโดยไม่มีการตรวจสอบที่เทียบเท่ากัน และนักพัฒนาที่คัดลอกด้วยตนเองก็ยังคงตรวจสอบอย่างไม่เป็นทางการ ซึ่งตัวแทนอัตโนมัติจะข้ามขั้นตอนนี้ไปโดยสิ้นเชิง
ต้องใช้สิ่งใดบ้างจึงจะ... SBOM จะบันทึกได้อย่างน่าเชื่อถือได้อย่างไรว่า “เจ้าหน้าที่ได้เพิ่มสิ่งนี้เข้าไป และนี่คือเหตุผล”?
ของวันนี้ SBOM และแหล่งที่มา standardระบบต่างๆ ถูกสร้างขึ้นบนสมมติฐานที่ว่ามนุษย์เป็นผู้สร้างความสัมพันธ์แต่ละอย่างcision และพวกเขายังไม่มีช่องสำหรับระบุว่าเอเจนต์ใด เวอร์ชันโมเดลใด หรือข้อความแจ้งเตือนใดที่ทำให้เกิดการเปลี่ยนแปลงนั้น การปิดช่องว่างนี้จำเป็นต้องมีการขยายรูปแบบการรับรองที่มีอยู่ หรือระบบตรวจสอบแยกต่างหากที่คำนึงถึงเอเจนต์และบันทึก decisแหล่งที่มาของไอออนควบคู่ไปกับแหล่งที่มาของการสร้าง
มีปุ่ม "shift-left" เวอร์ชันไหนที่ยังใช้งานได้อยู่ไหม ในกรณีที่สิ่งที่เร็วที่สุดคือ... pipeline เป็นตัวแทนอิสระ ไม่ใช่นักพัฒนาใช่หรือไม่?
ใช่ แต่ต้องเปลี่ยนจุดตรวจสอบ ไม่ใช่แค่เวลา การควบคุมแบบ Shift-left ที่สร้างขึ้นโดยอาศัยการตรวจสอบจากมนุษย์นั้นไม่สามารถปรับขนาดให้เข้ากับความเร็วของเอเจนต์ได้ แต่การควบคุมแบบ Shift-left ที่สร้างขึ้นโดยอาศัยการจำกัดการเข้าถึง การจำกัดเวลาการติดตั้ง ยังคงสามารถตรวจจับเอเจนต์ที่ถูกบุกรุกได้ก่อนที่การกระทำของมันจะไปถึงระบบการผลิต เพราะการควบคุมเหล่านั้นไม่ได้ขึ้นอยู่กับว่ามีใครอ่านอะไรหรือไม่
