Shahar Man, ผู้ร่วมก่อตั้งและซีอีโอของ Backslash Security – สัมภาษณ์ซีรีส์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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