ซายิด อัล ฮามานี, CEO และผู้ก่อตั้ง Boost Security – ซีรีส์สัมภาษณ์

ซายิด อัล ฮามานี ซึ่งเป็น CEO และผู้ก่อตั้ง Boost Security เป็นผู้นำด้านความปลอดภัยไซเบอร์และ DevSecOps ที่มีประสบการณ์มากกว่าสองทศวรรษในการสร้างและขยายการดำเนินงานเทคโนโลยีทั่วโลก ตั้งแต่ก่อตั้ง Boost Security ในปี 2020 เขาได้มุ่งเน้นในการที่จะทำให้องค์กรต่างๆ มีความปลอดภัยในการพัฒนาซอฟต์แวร์ โดยอาศัยประสบการณ์จากบทบาทก่อนหน้านี้ รวมถึง VP of Application Security ที่ Trend Micro และ Co-Founder/CEO ของ IMMUNIO ในช่วงก่อนหน้านี้ เขาเคยดำรงตำแหน่งผู้นำระดับสูงใน Canonical โดยนำเสนอรายการผลิตภัณฑ์ การจัดการวิศวกรรม และการสนับสนุนระดับโลก และใน SITA โดยที่เขาจัดการการดำเนินงาน IT ระดับภารกิจที่สำคัญ การทำงานของเขาสะท้อนถึงผลงานที่แข็งแกร่งในการสร้างทีม การเพิ่มประสิทธิภาพระบบ และการส่งเสริมแนวทางปฏิบัติด้านความปลอดภัยที่ทันสมัย

Boost Security เป็นบริษัทด้านความปลอดภัยไซเบอร์ที่มุ่งเน้นในการรักษาความปลอดภัยของซอฟต์แวร์สมัยใหม่ผ่านแพลตฟอร์ม DevSecOps สำหรับนักพัฒนา โดยเทคโนโลยีของบริษัทนี้สามารถรวมเข้ากับ CI/CD pipelines ได้โดยตรงเพื่อตรวจจับ จัดลำดับความสำคัญ และแก้ไขช่องโหว่ด้านความปลอดภัยโดยอัตโนมัติ ซึ่งช่วยลดภาระการทำงานด้วยมือและรักษาความเร็วในการพัฒนาต่อไป โดยการรวมความปลอดภัยของแอปพลิเคชันและซัพพลายเชนเข้าด้วยกันในระบบเดียว แพลตฟอร์มนี้ให้ความสามารถในการมองเห็นทั้งหมดทั่วโค้ด การพึ่งพา และโครงสร้างพื้นฐาน ช่วยให้องค์กรต่างๆ มีความสามารถในการทนต่อการโจมตีในระบบคลาวด์ที่ซับซ้อน

คุณเคยเป็นผู้นำด้านความปลอดภัยของแอปพลิเคชันที่ Trend Micro และร่วมก่อตั้ง IMMUNIO คุณได้รับแรงบันดาลใจในการก่อตั้ง Boost Security จากอะไร และคุณมองเห็นช่องว่างในตลาดอย่างไรที่คุณสามารถระบุได้ตั้งแต่เนิ่นๆ

IMMUN.IO เป็นหนึ่งในบริษัท RASP แรกที่ก่อตั้งขึ้น และประสบการณ์ของเราจนถึงขณะนั้นคือ WAFs ในฐานะเทคโนโลยีความปลอดภัยในขณะรันไทม์เป็นเรื่องที่ยากต่อการดูแลและไม่ได้ผลลัพธ์ที่ดี เราได้เห็นถึงวิธีการที่ WAFs จะถูกแทนที่ด้วยโซลูชันที่แม่นยำและง่ายต่อการดูแลมากขึ้น โดยการอินสตรูเมนต์ให้กับแอปพลิเคชัน

นั่นคือในปี 2012 DevOps ยังคงอยู่ในช่วงเริ่มต้น ส่วนใหญ่ทีมไม่ได้ใช้ Agile และ Kubernetes ยังไม่เป็นที่รู้จัก

Trend Micro ได้เข้าซื้อกิจการ IMMUN.IO ในปี 2017 ในช่วงเวลานั้น มีการใช้ DevOps มากขึ้น เช่น CI/CD pipelines การพัฒนาที่รวดเร็ว และการปล่อยสินค้าเร็วขึ้น ทีมพัฒนาซอฟต์แวร์สามารถสร้างซอฟต์แวร์ได้ดีขึ้นและจัดส่งได้เร็วขึ้น แต่ความปลอดภัยยังคงไม่ดี:

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

