การตรวจสอบรหัส ช่องโหว่ และความเสี่ยงของเอาท์พุต AI

กำไร:

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

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

ในที่นี้เราจะพิจารณา "การตรวจสอบความถูกต้อง" ในสามชั้น ได้แก่ ความถูกต้อง (โค้ดใช้งานได้จริงหรือไม่) ความปลอดภัย (ทนต่ออินพุตที่เป็นอันตรายหรือไม่) และแหล่งที่มา/ใบอนุญาต (ฉันมีสิทธิ์ใช้โค้ดนี้หรือไม่) แต่ละเลเยอร์มีวิธีการควบคุมของตัวเองและไม่มีใครสามารถข้ามไปได้ "นั่นคือสิ่งที่ AI พูด"

ความเสี่ยงสามชั้น

1. ความเสี่ยงต่อความถูกต้อง (ภาพหลอน) โมเดลอาจเรียกใช้ฟังก์ชันที่ไม่มีอยู่ ใช้ API ในทางที่ผิด และเลี่ยงผ่าน Edge Case โดยไม่ต้องแจ้งให้ทราบ รหัสดู "สมเหตุสมผล" แต่ไม่ถูกต้อง ยาแก้พิษ: การรวบรวม การทดสอบ การวิเคราะห์ทางสถิต และการตรวจสอบด้วยภาพ

2. ความเสี่ยงด้านความปลอดภัย AI สามารถทำซ้ำรูปแบบที่ไม่ปลอดภัยในข้อมูลการฝึกอบรม: การสืบค้นที่เสี่ยงต่อการแทรก SQL, การป้อนข้อมูลของผู้ใช้ที่ไม่ได้รับการรับรองความถูกต้อง, การเข้ารหัสที่อ่อนแอ, การดีซีเรียลไลซ์ที่ไม่ปลอดภัย, การเปลี่ยนเส้นทางแบบเปิด รหัสใช้งานได้แต่เสี่ยงต่อการถูกโจมตี ยาแก้พิษ: การตรวจสอบที่เน้นความปลอดภัย เครื่องสแกนอัตโนมัติ (SAST) และการกำหนดรูปแบบการรักษาความปลอดภัยที่เป็นที่รู้จัก

3. ความเสี่ยงด้านแหล่งที่มา/ใบอนุญาต AI อาจสร้างเอาต์พุตที่คล้ายกับรหัสลิขสิทธิ์ที่มีลิขสิทธิ์หรือมีข้อจำกัดอย่างใกล้ชิด หรืออาจแนะนำการขึ้นต่อกันของลิขสิทธิ์ที่ไม่เหมาะสม ยาแก้พิษ: การตรวจสอบการพึ่งพาและใบอนุญาต การตรวจสอบความเป็นต้นฉบับ นโยบายองค์กร

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

ทีละขั้นตอน: ประตูการรับรองความถูกต้องแบบชั้น

1. อ่านด้วยความเข้าใจ เข้าใจโค้ดจริงๆ ก่อนที่จะยอมรับ อย่ารวมรหัสที่คุณไม่เข้าใจ หากคุณไม่สามารถอธิบาย "เหตุใดจึงใช้งานได้" แสดงว่ายังไม่ได้รับการตรวจสอบ
2. ตรวจสอบว่ามีอยู่จริง ยืนยันว่าทุกฟังก์ชัน, API และแพ็คเกจที่ใช้มีอยู่จริงและใช้อย่างถูกต้อง (ประตูประสาทหลอน)
3. เรียกใช้เครื่องมืออัตโนมัติ คอมไพเลอร์ linter (เครื่องสแกนสไตล์/ข้อผิดพลาด) ตัวตรวจสอบประเภท การทดสอบหน่วย และหากเป็นไปได้ SAST (การทดสอบความปลอดภัยของแอปพลิเคชันแบบคงที่ — เครื่องมือที่จะสแกนซอร์สโค้ดเพื่อหาช่องโหว่)
4. มองจากมุมมองด้านความปลอดภัย อินพุตได้รับการตรวจสอบหรือไม่ แบบสอบถามมีการกำหนดพารามิเตอร์หรือไม่ ความลับถูกฝังอยู่เหรอ? มีการควบคุมการอนุญาตหรือไม่?
5. ตรวจสอบแหล่งที่มาและใบอนุญาต การขึ้นต่อกันใหม่ได้รับอนุญาตหรือไม่ ผลลัพธ์ดูคล้ายกับโค้ดเบสที่รู้จักมากเกินไปหรือไม่
6. หากเป็นเรื่องสำคัญต่อความปลอดภัย โปรดขออนุมัติจากผู้เชี่ยวชาญ ต้องมีการตรวจสอบอย่างอิสระโดยวิศวกรที่มีความสามารถในด้านต่างๆ เช่น การรับรองความถูกต้อง การชำระเงิน การเข้ารหัส การควบคุมการเข้าถึง

