ชาหาร์ มัน Co-founder และ CEO ของ Backslash Security – สัมภาษณ์ซีรีส์

ชาหาร์ มัน Co-founder และ CEO ของ Backslash Security เป็นผู้นำด้านเทคโนโลยีที่มีประสบการณ์ยาวนานและมีความเชี่ยวชาญด้านการพัฒนาเครื่องมือคลาวด์ ความมั่นคงทางไซเบอร์ และซอฟต์แวร์สำหรับองค์กร ปัจจุบันเขาดำรงตำแหน่ง CEO ของ Backslash Security ซึ่งเป็นบริษัทที่มุ่งเน้นในการรักษาความปลอดภัยของสภาพแวดล้อมการพัฒนาซอฟต์แวร์ที่เป็นมิตรกับ AI โดยปกป้องทุกสิ่งตั้งแต่ IDE และเอเจนต์ AI ไปจนถึงโค้ดที่สร้างขึ้นและกระบวนการทำงานที่ถูกกระตุ้น ก่อนหน้านี้ เขาเคยดำรงตำแหน่งผู้นำระดับสูงใน Aqua Security โดย曾ดำรงตำแหน่ง Vice President of Product Management และ Vice President of R&D ซึ่งช่วยสร้างแพลตฟอร์มความมั่นคงสำหรับ контейเนอร์ข้ามชีวิตการพัฒนาซอฟต์แวร์ ในช่วงต้นอาชีพของเขา มันใช้เวลาเกินกว่าหนึ่งทศวรรษที่ SAP โดย曾เป็นผู้นำในการพัฒนาและโครงการผลิตภัณฑ์ รวมถึง SAP Web IDE และทำงานอย่างใกล้ชิดกับลูกค้าองค์กรระดับโลก ในขณะเดียวกันก็ช่วยให้ระบบนิเวศของนักพัฒนามีการเติบโต อาชีพของเขาที่ผ่านมาเริ่มต้นด้วยบทบาททางเทคนิคและผู้นำในบริษัทสตาร์ทอัพและส่วนหน่วยเทคโนโลยีการป้องกันของอิสราเอล ซึ่งให้พื้นฐานที่แข็งแกร่งทั้งในด้านวิศวกรรมและระบบขนาดใหญ่

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

คุณเคยดำรงตำแหน่งผู้นำในด้านผลิตภัณฑ์และ R&D ในบริษัทอย่าง Aqua Security และ SAP ก่อนที่จะก่อตั้ง Backslash Security สัญญาณแรกที่ทำให้คุณเชื่อว่าการพัฒนาซอฟต์แวร์ที่เป็นมิตรกับ AI และ “vibe coding” จะเปลี่ยนแปลงการสร้างซอฟต์แวร์อย่างลึกซึ้ง และความมั่นคงจำเป็นต้องถูกสร้างขึ้นใหม่เพื่อสนับสนุนสิ่งนี้คืออะไร?

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

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

คุณอธิบาย “vibe coding” ว่าเป็นการขยายพื้นที่การโจมตีออกไปนอกเหนือจากโค้ดไปยังพรอมต์, เอเจนต์, เซิร์ฟเวอร์ MCP, และชั้นเครื่องมือ อันตรายที่ถูกเข้าใจผิดมากที่สุดใน chồngใหม่นี้ที่นักพัฒนาซอฟต์แวร์และทีมความมั่นคงกำลังพลาดอยู่คืออะไร?

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

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

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

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

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

เครื่องมืออย่าง Cursor, Claude Code, และ GitHub Copilot กำลังเป็นส่วนหนึ่งของกระบวนการทำงานของนักพัฒนาซอฟต์แวร์ คุณเห็นช่องว่างด้านความมั่นคงที่ใหญ่ที่สุดเมื่อทีมใช้เครื่องมือเหล่านี้โดยไม่มีการกำกับดูแลที่เหมาะสม?

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

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

ช่องว่างที่เกิดขึ้นใหม่เป็นอันดับสามคือทุกคนสามารถกลายเป็นนักพัฒนาซอฟต์แวร์ได้ — สิ่งที่เรียกว่า “citizen-developers” โดยใช้เครื่องมือ “vibe coding” เมื่อบุคลากรทางการเงินใช้ Claude Code เพื่อสร้างกระบวนการอัตโนมัติและเชื่อมต่อกับระบบภายใน องค์กรจะสร้างความเสี่ยงและเป็นจุดบอดที่ยิ่งใหญ่แม้กระทั่งในปัจจุบัน

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

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

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

การกระตุ้นกำลังเกิดขึ้นเป็นชั้นใหม่ของการเขียนโปรแกรมได้ องค์กรควรเข้าใกล้การรักษาความปลอดภัยของการกระตุ้นและการป้องกันปัญหาเช่นการฉีดการกระตุ้น, การรั่วไหลของข้อมูล, หรือการดัดแปลงอย่างไร?

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

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

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

หนึ่งในธีมหลักของคุณคือ “การเป็นแผนกของ Yes” — การทำให้ความมั่นคงไม่ชะลอความเร็วของนักพัฒนาซอฟต์แวร์ คุณสร้างสมดุลระหว่างการป้องกันแบบเรียลไทม์กับความเร็วของนักพัฒนาซอฟต์แวร์ในสภาพแวดล้อมที่ความเร็วเป็นสิ่งสำคัญอย่างไร?

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

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

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

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

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

เมื่อมองไปข้างหน้า 12 ถึง 24 เดือน คุณคาดหวังว่าการโจมตีหรือช่องโหว่ใดที่จะเกิดขึ้นโดยเฉพาะเนื่องจากกระบวนการพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วย AI?

เราคาดหวังว่าช่องโหว่ของโค้ดทั่วไปส่วนใหญ่จะถูกหลีกเลี่ยงล่วงหน้าผ่านการปรับปรุงของโมเดลภาษาขนาดใหญ่ (LLM) หรือการปรับปรุงกฎการกระตุ้นที่ฝังอยู่ใน “harness” ที่ล้อมรอบเครื่องมือเหล่านี้ หากเมื่อปีที่แล้ว เราเห็นการเพิ่มขึ้นของช่องโหว่เนื่องจากความเร็วที่เพิ่มขึ้น สิ่งนี้จะแก้ไขตัวเองได้ และสิ่งที่ไม่ได้รับการแก้ไขจะถูกตามล่าโดยการวิเคราะห์โค้ดและ SCA ที่ใช้ AI (บางส่วนจะถูกจัดหาโดยผู้ให้บริการแพลตฟอร์ม AI เช่น Claude Code Security และโครงการ Glasswing)

อย่างไรก็ตาม ฉันคาดหวังผลลัพธ์ที่เลวร้ายกว่าเมื่อใช้เครื่องมือ AI ที่ไม่ได้รับการดูแลและไม่ได้รับการดูแลในการพัฒนาซอฟต์แวร์ — เช่น เอเจนต์แบบโอเพ่นซอร์ส (OpenClaw เป็นตัวอย่างที่ดี) ซึ่งมีการตั้งค่าความมั่นคงที่ไม่ดีมากจนต้องมีการดูแลและผู้ใช้ที่มีความรู้ด้านความมั่นคงที่ถูกแซงหน้าโดยความกระตือรือร้นในการใช้ “vibe coding”

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

ขอขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Backslash Security