สร้าง threat model สำหรับ workflow การพัฒนาด้วย AI
เรียนจบแล้วทำแผนผังทรัพย์สิน ขอบเขตความเชื่อถือ และความผิดพลาดที่อาจเกิด เลือกมาตรการควบคุมและ test สำหรับสถานการณ์พัฒนาที่เจาะจง
เผยแพร่โดย Taigaวิธีเขียนเนื้อหาของเรา
ตรวจความเข้าใจทะเบียนภัยคุกคามระบุว่า “ความเสี่ยง AI: สูง” โดยไม่มีรายละเอียด ควรเพิ่มอะไรก่อนทำแบบฝึกหัด
สิ่งที่จะได้เรียนรู้
- วาดระบบการพัฒนาให้ครอบคลุมมากกว่าตัวแอปพลิเคชัน
- อธิบายภัยคุกคามที่ชัดเจนด้วยผู้ดำเนินการ การดำเนินการ และผลกระทบ
- เปลี่ยนภัยคุกคามเป็นมาตรการควบคุมที่มีผู้รับผิดชอบและขั้นตรวจสอบ
เลือกสถานการณ์ขอบเขตจำกัด
เริ่มจาก workflow หนึ่งที่คนเข้าใจได้ เช่น agent อ่าน issue แก้ repository รัน test และเปิด pull request รวมระบบที่ทำให้การดำเนินการเหล่านี้เกิดขึ้นได้
ระบุทรัพย์สินที่สำคัญ ได้แก่ source code ข้อมูลลูกค้า ข้อมูลรับรอง artifact สำหรับ release และความพร้อมใช้งานบริการ ระบุผู้รับผิดชอบ จากนั้นระบุคนและระบบที่อ่านหรือเปลี่ยนทรัพย์สินแต่ละอย่างได้
OWASP แนะนำให้จำลองระบบ ระบุภัยคุกคาม เลือกวิธีตอบสนอง และตรวจสอบผล ใช้วิธีนี้ตั้งแต่ต้นและอัปเดตเมื่อระบบเปลี่ยน ดู แนวทาง threat modeling
วาดขอบเขตความเชื่อถือ
สำหรับ workflow สมมติจาก issue ไปสู่ PR ให้วาดการเชื่อมต่อเหล่านี้
Issue → agent → repository → test runner → artifact store → deployment
เพิ่มผู้ให้บริการโมเดลและที่เก็บ secret ทำเครื่องหมายจุดที่เนื้อหามาจากแหล่งที่เชื่อถือได้น้อยกว่า ทำเครื่องหมายจุดที่ตัวตนได้รับความสามารถใหม่ เช่น เปลี่ยนจากอ่าน issue เป็นเขียนไฟล์ repository
แผนภาพแอปพลิเคชันอย่างเดียวไม่แสดงความเสี่ยงการพัฒนาทั้งหมด ฐานข้อมูล production อาจเป็นส่วนตัว แต่ CI job อาจเปิดเผยข้อมูลรับรอง รวมสภาพแวดล้อมชั่วคราวและสิทธิ์ของฝ่ายช่วยเหลือเมื่อมีผลต่อสถานการณ์
เขียนเส้นทางความผิดพลาดที่ชัดเจน
หลีกเลี่ยงข้อความ เช่น “AI อาจไม่ปลอดภัย” เขียนผู้ดำเนินการ การดำเนินการ ทรัพย์สินที่ได้รับผลกระทบ และผลที่ตามมา รวมเงื่อนไขที่ต้องมีเพื่อให้สถานการณ์เกิดขึ้น
| สถานการณ์ | มาตรการควบคุมที่ต้องตรวจดู | หลักฐานที่ต้องขอ |
|---|---|---|
| ข้อความ issue ชักนำ agent ไปยัง repository ที่ไม่เกี่ยวข้อง | ขอบเขต repository และเครื่องมือ | การเขียนนอก repository ของงานถูกปฏิเสธ |
| Test job ที่ยังไม่น่าเชื่อถืออ่านข้อมูลรับรอง production | ตัวตน job และการแยก secret | การตรวจ workflow และ test การปฏิเสธในสภาพแวดล้อมแยก |
| Deployment ใช้ artifact คนละตัวกับที่ตรวจทาน | ตัวตน artifact และกฎเลื่อน artifact ไปขั้นถัดไป | ค่า digest ตรงกันในบันทึกอนุมัติและ deployment |
| Migration ที่ล้มเหลวทำให้กู้บริการไม่ได้ | Compatibility และขั้นตอน restore | แบบฝึกกู้คืนด้วยข้อมูลสมมติที่เป็นตัวแทนได้ |
นี่เป็นตัวอย่าง ไม่ใช่รายการภัยคุกคามทั้งหมด ข้อมูล เครื่องมือ และสภาพแวดล้อมเดินระบบของคุณกำหนดสถานการณ์ที่เกี่ยวข้อง
เลือกวิธีตอบสนองพร้อมผู้รับผิดชอบ
จัดลำดับตามผลกระทบและโอกาสเผชิญภัยที่มีเหตุรองรับ อย่านำเสนอคะแนนตัวเลขราวกับมีความแม่นยำที่คุณยังไม่มี บันทึกความไม่แน่นอนและหลักฐานที่อาจเปลี่ยนลำดับความสำคัญ
วิธีตอบสนองอาจลบความสามารถที่เสี่ยง ลดขอบเขต เพิ่มมาตรการควบคุม หรือยอมรับความเสี่ยงที่เหลือตามที่กำหนด การยอมรับต้องมีผู้รับผิดชอบที่มีอำนาจและเหตุผล ไม่ควรเป็นข้อสรุปของ agent ที่ยังไม่ได้ตรวจทาน
เปลี่ยนวิธีตอบสนองที่เลือกเป็นงานพร้อมเงื่อนไขการยอมรับที่สังเกตได้ “ปรับปรุงความปลอดภัย agent” ตรวจสอบยาก “Test job อ่าน secret ของ production ไม่ได้” กำหนดขอบเขตที่ตรวจสอบได้
ทบทวนหลังการเปลี่ยนแปลงสำคัญ
Connector เส้นทางโมเดล สภาพแวดล้อม หรือสิทธิ์ใหม่อาจเปลี่ยน threat model เพิ่มการเปลี่ยนแปลงเหล่านี้ในเงื่อนไขทบทวน ใช้ incident และการประเมินที่ไม่ผ่านเพื่อปรับสมมติฐานด้วย
ลอง แบบฝึกหัดทบทวนความเสี่ยง เพื่อเปลี่ยนข้อมูล อำนาจ กลุ่มผู้ได้รับผล และเงื่อนไขกู้คืนของสถานการณ์ ผลลัพธ์เสนอคำถาม ไม่ได้แทน threat model เฉพาะระบบหรืออนุญาตให้ทำงาน
ทำแบบฝึกหัด
เปิดแบบฝึกหัดทบทวนความเสี่ยง เลือกข้อมูลภายใน การเขียน branch ผู้ใช้ภายนอก และการกู้คืนที่ยาก เลือกประเด็นกังวลหนึ่งข้อจากผลลัพธ์ เขียนผู้ดำเนินการ จุดเข้า ทรัพย์สินที่ได้รับผลกระทบ ผลที่ตามมา มาตรการควบคุม test การปฏิเสธ ผู้รับผิดชอบ และเงื่อนไขทบทวน
ดาวน์โหลดใบงาน (Markdown)การยกเลิกตัวเลือกนี้จะลบความคืบหน้าทั้งหมดที่บันทึกใน browser นี้
ความคืบหน้าอยู่ใน browser นี้ ไม่ใช้บัญชีและไม่ติดตามการใช้งาน