มินิเคสสามอัน

กรณีที่ 1 — การฉีด SQL ติดอยู่ที่ประตูตรวจสอบ รหัสที่สร้างโดย AI ที่เชื่อมอินพุตของผู้ใช้เข้ากับแบบสอบถาม SQL โดยตรงสำหรับจุดสิ้นสุดการค้นหา ("... WHERE name = '" + q + "'") รหัสใช้งานได้และผ่านการทดสอบ การตรวจสอบที่เน้นความปลอดภัยและการสแกน SAST ตรวจพบสิ่งนี้ มันถูกแปลงเป็นแบบสอบถามแบบกำหนดพารามิเตอร์ (คำสั่งที่เตรียมไว้) หากไม่ถูกจับได้ ก็อาจเป็นช่องโหว่ของข้อมูลรั่วไหลแบบคลาสสิก

กรณีที่ 2 — แพ็คเกจภาพหลอน AI แนะนำแพ็คเกจ npm ที่ไม่มีอยู่จริง (fast-safe-parse) สำหรับงาน เมื่อผู้พัฒนาพยายามติดตั้ง ไม่พบแพ็คเกจ ที่แย่กว่านั้น: ในบางกรณี ผู้โจมตีสามารถเติมชื่อแพ็คเกจ "โกสต์" ดังกล่าวด้วยแพ็คเกจจริงและเป็นอันตรายได้ (ความสับสนในการพึ่งพา) บทเรียน: ตรวจสอบแต่ละแพ็คเกจที่แนะนำโดยเทียบกับการลงทะเบียนอย่างเป็นทางการและประวัติการดาวน์โหลด/การบำรุงรักษา

กรณีที่ 3 — ใบอนุญาตเข้ากันไม่ได้ ไลบรารีสหายที่ดีที่แนะนำโดย AI มีใบอนุญาตลิขสิทธิ์ที่เข้มงวดซึ่งเข้ากันไม่ได้กับใบอนุญาตผลิตภัณฑ์ของสถาบัน การสแกนใบอนุญาตการพึ่งพารายงานสิ่งนี้ ทีมงานได้เปลี่ยนใบอนุญาตด้วยทางเลือกที่เหมาะสม หากไม่มีการตรวจสอบ ภาระทางกฎหมายจะเกิดขึ้นในการจำหน่ายผลิตภัณฑ์

เทมเพลตที่คัดลอกได้สี่แบบ

การตรวจสอบตนเองก่อนเข้าเรียน:

ก่อนที่จะยอมรับโค้ดที่สร้างโดย AI ต่อไปนี้ ให้ตรวจสอบ:1) ทุกฟังก์ชัน/API/แพ็คเกจที่ใช้นั้นมีอยู่จริงหรือไม่ ตั้งค่าสถานะผู้ต้องสงสัย2) มีอินพุตที่ไม่ได้รับการตรวจสอบ, การต่อข้อมูล SQL/คำสั่ง, ความลับที่ฝังอยู่, crypto ที่อ่อนแอหรือไม่3) อะไรคือข้อบกพร่อง/กรณีขอบที่ยังไม่ได้แก้ไข?ติดป้ายกำกับการค้นพบแต่ละรายการว่า "แน่นอน / น่าจะเป็น" และเสนอแนะการแก้ไข{{code}}