การผลิตซอฟต์แวร์เร็วขึ้นเป็นเรื่องที่ทำได้ง่ายขึ้น แต่การผลิตซอฟต์แวร์ที่มีความปลอดภัยยังคงเป็นเรื่องที่ยาก

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

เราช่วยให้บริษัทต่างๆ ใส่ความปลอดภัยลงใน SDLC ในช่วงยุค DevOps นั่นคือการเปลี่ยนแปลงจาก 1 ถึง 10 เรากำลังอยู่ในยุคโค้ดด้วยตัวแทน – ที่ตัวแทนทำการเขียนโค้ดจำนวนมาก แต่ก็เป็นปัญหาเดียวกัน – ความเร็วและปริมาณโค้ดเพิ่มขึ้นจาก 10 ถึง 100 และเราตั้งเป้าที่จะดำเนินการต่อในแนวทางเดียวกัน

คุณได้โต้แย้งว่าชีวิตวงจรการพัฒนาซอฟต์แวร์ (SDLC) ได้เปลี่ยนแปลงไปอย่างมีนัยสำคัญในด้านต้นน้ำ คุณได้พบกับช่วงเวลาที่คุณรู้สึกว่าแนวทาง DevSecOps แบบดั้งเดิมไม่เพียงพออีกต่อไปเมื่อไหร่?

มันเกิดขึ้นเมื่อเราเห็นว่าผู้โจมตีเข้ามาในระบบได้อย่างไร เราเห็นรูปแบบเดียวกันซ้ำๆ – วิธีการทำงานของ GitHub ที่ไม่ได้รับการตรวจสอบตั้งแต่ fork repo, โทเค็นที่มีการเข้าถึงคลาวด์ผลิตที่ฝังอยู่ใน config ของรันเนอร์, งาน CI ที่ถูกขโมยมาเพื่อใช้ในการติดตั้งพาเลตของโจมตี สิ่งเหล่านี้เรียกว่า “การโจมตีแบบใช้พายพ์” เพราะผู้โจมตีใช้การทำงานอัตโนมัติของคุณมาเป็นอาวุธ โดยใช้เครดิตเชลล์ที่ทีมความปลอดภัยของคุณได้ตรวจสอบแล้ว

สแต็ค DevSecOps ที่เราสร้างขึ้นมาในช่วงหนึ่งทศวรรษไม่มีคำตอบสำหรับปัญหานี้ การสแกน SAST ตรวจสอบโค้ดแหล่งที่มาของแอปพลิเคชัน การสแกน SCA ตรวจสอบการพึ่งพาของแอปพลิเคชัน ทั้งสองสมมติว่าพายพ์ที่กำลังทำงานนั้นเป็นของเชื่อถือได้ ในขณะที่พายพ์เองเป็นไฟล์ YAML ที่มีคำสั่งเชลล์ การเข้าถึงเครือข่าย และเครดิตเชลล์ที่สำคัญ และเกือบไม่มีใครที่ตรวจสอบมัน

เมื่อมันกลายเป็นเส้นทางที่ง่ายที่สุด คุณสามารถจัดส่งโค้ดที่สะอาดได้ แต่ยังคงส่งมอบคลาวด์ของคุณให้กับผู้โจมตี

องค์กรควรปรับเปลี่ยน SDLC อย่างไรในโลกที่ตัวแทนที่สร้างโค้ดอย่างต่อเนื่องแทนที่นักพัฒนาที่เขียนโค้ดทีละขั้นตอน?

เราต้องหยุดคิดเกี่ยวกับ SDLC เป็นลำดับของการตรวจสอบ ตัวแทนมีเวลาที่ลดลงจาก “ใครเขียนสิ่งนี้” ถึง “สิ่งนี้อยู่ในผลิต” จากสัปดาห์เป็นนาที โมเดลเก่าสมมติว่ามีจังหวะของมนุษย์ระหว่างการตรวจสอบโค้ด SAST SCA และการ_deploy แต่เรากำลังอยู่เกินกว่านั้นแล้ว

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

