ความเสี่ยงด้านความปลอดภัยของ AI: สิ่งที่ทีม DevSecOps ต้องรู้เพื่อรักษาความปลอดภัยของระบบ AI
ความเสี่ยงด้านความปลอดภัยของ AI ไม่ได้จำกัดอยู่แค่พฤติกรรมของโมเดลหรือความเป็นส่วนตัวของข้อมูลอีกต่อไปแล้ว ปัจจุบัน ความเสี่ยงเหล่านี้ยังส่งผลกระทบต่อวิธีการเขียน ตรวจสอบ สร้าง และเผยแพร่ซอฟต์แวร์ด้วย เนื่องจากเครื่องมือเขียนโค้ด AI ระบบ AI ที่มีบทบาทเฉพาะ และเวิร์กโฟลว์ที่ขับเคลื่อนด้วย AI กำลังเข้ามามีบทบาทมากขึ้น SDLCทีม DevSecOps ต้องเผชิญกับความเสี่ยงรูปแบบใหม่ ได้แก่ โค้ดที่เขียนเร็วขึ้น ระบบอัตโนมัติที่รวดเร็วขึ้น และข้อผิดพลาดที่เกิดขึ้นเร็วขึ้น
อย่างไรก็ตาม นี่ไม่ได้หมายความว่าทีมควรชะลอการนำ AI มาใช้ แต่พวกเขาจำเป็นต้องมีมาตรการควบคุมความปลอดภัยที่สอดคล้องกับความเร็วของการพัฒนาที่ใช้ AI ช่วย ในคู่มือนี้ เราจะอธิบายถึงความเสี่ยงด้านความปลอดภัยของ AI ที่สำคัญที่สุด วิธีที่ความเสี่ยงเหล่านี้ปรากฏในขั้นตอนการทำงานด้านวิศวกรรมจริง และวิธีที่ทีมสามารถลดความเสี่ยงในด้านโค้ด การพึ่งพา และความลับต่างๆ ได้ pipelineและตัวแทน
หากต้องการทราบภาพรวมที่กว้างขึ้นเกี่ยวกับวิธีที่ AI เปลี่ยนแปลงภูมิทัศน์ของภัยคุกคาม โปรดดูคู่มือของเรา ความปลอดภัยทางไซเบอร์ของ AI.
ความเสี่ยงด้านความปลอดภัยของ AI มีอะไรบ้าง?
ความเสี่ยงด้านความปลอดภัยของ AI คือจุดอ่อน ภัยคุกคาม หรือรูปแบบความล้มเหลวที่ปรากฏขึ้นเมื่อปัญญาประดิษฐ์ได้รับการออกแบบ ฝึกฝน บูรณาการ หรือใช้งานภายในระบบจริง ความเสี่ยงเหล่านี้อาจส่งผลกระทบต่อโมเดล ข้อมูล ข้อความแจ้งเตือน API และโค้ด pipelineและเครื่องมือที่เชื่อมต่อสิ่งเหล่านั้นเข้าด้วยกัน
การขอ แนวทางของ NCSC เกี่ยวกับ AI และความปลอดภัยทางไซเบอร์ อธิบายว่าความปลอดภัยทางไซเบอร์เป็นข้อกำหนดหลักสำหรับระบบ AI ที่ปลอดภัยและเชื่อถือได้ ในทำนองเดียวกัน กรอบการบริหารความเสี่ยง NIST AI ช่วยให้องค์กรมีโครงสร้างในการจัดการความเสี่ยงจาก AI ผ่านการกำกับดูแล การวัดผล และการควบคุมที่เป็นรูปธรรม
สำหรับทีม DevSecOps ปัญหาจะมีความเฉพาะเจาะจงมากขึ้น AI ได้กลายเป็นส่วนหนึ่งของห่วงโซ่การส่งมอบซอฟต์แวร์แล้ว มันเขียนโค้ด แนะนำการพึ่งพา สร้างการกำหนดค่า เรียกใช้ API และบางครั้งก็ทำงานอย่างอิสระ ดังนั้น ความเสี่ยงด้านความปลอดภัยของ AI จึงต้องได้รับการจัดการภายในองค์กร SDLCไม่ใช่แค่ในระดับโมเดลเท่านั้น
เหตุใดความเสี่ยงด้านความปลอดภัยของ AI จึงแตกต่างออกไปในปัจจุบัน
ความเสี่ยงด้านความปลอดภัยทางไซเบอร์แบบดั้งเดิมมักเกิดจากโค้ดที่เขียนโดยมนุษย์ แพ็กเกจที่มีช่องโหว่ ข้อมูลประจำตัวที่ไม่ปลอดภัย หรือโครงสร้างพื้นฐานที่ตั้งค่าไม่ถูกต้อง ความเสี่ยงเหล่านั้นยังคงมีอยู่ แต่ปัญญาประดิษฐ์ (AI) เปลี่ยนแปลงความเร็วในการปรากฏของความเสี่ยงเหล่านั้น และความยากในการตรวจจับ
โค้ดที่สร้างโดย AI อาจดูถูกต้อง แต่ก็ยังอาจพลาดการตรวจสอบสิทธิ์ได้ ผู้ช่วยเขียนโค้ด AI อาจแนะนำแพ็กเกจที่มีช่องโหว่ กระบวนการทำงานอัตโนมัติอาจเรียกใช้เครื่องมือผิด เข้าถึงไฟล์ผิด หรือเปิดเผยความลับในบันทึก นอกจากนี้ ระบบ AI มักขึ้นอยู่กับบริบท ข้อความแจ้ง ตัวเชื่อมต่อ และเครื่องมือภายนอก ซึ่งสร้างจุดอ่อนด้านความปลอดภัยได้มากขึ้น
การขอ OWASP Top 10 สำหรับการสมัครเรียน LLM เน้นย้ำถึงความเสี่ยงต่างๆ เช่น การฉีดข้อมูลอย่างรวดเร็ว การเปิดเผยข้อมูลที่ละเอียดอ่อน ปัญหาในห่วงโซ่อุปทาน และอำนาจการตัดสินใจที่มากเกินไป หมวดหมู่เหล่านี้มีประโยชน์เพราะเชื่อมโยงพฤติกรรมของ AI กับปัญหาด้านความปลอดภัยของแอปพลิเคชันจริง
กล่าวอีกนัยหนึ่ง ความเสี่ยงด้านความปลอดภัยของ AI ไม่ได้เกี่ยวข้องกับตัวโมเดลเพียงอย่างเดียว แต่เกี่ยวข้องกับระบบทั้งหมดที่อยู่รอบๆ โมเดลนั้นด้วย
ความเสี่ยงด้านความปลอดภัยของ AI ที่สำคัญสำหรับทีม DevSecOps
ด้านล่างนี้คือความเสี่ยงที่สำคัญที่สุดเมื่อมีการใช้ AI ในการพัฒนาแอปพลิเคชัน การรักษาความปลอดภัยแอปพลิเคชัน และอื่นๆ CI/CD เวิร์กโฟลว์
1. ช่องโหว่ของโค้ดที่สร้างโดย AI
เครื่องมือเขียนโค้ด AI สามารถสร้างโค้ดที่ใช้งานได้ แต่ไม่ปลอดภัย ตัวอย่างเช่น อาจสร้างคำสั่ง SQL โดยไม่มีการกำหนดพารามิเตอร์ที่เหมาะสม ข้ามการตรวจสอบความถูกต้องของข้อมูล หรือใช้ตรรกะการตรวจสอบสิทธิ์ที่อ่อนแอ
เหตุการณ์นี้เกิดขึ้นเนื่องจากระบบ AI จำนวนมากสร้างรูปแบบโค้ดที่น่าจะเป็นไปได้โดยอิงจากข้อมูลการฝึกฝน อย่างไรก็ตาม โค้ดที่น่าจะเป็นไปได้นั้นไม่ได้หมายความว่าเป็นโค้ดที่ปลอดภัยเสมอไป ในทางปฏิบัติ โมเดลอาจสร้างตัวอย่างที่ไม่ปลอดภัยขึ้นมาใหม่ เนื่องจากตัวอย่างเหล่านั้นพบได้ทั่วไปในคลังเก็บข้อมูลสาธารณะ
ตัวอย่างทั่วไป ได้แก่ :
- การแทรก SQL
- การเขียนสคริปต์ข้ามไซต์
- การตรวจสอบการอนุญาตไม่ครบถ้วน
- การจัดการเซสชันที่อ่อนแอ
- การดีซีเรียลไลซ์ที่ไม่ปลอดภัย
- ขาดการป้องกัน CSRF
ดังนั้น โค้ดที่สร้างโดย AI จึงควรได้รับการพิจารณาว่าไม่น่าเชื่อถือจนกว่าจะผ่านการทดสอบ SASTรวมถึงการตรวจสอบนโยบายและการทบทวน
คำแนะนำการเชื่อมโยงภายใน: เชื่อมโยงส่วนนี้กับโพสต์ของคุณบน AI SAST.
2. ความเสี่ยงด้านห่วงโซ่อุปทานและการพึ่งพา
เครื่องมือ AI ไม่ได้แค่สร้างโค้ดเท่านั้น แต่ยังแนะนำแพ็กเกจ เวอร์ชัน สคริปต์ และคำสั่งติดตั้งด้วย ซึ่งทำให้เกิดเส้นทางโดยตรงจากคำแนะนำของ AI ไปสู่ความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์
ตัวอย่างเช่น เครื่องมือ AI อาจแนะนำดังนี้:
- แพ็คเกจที่ล้าสมัย
- การพึ่งพาที่พิมพ์ผิด
- ชื่อแพ็คเกจที่เกิดจากภาพหลอน
- แพ็คเกจที่มีสคริปต์การติดตั้งที่น่าสงสัย
- ห้องสมุดที่เปราะบางแต่ยังคงถูกใช้งานอย่างแพร่หลาย
นอกจากนี้ ผู้โจมตีสามารถใช้ประโยชน์จากพฤติกรรมนี้ได้โดยการจดทะเบียนชื่อแพ็กเกจที่เครื่องมือ AI มีแนวโน้มที่จะคิดค้นขึ้นมา ความเสี่ยงนี้มักเรียกว่า slopsquatting ซึ่งเป็นการเปลี่ยนภาพลวงตาของแบบจำลองให้กลายเป็นการโจมตีห่วงโซ่อุปทานของแพ็กเกจ
เพื่อลดความเสี่ยงนี้ ทีมต่างๆ จำเป็นต้อง SCAรวมถึงการตรวจจับมัลแวร์ การบังคับใช้นโยบายการพึ่งพา และการวิเคราะห์การเข้าถึง นอกจากนี้ควรใช้สัญญาณการโจมตี เช่น กำไรต่อหุ้น และการแสวงหาประโยชน์อย่างแข็งขันจากข้อมูลข่าวกรอง CISแคตตาล็อกช่องโหว่ที่ถูกใช้ประโยชน์ที่ทราบแล้ว.
3. การเปิดเผยความลับในเวิร์กโฟลว์ AI
การเปิดเผยข้อมูลลับเป็นหนึ่งในความเสี่ยงด้านความปลอดภัยของ AI ที่พบได้บ่อยที่สุด นักพัฒนาซอฟต์แวร์มักใส่ข้อมูลบริบทลงในเครื่องมือ AI ซึ่งข้อมูลบริบทนั้นอาจรวมถึงคีย์ API โทเค็น ข้อมูลประจำตัว URL หรือการกำหนดค่าภายใน
นอกจากนี้ โค้ดที่สร้างโดย AI อาจมีตัวแทนที่ดูเหมือนจริง หรือที่แย่กว่านั้นคือ คัดลอกข้อมูลลับกลับเข้าไปในไฟล์ต้นฉบับ pipeline สคริปต์ หรือบันทึก เมื่อข้อมูลลับเข้าสู่ประวัติ Git แล้ว CI/CD แม้ว่าไฟล์บันทึกข้อมูลเหล่านั้นจะยังคงสามารถนำไปใช้ประโยชน์ได้อีกนานหลังจากที่ไฟล์ต้นฉบับถูกลบไปแล้วก็ตาม commit.
จุดที่อาจเกิดการสัมผัสกับสารอันตรายได้บ่อย ได้แก่:
- ประวัติการแจ้งเตือน
- รหัสที่สร้างขึ้น
- ไป commits
- CI/CD บันทึก
- IaC ไฟล์
- รูปภาพคอนเทนเนอร์
- พื้นที่ทำงานที่ใช้ร่วมกัน
ด้วยเหตุนี้ ทีมงานจึงควรผสานรวมการสแกนระดับ IDE เข้าด้วยกัน pre-commit การตรวจสอบ, การสแกนประวัติการจัดเก็บข้อมูล, CI/CD การสแกนบันทึก และการเพิกถอนอัตโนมัติ
คำแนะนำสำหรับการเชื่อมโยงภายใน: เชื่อมโยงส่วนนี้กับผลิตภัณฑ์รักษาความปลอดภัยข้อมูลลับของคุณหรือเนื้อหาที่เกี่ยวข้อง
4. การใช้ตัวแทนและเครื่องมือ AI ในทางที่ผิด
เอเจนต์เอไอ สิ่งนี้ก่อให้เกิดความเสี่ยงรูปแบบใหม่ เนื่องจากตัวแทนไม่ได้เพียงแค่เสนอแนะการกระทำเท่านั้น แต่ยังสามารถลงมือปฏิบัติเองได้ด้วย
เอージェนต์ AI อาจรันคำสั่งเชลล์ แก้ไขไฟล์ เรียกใช้ API เปิดไฟล์ และอื่นๆ pull requestsปรับเปลี่ยนเวิร์กโฟลว์ CI หรือโต้ตอบกับบริการคลาวด์ แม้ว่าสิ่งนี้จะช่วยเพิ่มประสิทธิภาพการทำงานได้อย่างมหาศาล แต่ก็เพิ่มขอบเขตของความผิดพลาดด้วยเช่นกัน
ความเสี่ยงที่สำคัญ ได้แก่ :
- การเรียกใช้เชลล์ที่ไม่ปลอดภัย
- คีย์ API ที่มีสิทธิ์มากเกินไป
- การแก้ไขโค้ดโดยไม่ได้รับอนุญาต
- การกำหนดค่า MCP หรือตัวเชื่อมต่อ API ไม่ถูกต้อง
- การเรียกใช้เครื่องมือที่อยู่นอกขอบเขตที่ได้รับอนุมัติ
- การเข้าถึงสภาพแวดล้อมเกินกว่าที่งานนั้นต้องการ
หมวดหมู่ OWASP LLM Top 10 สำหรับสิทธิ์การเข้าถึงที่มากเกินไปนั้นมีความเกี่ยวข้องอย่างยิ่งในกรณีนี้ หากเอเจนต์มีสิทธิ์การเข้าถึงมากเกินไป คำสั่งที่ไม่ถูกต้อง การฉีดข้อมูลแบบทันที หรือเครื่องมือที่ถูกบุกรุก อาจกลายเป็นเหตุการณ์ด้านความปลอดภัยที่ร้ายแรงได้
5. CI/CD และ Pipeline ความเสี่ยง
โค้ดที่สร้างโดย AI จะไปถึงในที่สุด pipelineณ จุดนั้น ความเสี่ยงจะเปลี่ยนจากซอร์สโค้ดไปสู่การสร้างโปรแกรม ไฟล์ผลลัพธ์ ข้อมูลลับ การพึ่งพา และขั้นตอนการทำงานของการปรับใช้
ตัวอย่างเช่น การเปลี่ยนแปลงที่ได้รับความช่วยเหลือจาก AI อาจมีลักษณะดังนี้:
- เพิ่มขั้นตอนการสร้างที่ไม่ปลอดภัย
- แก้ไขเวิร์กโฟลว์ GitHub Actions
- ดึงแพ็กเกจที่เป็นอันตรายระหว่างการติดตั้ง
- พิมพ์ข้อมูลลับลงในบันทึกการสร้าง
- ปิดใช้งานการควบคุมความปลอดภัย
- เปลี่ยนตรรกะการปรับใช้
ดังนั้น CI/CD การรักษาความปลอดภัยกลายเป็นสิ่งจำเป็นอย่างยิ่งสำหรับการนำ AI มาใช้ Pipeline guardrails ควรบล็อกรูปแบบที่ไม่ปลอดภัยก่อนที่จะนำไปใช้งานจริง สำหรับรายละเอียดเพิ่มเติม โปรดดูเนื้อหาของเราเกี่ยวกับ CI/CD ความปลอดภัย และ software supply chain security.
6. การรั่วไหลของข้อมูลและการฉีดข้อมูลอย่างรวดเร็ว
การแทรกข้อความแจ้งเตือน (Prompt injection) เป็นหนึ่งในความเสี่ยงด้านความปลอดภัยของ AI ที่รู้จักกันดีที่สุด แต่ก็มักจะถูกเข้าใจผิด ปัญหานี้ไม่ได้จำกัดอยู่แค่แชทบอทเท่านั้น แต่สามารถส่งผลกระทบต่อเวิร์กโฟลว์ AI ใดๆ ที่รับข้อมูลเข้าจากภายนอกแล้วนำข้อมูลนั้นไปใช้ในการชี้นำการกระทำได้
ตัวอย่างเช่น คำอธิบายปัญหาที่เป็นอันตราย ไฟล์ README ตั๋วสนับสนุน หรือหน้าเอกสารประกอบการพึ่งพา อาจมีคำสั่งที่ซ่อนอยู่ หากเอเจนต์ AI อ่านเนื้อหานั้นและปฏิบัติตาม ผู้โจมตีอาจมีอิทธิพลต่อการเรียกใช้เครื่องมือ การเปลี่ยนแปลงโค้ด หรือการเข้าถึงข้อมูลได้
การรั่วไหลของข้อมูลสามารถเกิดขึ้นได้ในลักษณะที่คล้ายคลึงกัน โมเดลอาจเปิดเผยบริบทที่ละเอียดอ่อน สรุปไฟล์ส่วนตัว หรือส่งข้อมูลที่เป็นความลับไปยังบริการภายนอก ดังนั้น ระบบ AI จึงต้องการการกรองที่รวดเร็ว การควบคุมผลลัพธ์ ข้อจำกัดของเครื่องมือ และขอบเขตที่ชัดเจนเกี่ยวกับข้อมูลที่ระบบสามารถเข้าถึงได้
ความเสี่ยงด้านความปลอดภัยของ AI ในด้านต่างๆ SDLC
ความเสี่ยงด้านความปลอดภัยของ AI ปรากฏขึ้นในขั้นตอนต่างๆ ของวงจรชีวิตซอฟต์แวร์ สิ่งสำคัญคือการรักษาความปลอดภัยในแต่ละขั้นตอน ไม่ใช่แค่แอปพลิเคชันที่เสร็จสมบูรณ์แล้วเท่านั้น
| SDLC ระยะ | ความเสี่ยงด้านความปลอดภัยของ AI | ตัวอย่าง | การควบคุมที่แนะนำ |
|---|---|---|---|
| IDE | โค้ดที่สร้างโดย AI ที่ไม่ปลอดภัย | ผู้ช่วยเขียนโค้ด AI แนะนำตรรกะการตรวจสอบสิทธิ์ที่ไม่ปลอดภัย | เรียลไทม์ SAST และให้ข้อเสนอแนะด้านการเขียนโค้ดที่ปลอดภัย |
| Commit | การเปิดเผยความลับ | โทเค็นปรากฏในโค้ดที่สร้างขึ้น หรือ commit ประวัติศาสตร์ | การตรวจจับความลับ pre-commit การตรวจสอบ และการเพิกถอนอัตโนมัติ |
| Pull Request | การหลีกเลี่ยงนโยบาย | โค้ดที่สร้างขึ้นจะเปลี่ยนแปลงกฎการควบคุมการเข้าถึงโดยไม่ผ่านการตรวจสอบ | PR guardrails และการบังคับใช้นโยบาย |
| สร้าง | การพึ่งพาที่เป็นอันตราย | แพ็กเกจที่แนะนำโดย AI มีพฤติกรรมการติดตั้งที่น่าสงสัย | SCAรวมถึงการตรวจจับมัลแวร์และการตรวจสอบนโยบายการพึ่งพา |
| CI/CD | Pipeline การจัดการ | เอเจนต์จะทำการแก้ไขไฟล์เวิร์กโฟลว์หรือสคริปต์การปรับใช้ | CI/CD การตรวจสอบความปลอดภัยและการตรวจจับความผิดปกติ |
| Runtime | การฉีดข้อมูลหรือการรั่วไหลของข้อมูลอย่างรวดเร็ว | ข้อมูลจากภายนอกทำให้กระบวนการทำงานของ AI เปิดเผยบริบทที่ละเอียดอ่อน | การควบคุมการแจ้งเตือน การจำกัดการเข้าถึง และการตรวจสอบ |
ความเสี่ยงด้านความปลอดภัยของ AI เทียบกับความเสี่ยงด้านความปลอดภัยทางไซเบอร์แบบดั้งเดิม
การรักษาความปลอดภัยทางไซเบอร์แบบดั้งเดิมยังคงมีความสำคัญ แต่ปัญญาประดิษฐ์ (AI) เพิ่มรูปแบบพฤติกรรมใหม่ๆ ที่ต้องใช้การควบคุมที่แตกต่างออกไป
| พื้นที่ | ความเสี่ยงด้านความปลอดภัยทางไซเบอร์แบบดั้งเดิม | ความเสี่ยงด้านความปลอดภัยของ AI |
|---|---|---|
| รหัส | ช่องโหว่ที่เกิดจากการกระทำของมนุษย์ | รูปแบบที่ไม่ปลอดภัยที่สร้างขึ้นโดย AI ด้วยความเร็วที่สูงขึ้น |
| การอ้างอิง | แพ็กเกจที่มีช่องโหว่ที่ทราบแล้ว | แพ็กเกจที่แนะนำโดย AI ซึ่งอาจเป็นการหลอกลวง เป็นอันตราย หรือไม่ปลอดภัย |
| ความลับ | ใส่ข้อมูลประจำตัวโดยไม่ได้ตั้งใจ commitพัฒนาโดยนักพัฒนา | ข้อมูลลับถูกคัดลอกลงในข้อความแจ้งเตือน โค้ดที่สร้างขึ้น หรือบันทึกต่างๆ |
| เครื่องมือ | การใช้งานเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์อย่างไม่ถูกต้องด้วยตนเอง | เอージェนต์อัตโนมัติที่ใช้เครื่องมือหรือ API ในทางที่ผิด |
| Pipelines | กำหนดค่าผิดพลาด CI/CD เวิร์กโฟลว์ | การเปลี่ยนแปลงเวิร์กโฟลว์ที่สร้างโดยเอเจนต์ หรือระบบอัตโนมัติที่ไม่ปลอดภัย |
ตัวอย่างความเสี่ยงด้านความปลอดภัยของ AI ในโลกแห่งความเป็นจริง
ความเสี่ยงด้านความปลอดภัยของ AI ไม่ใช่เรื่องสมมติ ปัจจุบันมีกรอบการทำงานและงานวิจัยสาธารณะหลายแห่งที่ติดตามประเด็นเหล่านี้อย่างเป็นทางการมากขึ้น
การขอ คลังข้อมูลความเสี่ยงด้าน AI ของ MIT แคตตาล็อกนี้รวบรวมความเสี่ยงด้าน AI มากกว่า 1,700 รายการ ครอบคลุมสาเหตุและโดเมนต่างๆ ในขณะเดียวกัน OWASP ก็ได้กำหนดหมวดหมู่ที่เป็นประโยชน์สำหรับความเสี่ยงในการใช้งาน LLM รวมถึงการโจมตีแบบทันที การเปิดเผยข้อมูลที่ละเอียดอ่อน ช่องโหว่ในห่วงโซ่อุปทาน และอำนาจการตัดสินใจที่มากเกินไป
สำหรับทีม DevSecOps ตัวอย่างที่เกี่ยวข้องมากที่สุดมักปรากฏในกระบวนการส่งมอบซอฟต์แวร์:
- เครื่องมือ AI ชี้ให้เห็นถึงโค้ดที่มีช่องโหว่
- เอเจนต์ AI ที่แก้ไขไฟล์เวิร์กโฟลว์
- ความสัมพันธ์ที่สร้างขึ้นโดย AI ก่อให้เกิดความเสี่ยงต่อห่วงโซ่อุปทาน
- ความลับที่รั่วไหลผ่านข้อความแจ้งเตือน บันทึก หรือ commits
- เวิร์กโฟลว์ของ Agentic ที่เรียกใช้เครื่องมือที่อยู่นอกขอบเขตที่ได้รับอนุมัติ
กล่าวโดยสรุป ความเสี่ยงด้านความปลอดภัยของ AI จะรุนแรงมากขึ้นเมื่อระบบ AI สามารถเข้าถึงโค้ด ข้อมูลประจำตัว และแพ็กเกจได้ pipelineหรือโครงสร้างพื้นฐาน
วิธีการลดความเสี่ยงด้านความปลอดภัยของ AI ในทางปฏิบัติ
วิธีที่ดีที่สุดในการลดความเสี่ยงด้านความปลอดภัยของ AI คือการมองว่าการพัฒนาโดยใช้ AI เป็นส่วนหนึ่งของกระบวนการทำงาน SDLCนั่นหมายถึงการสแกนตั้งแต่เนิ่นๆ การตรวจสอบความถูกต้องบ่อยครั้ง และการบังคับใช้ระเบียบข้อบังคับในสถานที่ทำงานจริงของนักพัฒนา
1. สแกนโค้ดที่สร้างโดย AI ใน IDE
นักพัฒนาควรเห็นข้อเสนอแนะด้านความปลอดภัยขณะที่กำลังเขียนหรือยอมรับโค้ดที่สร้างโดย AI ซึ่งจะช่วยลดการสลับบริบทและช่วยแก้ไขปัญหาได้ก่อนที่จะถึง Git
วิธีใช้:
- SAST ใน IDE
- คำอธิบายช่องโหว่แบบอินไลน์
- คำแนะนำการแก้ไขที่ปลอดภัย
- การแก้ไขปัญหาโดยคำนึงถึงนโยบาย
เรื่องนี้มีความสำคัญอย่างยิ่งสำหรับผู้ช่วยเขียนโค้ด AI เนื่องจากคำแนะนำที่ไม่ปลอดภัยอาจแทรกซึมเข้าไปในโค้ดได้อย่างรวดเร็ว
2. ตรวจสอบความถูกต้องของส่วนประกอบต่างๆ ก่อนทำการสร้างโปรเจกต์
ต้องตรวจสอบความสัมพันธ์ของแพ็กเกจที่ AI แนะนำก่อนที่จะติดตั้งหรือจัดส่ง ดังนั้น ทีมควรบังคับใช้มาตรการควบคุมความสัมพันธ์ของแพ็กเกจในระหว่างการพัฒนา CI/CD.
วิธีใช้:
- SCA
- การตรวจจับมัลแวร์
- การตรวจจับการปลอมแปลงเครื่องหมายถูก
- การให้คะแนน EPSS
- การวิเคราะห์การเข้าถึง
- การบล็อกตามนโยบาย
วิธีนี้ช่วยจัดลำดับความสำคัญของแพ็กเกจที่แสดงถึงความเสี่ยงที่แท้จริง ไม่ใช่แค่ความเสี่ยงเชิงทฤษฎีเท่านั้น
3. ตรวจจับและเพิกถอนข้อมูลลับโดยอัตโนมัติ
การสแกนหาความลับต้องครอบคลุมมากกว่าแค่ซอร์สโค้ด เวิร์กโฟลว์ที่ใช้ AI ช่วยเหลืออาจเปิดเผยข้อมูลประจำตัวได้ในหลายจุด
วิธีใช้:
- Pre-commit การสแกน
- การสแกนประวัติการเก็บข้อมูล
- Pipeline การสแกนบันทึก
- IaC การสแกน
- การสแกนภาพคอนเทนเนอร์
- การเพิกถอนอัตโนมัติ
ด้วยเหตุนี้ ทีมงานจึงสามารถลดระยะเวลาตั้งแต่การสัมผัสเชื้อจนถึงการควบคุมสถานการณ์ได้
4. บังคับใช้ Guardrails in CI/CD
Guardrails ควรตัดสินใจว่าการเปลี่ยนแปลงนั้นปลอดภัยเพียงพอที่จะดำเนินการต่อไปหรือไม่ การรายงานเป็นสิ่งที่มีประโยชน์ แต่การระงับเป็นสิ่งจำเป็นสำหรับความเสี่ยงที่สำคัญ
Guardrails ควรครอบคลุม:
- ช่องโหว่ร้ายแรงใหม่
- ความลับ
- การพึ่งพาที่เป็นอันตราย
- แพ็กเกจที่ไม่ได้ตรึงไว้หรือไม่น่าเชื่อถือ
- การเปลี่ยนแปลงเวิร์กโฟลว์ที่ไม่ปลอดภัย
- หายไป SBOMs
- การละเมิดนโยบาย
นอกจากนี้ ทีมควรเริ่มต้นด้วยโหมดรายงานอย่างเดียวเมื่อจำเป็น จากนั้นค่อยขยับไปใช้โหมดบล็อกเมื่อมีความมั่นใจมากขึ้น
5. ตรวจสอบพฤติกรรมของเครื่องมือตัวแทน
ระบบ AI ที่ทำงานอย่างอิสระจำเป็นต้องมีการตรวจสอบได้ หากเอเจนต์สามารถแก้ไขไฟล์ สั่งการสร้าง หรือเรียกใช้ API ทีมงานจำเป็นต้องรู้ว่าเอเจนต์ทำอะไร ทำเมื่อไหร่ และการกระทำนั้นเป็นไปตามที่คาดไว้หรือไม่
การตรวจสอบ:
- เครื่องมือเรียก
- การเปลี่ยนแปลงไฟล์เวิร์กโฟลว์
- กิจกรรมการเขียนที่เก็บข้อมูล
- ปลายทางเครือข่าย
- การเข้าถึงความลับ
- Pull request การสร้าง
- Pipeline ทริกเกอร์
หากปราศจากความโปร่งใสนี้ ความไว้วางใจในความเป็นอิสระของเอージェนต์ก็จะกลายเป็นเรื่องยาก
Xygeni ช่วยลดความเสี่ยงด้านความปลอดภัยของ AI ได้อย่างไร
Xygeni มุ่งเน้นการรักษาความปลอดภัยของการพัฒนาซอฟต์แวร์โดยใช้ AI ตลอดห่วงโซ่การส่งมอบซอฟต์แวร์ แทนที่จะมองความเสี่ยงจาก AI เป็นหมวดหมู่แยกต่างหาก แต่เชื่อมโยงโค้ด การพึ่งพา และความลับต่างๆ เข้าด้วยกัน pipelineและบริบททางธุรกิจ
ตัวอย่างเช่น:
- SAST ช่วยตรวจจับโค้ดที่สร้างโดย AI ที่ไม่ปลอดภัยได้ตั้งแต่เนิ่นๆ
- SCA ตรวจสอบความสัมพันธ์ของไฟล์และตรวจจับแพ็กเกจที่เป็นอันตราย
- ความลับด้านความปลอดภัย ตรวจจับข้อมูลประจำตัวที่ถูกเปิดเผยในแหล่งเก็บข้อมูลต่างๆ และ pipelines.
- CI/CD ความปลอดภัย บังคับใช้ระเบียบข้อบังคับก่อนที่จะมีการเปลี่ยนแปลงที่ไม่ปลอดภัยเกิดขึ้น
- การตรวจจับความผิดปกติ ระบุพฤติกรรมที่ผิดปกติในขั้นตอนการพัฒนาและการส่งมอบงาน
- ASPM รวบรวมข้อมูลต่างๆ เข้าไว้ในมุมมองความเสี่ยงเดียว เพื่อให้ทีมสามารถจัดลำดับความสำคัญในสิ่งที่สำคัญได้
เรื่องนี้สำคัญเพราะความเสี่ยงด้านความปลอดภัยของ AI นั้นมีลักษณะเป็นความเสี่ยงข้ามชั้น การพึ่งพาที่อ่อนแอ โทเค็นที่ถูกเปิดเผย และการเปลี่ยนแปลงเวิร์กโฟลว์ที่ไม่ปลอดภัย อาจดูเหมือนแยกจากกันในเครื่องมือเฉพาะจุด แต่เมื่อรวมกันแล้วอาจก่อให้เกิดเส้นทางการโจมตีที่ใหญ่กว่ามาก
กรอบการบริหารความเสี่ยงด้านความปลอดภัยของ AI ที่ควรรู้
มีกรอบการทำงานหลายอย่างที่ช่วยให้ทีมจัดโครงสร้างการทำงานของตนได้
การขอ กรอบการบริหารความเสี่ยง NIST AI ช่วยให้องค์กรสามารถวางแผน วัดผล จัดการ และกำกับดูแลความเสี่ยงด้าน AI ได้อย่างมีประสิทธิภาพ เป็นประโยชน์สำหรับฝ่ายบริหาร ฝ่ายปฏิบัติตามกฎระเบียบ และฝ่ายบริหารความเสี่ยง
การขอ OWASP Top 10 สำหรับการสมัครเรียน LLM วิธีนี้มีประโยชน์มากกว่าสำหรับทีมรักษาความปลอดภัยแอปพลิเคชัน (AppSec) เนื่องจากสอดคล้องโดยตรงกับความเสี่ยงทางเทคนิค เช่น การโจมตีแบบ Prompt Injection การเปิดเผยข้อมูลที่ละเอียดอ่อน ช่องโหว่ในห่วงโซ่อุปทาน และอำนาจการตัดสินใจที่มากเกินไป
การขอ คำแนะนำด้าน AI และความปลอดภัยทางไซเบอร์ของ NCSC เป็นประโยชน์สำหรับผู้นำด้านความปลอดภัยที่ต้องการเข้าใจว่า AI เปลี่ยนแปลงความเสี่ยงด้านไซเบอร์ขององค์กรอย่างไร
โดยรวมแล้ว แหล่งข้อมูลเหล่านี้แสดงให้เห็นประเด็นสำคัญประการหนึ่งอย่างชัดเจน นั่นคือ การรักษาความปลอดภัยของ AI ต้องได้รับการจัดการครอบคลุมทั้งบุคคล กระบวนการ ระบบ และขั้นตอนการส่งมอบซอฟต์แวร์
รายการตรวจสอบ: วิธีลดความเสี่ยงด้านความปลอดภัยของ AI
ใช้รายการตรวจสอบนี้เป็นจุดเริ่มต้นที่นำไปใช้ได้จริง
| พื้นที่ควบคุม | สิ่งที่ต้องทำ | ทำไมมันสำคัญ |
|---|---|---|
| รหัสที่สร้างโดย AI | วิ่ง SAST ใน IDE, PR และ CI/CD pipeline. | ป้องกันไม่ให้โค้ดที่ไม่ปลอดภัยเข้าสู่ระบบการใช้งานจริง |
| การอ้างอิง | ใช้ SCAรวมถึงการตรวจจับมัลแวร์, EPSS และการเข้าถึงได้ | บล็อกแพ็กเกจที่แนะนำโดย AI ที่มีความเสี่ยง |
| ความลับ | สแกน commitบันทึก, ประวัติ IaCและภาชนะบรรจุ | ลดความเสี่ยงจากการเปิดเผยข้อมูลประจำตัวและการนำข้อมูลไปใช้ในทางที่ผิด |
| CI/CD | บังคับใช้ pipeline guardrails และเกณฑ์กำหนดนโยบาย | ป้องกันการสร้างและการติดตั้งที่ไม่ปลอดภัย |
| เครื่องมือตัวแทน | ตรวจสอบการเรียกใช้เครื่องมือ การเข้าถึง API และการเปลี่ยนแปลงเวิร์กโฟลว์ | จำกัดอำนาจการตัดสินใจที่มากเกินไปและพฤติกรรมที่ไม่คาดคิด |
| การบริหารความเสี่ยง | ใช้ ASPM เพื่อเชื่อมโยงผลการค้นพบในแต่ละระดับ | ช่วยให้ทีมมุ่งเน้นไปที่ความเสี่ยงทางธุรกิจที่แท้จริง |
ประเด็นที่สำคัญ
- ความเสี่ยงด้านความปลอดภัยของ AI ในปัจจุบันส่งผลกระทบต่อโค้ด ส่วนประกอบ และข้อมูลลับ pipelineและตัวแทน
- เครื่องมือรักษาความปลอดภัยแอปพลิเคชันแบบดั้งเดิมยังคงจำเป็นอยู่ แต่ต้องใช้งานให้เร็วขึ้นและด้วยบริบทที่มากขึ้น
- โค้ดที่สร้างโดย AI ควรได้รับการพิจารณาว่าไม่น่าเชื่อถือจนกว่าจะได้รับการตรวจสอบความถูกต้อง
- เวิร์กโฟลว์ของเอเจนต์ AI จำเป็นต้องมี guardrailsสิทธิ์การเข้าถึง และความสามารถในการตรวจสอบ
- ทีม DevSecOps ต้องการการมองเห็นที่เป็นหนึ่งเดียวทั่วทั้งระบบ SDLC เพื่อจัดการความเสี่ยงด้าน AI อย่างมีประสิทธิภาพ
คำถามที่พบบ่อย: ความเสี่ยงด้านความปลอดภัยของ AI
ความเสี่ยงด้านความปลอดภัยของ AI มีอะไรบ้าง?
ความเสี่ยงด้านความปลอดภัยของ AI คือภัยคุกคามหรือจุดอ่อนที่ปรากฏขึ้นเมื่อมีการสร้าง บูรณาการ หรือใช้งานระบบ AI ความเสี่ยงเหล่านี้อาจส่งผลกระทบต่อโมเดล ข้อมูล ข้อความแจ้งเตือน โค้ด การพึ่งพา API และอื่นๆ pipelines.
ความเสี่ยงด้านความปลอดภัยของ AI ที่ใหญ่ที่สุดสำหรับทีม DevSecOps คืออะไร?
ความเสี่ยงที่ใหญ่ที่สุด ได้แก่ โค้ดที่สร้างโดย AI ที่ไม่ปลอดภัย การพึ่งพาที่เปราะบาง การเปิดเผยความลับ การโจมตีแบบ Prompt Injection สิทธิ์การเข้าถึงของเอเจนต์ที่มากเกินไป และความไม่ปลอดภัย CI/CD ระบบอัตโนมัติ
เหตุใดความเสี่ยงด้านความปลอดภัยของ AI จึงแตกต่างจากความเสี่ยงด้านความปลอดภัยทางไซเบอร์แบบดั้งเดิม?
ระบบ AI สามารถสร้างโค้ด แนะนำความสัมพันธ์ระหว่างส่วนประกอบ เรียกใช้เครื่องมือ และดำเนินการได้อย่างอิสระ ส่งผลให้ความเสี่ยงปรากฏขึ้นเร็วขึ้นและครอบคลุมหลายระดับมากขึ้น SDLC.
ทีมต่างๆ จะลดความเสี่ยงด้านความปลอดภัยของ AI ได้อย่างไร?
ทีมสามารถลดความเสี่ยงได้โดยการสแกนโค้ดที่สร้างโดย AI ตรวจสอบความถูกต้องของความสัมพันธ์ระหว่างส่วนประกอบต่างๆ ตรวจจับข้อมูลลับ และบังคับใช้กฎระเบียบ CI/CD guardrailsการติดตามพฤติกรรมของตัวแทน และการเชื่อมโยงผลการค้นพบผ่าน ASPM.
โค้ดที่สร้างโดย AI ปลอดภัยหรือไม่?
โดยพื้นฐานแล้วโค้ดที่สร้างโดย AI นั้นไม่ปลอดภัย ควรได้รับการตรวจสอบ สแกน ทดสอบ และตรวจสอบความถูกต้องก่อนนำไปใช้งานจริง
ข้อคิดส่งท้าย: ความเสี่ยงด้านความปลอดภัยของ AI จำเป็นต้องได้รับการพิจารณา SDLC-การควบคุมระดับ
ปัญญาประดิษฐ์ (AI) เปลี่ยนแปลงความเร็วและรูปแบบของความเสี่ยงด้านซอฟต์แวร์ ช่วยให้ทีมสร้างซอฟต์แวร์ได้เร็วขึ้น แต่ก็ยังนำมาซึ่งช่องทางใหม่ๆ ที่ทำให้โค้ดที่ไม่ปลอดภัย ข้อมูลลับที่ถูกเปิดเผย การพึ่งพาที่ไม่ปลอดภัย และระบบอัตโนมัติที่มีความเสี่ยง เข้ามาในห่วงโซ่การส่งมอบซอฟต์แวร์ได้
ดังนั้น การรักษาความปลอดภัยของ AI จึงไม่สามารถจัดการได้ด้วยการกำกับดูแลแบบจำลองหรือเอกสารนโยบายเพียงอย่างเดียว จำเป็นต้องมีการควบคุมที่เป็นรูปธรรมภายในตัวมันเอง SDLC: ข้อเสนอแนะจาก IDE SAST, SCAการตรวจจับความลับ CI/CD guardrailsการตรวจจับความผิดปกติ และ ASPMความสัมพันธ์ระดับ -
ทีมที่จัดการความเสี่ยงด้านความปลอดภัยของ AI ได้ดีจะไม่ใช่ทีมที่ขัดขวางการนำ AI มาใช้ แต่จะเป็นทีมที่สร้างชั้นความปลอดภัยที่เหมาะสมรอบๆ AI ต่างหาก