การตรวจสอบที่เน้นความปลอดภัย:

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

การตรวจสอบการพึ่งพาและใบอนุญาต:

แสดงรายการการอ้างอิงที่เพิ่ม/แนะนำโดยโค้ดนี้ สำหรับแต่ละแพ็คเกจ: มีแพ็คเกจอยู่จริงหรือไม่ มีการบำรุงรักษาหรือไม่ ใบอนุญาตโดยทั่วไปจะเป็นอย่างไร (ต้องได้รับการยืนยัน) และจำเป็นจริง ๆ สำหรับโครงการหรือสามารถทำได้ด้วยเครื่องมือที่มีอยู่หรือไม่ {{รหัสหรือรายการการพึ่งพา}}

การจัดเก็บแบบหล่อที่ปลอดภัย (ในการผลิต):

เขียนโค้ดสำหรับ {{task}} กฎความปลอดภัยบังคับ: - ตรวจสอบ/ฆ่าเชื้ออินพุตภายนอกทั้งหมด - ใช้แบบสอบถามแบบกำหนดพารามิเตอร์ในการเข้าถึงฐานข้อมูลเท่านั้น - อย่าฝังความลับในโค้ด ถือว่าตัวแปรสภาพแวดล้อม/ตัวจัดการความลับ - อย่ากลืนข้อผิดพลาด พิจารณาอย่างมีความหมาย. อธิบายว่ารหัสปฏิบัติตามกฎเหล่านี้อย่างไรใน 3 รายการ

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

จุดอ่อน: "เขียนแบบสอบถามที่ค้นหาด้วยชื่อผู้ใช้" (รหัสที่เสี่ยงต่อการฉีดอาจเกิดขึ้น)

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

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

ชั้นการรับรองความถูกต้อง

เครื่องมือ/วิธีการ

“AI กล่าว” เพียงพอแล้วหรือยัง?

ความแม่นยำ

การรวบรวม การทดสอบ การตรวจสอบด้วยสายตา

ไม่

API/ความเป็นจริงของแพ็คเกจ

เอกสารอย่างเป็นทางการ/การควบคุมบันทึก

ไม่

ความปลอดภัย

SAST การตรวจสอบความปลอดภัย

ไม่

ใบอนุญาต/แหล่งที่มา

การตรวจสอบการพึ่งพาและใบอนุญาต

ไม่

ตรรกะที่มีความสำคัญต่อความปลอดภัย

ได้รับการอนุมัติจากวิศวกรผู้เชี่ยวชาญ

ไม่อย่างแน่นอน

ความรับผิดชอบไม่สามารถถ่ายโอนได้

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

เคล็ดลับ: สร้างรายการตรวจสอบสั้นๆ ในทีมของคุณที่คุณเรียกว่า “ประตูตรวจสอบสำหรับโค้ดที่สร้างโดย AI” (บิลด์ + การทดสอบ + การสแกนความปลอดภัย + การตรวจสอบด้วยภาพ) เมื่อประตูนี้กลายเป็นนิสัย การสูญเสียความเร็วจะน้อยที่สุดและลดความเสี่ยงได้สูงสุด

ข้อผิดพลาดทั่วไป