หลายองค์กรยังคอรักษาเครื่องมือโค้ด AI เป็นเพียงชั้นการผลิตเท่านั้น คุณเชื่อว่าพวกมันแสดงถึงพื้นผิวการโจมตีใหม่ทั้งหมดหรือไม่?

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

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

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

Boost Security มองเครื่องพัฒนาของนักพัฒนาว่าเป็นจุดควบคุมใหม่ มีความเสี่ยงที่เกิดขึ้นที่จุดสิ้นสุดนั้นที่ทีมความปลอดภัยกำลังพลาดไป?

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

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

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

คุณเน้นย้ำถึง “กับดักบริบท” ที่ตัวแทนอาจเข้าถึงไฟล์ cục bộ ตัวแปรสภาพแวดล้อม และการกำหนดค่า ได้อย่างไรกว้างขวางและยากที่จะตรวจจับ?

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

ปัญหาในการตรวจจับเริ่มต้นเพราะการจราจรที่รั่วไหลดูเหมือนกับการใช้งานผลิตภัณฑ์ปกติ มันเป็น TLS ไปยัง api.openai.com หรือ api.anthropic.com มันมาจากแอปพลิเคชันทางธุรกิจที่ได้รับการอนุมัติ DLP มองเห็นว่านักพัฒนากำลังใช้เครื่องมือ AI ที่บริษัทเพิ่งซื้อลิขสิทธิ์มา ไม่ได้เห็นว่าหนึ่งในสตริงในพรอมต์นั้นคือคีย์ AWS ที่ตัวแทนดึงมาจาก .env ไฟล์ในไดเรกทอรี่พี่น้อง

คุณจับได้โดยการตรวจสอบพรอมต์ก่อนที่จะออกจากแล็ปท็อป ซึ่งเป็นที่ที่แทบจะไม่มีสแต็คความปลอดภัยใดๆ อยู่ในขณะนี้

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

นี่คือสถานการณ์ที่เราเห็นซ้ำๆ นักพัฒนาขอให้ตัวแทนทำการเพิ่มคุณสมบัติที่ต้องการไลบรารี HTTP retry ตัวแทนแนะนำชื่อแพ็คเกจ แพ็คเกจนั้นเป็นชื่อที่สมเหตุสมผล แต่ไม่ได้จริงๆ อยู่ใน npm ในช่วงหนึ่งชั่วโมง ผู้โจมตีจดทะเบียนมันและเติมโค้ด retry ที่ทำงานได้พร้อมกับสคริปต์หลังติดตั้งที่อ่าน ~/.aws/credentials และโพสต์ไปยังเว็บฮุก ตัวแทนเรียกใช้ npm install โดยไม่ตรวจสอบ เพราะตัวแทนทำงานโดยไม่ตรวจสอบเครดิตเชลล์หายไปก่อนที่นักพัฒนาจะรันโค้ด

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

ช่วงเวลาตั้งแต่การเผยแพร่จนถึงการโจมตีคือวัดในนาที สิ่งใดๆ ที่ตรวจสอบหลังจากนั้นตรวจสอบสายเกินไป

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

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

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

คุณกล่าวว่าความปลอดภัยไม่สามารถเริ่มต้นที่ CI/CD ได้อีกต่อไป สิ่งที่คล้ายกับขั้นตอนความปลอดภัยสมัยใหม่เมื่อความปลอดภัยต้องเริ่มต้นเร็วขึ้นในกระบวนการพัฒนาคืออะไร?

หากความปลอดภัยเริ่มต้นที่ CI/CD คุณได้ยกมือในขั้นตอนก่อนการcommit แล้ว ตัวแทนได้ดึงบริบทแล้ว เครดิตเชลล์ของคุณอาจอยู่ในล็อกของใครบางคนแล้ว คุณกำลังตรวจสอบซาก

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

ตัวไปป์ไลน์ไม่ได้หายไป บทบาทของมันเปลี่ยนเป็นการตรวจสอบยืนยันว่าการควบคุมในขั้นต้นทำงานตามที่ตั้งใจไว้

เมื่อองค์กรต่างๆ ยังคงนำ AI coding agents มาใช้ คุณคิดว่าสิ่งที่สำคัญที่สุดคืออะไรที่พวกเขาต้องทำวันนี้เพื่อให้แน่ใจว่าสภาพแวดล้อมในการพัฒนาของพวกเขายังคงปลอดภัยในอีกไม่กี่ปีข้างหน้า?

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

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

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

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