• สับสนระหว่าง "งาน" กับ "ปลอดภัย" รหัสที่ผ่านการทดสอบอาจเสี่ยงต่อการถูกโจมตี
• การใช้แพ็คเกจ/API โดยไม่ตรวจสอบ แพ็กเก็ตประสาทหลอนเสียหายและก่อให้เกิดความเสี่ยงด้านความปลอดภัย
• ข้ามเครื่องมืออัตโนมัติ Linter ตัวตรวจสอบประเภท และ SAST จับสิ่งที่มนุษย์พลาดได้ในราคาถูก
• ละเลยใบอนุญาต การขึ้นต่อกันของใบอนุญาตที่ไม่เหมาะสมสร้างภาระทางกฎหมายในการแจกจ่าย
• มอบความรับผิดชอบให้กับตัวรถ ทีมงานรับผิดชอบโค้ดในการผลิต “AI ทำได้” ไม่ใช่ข้อแก้ตัว

โดยสรุป

การยอมรับเอาต์พุต AI ต้องมีการตรวจสอบสามชั้น: ความถูกต้อง (คอมไพล์ การทดสอบ การตรวจสอบด้วยภาพ) ความปลอดภัย (SAST และการตรวจสอบที่เน้นความปลอดภัย) และแหล่งที่มา/ใบอนุญาต (การตรวจสอบการขึ้นต่อกัน) ยืนยันว่าแต่ละแพ็คเกจและ API ที่ใช้มีอยู่จริง บังคับใช้รูปแบบความปลอดภัยตั้งแต่เริ่มต้น และส่งรหัสที่มีความสำคัญต่อความปลอดภัยเพื่อขออนุมัติโดยวิศวกรที่มีคุณสมบัติ “ผลงาน” ไม่ได้หมายความว่าปลอดภัย และ “AI ที่ผลิต” ไม่ได้ขจัดความรับผิด ประตูตรวจสอบคือราคาของความเป็นมืออาชีพ ไม่ใช่ความเร็ว

งานสมัคร

จงใจให้งานที่ต้องคำนึงถึงความปลอดภัยแก่ AI (เช่น “ฟังก์ชันที่ค้นหาฐานข้อมูลด้วยการป้อนข้อมูลของผู้ใช้”) ในครั้งนี้โดยไม่กำหนดรูปแบบที่ปลอดภัย ส่งรหัสที่เข้ามาผ่านเทมเพลต "การตรวจสอบตนเองก่อนเข้ารับการรักษา" และ "การตรวจสอบที่เน้นความปลอดภัย": มีการแทรกข้อมูล ความลับที่ฝังไว้ แพ็กเก็ตภาพหลอน หรือการป้อนข้อมูลที่ไม่ผ่านการรับรองความถูกต้องหรือไม่ จากนั้นถามคำถามเดิมอีกครั้งด้วยเทมเพลต "การกำหนดรูปแบบที่ปลอดภัย" และเปรียบเทียบผลลัพธ์ทั้งสอง หากเป็นไปได้ ให้เรียกใช้เครื่องมือ linter/SAST และเปรียบเทียบสิ่งที่ค้นพบกับการควบคุมตนเองของ AI

รายการตรวจสอบ

• [ ] ฉันตรวจสอบเอาต์พุต AI ในสามชั้น: ความแม่นยำ ความปลอดภัย และใบอนุญาต
• [ ] ฉันขอยืนยันว่าทุกฟังก์ชัน, API และแพ็คเกจที่ใช้นั้นมีอยู่จริง
• [ ] ฉันรันคอมไพล์ ทดสอบ linter และหากเป็นไปได้ เครื่องมือ SAST
• [ ] ฉันกำหนดรูปแบบการรักษาความปลอดภัย (การสืบค้นแบบมีพารามิเตอร์ การตรวจสอบอินพุต การจัดการความลับ) ตั้งแต่ต้น
• [ ] ฉันตรวจสอบใบอนุญาตและข้อกำหนดของการขึ้นต่อกันใหม่
• [ ] ฉันกำลังส่งรหัสที่มีความสำคัญต่อความปลอดภัยเพื่อขออนุมัติจากวิศวกรที่มีความสามารถ และฉันเข้าใจว่าฉันเป็นผู้รับผิดชอบ