การตรวจสอบโค้ดที่ปลอดภัยและการวิเคราะห์แบบคงที่: การค้นหาช่องโหว่ด้วยปัญญาประดิษฐ์

กำไร:

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

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

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

ขั้นตอนการตรวจสอบโค้ด

1. ให้ขอบเขตและบริบท ภาษาใด, เฟรมเวิร์กใด, โค้ดนี้รับอินพุตที่ไหน, ให้เอาท์พุตที่ไหน, ทำงานที่เลเยอร์ใด การตรวจสอบโค้ดโดยไม่มีบริบทก่อให้เกิดผลบวกลวง
2. สแกนหารูปแบบที่เป็นอันตราย ค้นหาคลาสช่องโหว่ของ AI ที่รู้จัก (เช่น OWASP Top 10): การแทรก การรับรองความถูกต้อง การเปิดเผยข้อมูลที่ละเอียดอ่อน การควบคุมการเข้าถึง
3. ให้แต่ละข้อค้นพบมีความสมเหตุสมผล สำหรับแต่ละแฟล็ก: บรรทัดไหน ระดับช่องโหว่ใด สามารถนำไปใช้ประโยชน์ได้อย่างไร มีหลักฐานอะไรบ้าง การค้นพบที่ไม่ยุติธรรมจะไม่ได้รับการพิจารณาอย่างจริงจัง
4. กำจัดผลบวกลวง ข้อมูลเข้าถูกล้างจริงหรือไม่ เส้นทางนั้นเข้าถึงได้จริงหรือไม่ — ตรวจสอบกับบริบท
5. ตรวจสอบการแก้ไข ยืนยันว่าแพตช์ที่แนะนำโดย AI ปิดช่องโหว่ได้จริง ไม่ทำให้เกิดช่องโหว่/จุดบกพร่องใหม่ๆ และผ่านการทดสอบแล้ว
6. การอนุมัติของมนุษย์ นักพัฒนาซอฟต์แวร์ + ผู้เชี่ยวชาญด้านความปลอดภัยจะตรวจสอบการค้นพบและแก้ไข นั่นคือวิธีที่มันเข้าสู่ที่เก็บโค้ด

เงื่อนไข: SAST (การทดสอบความปลอดภัยของแอปพลิเคชันแบบคงที่ — การทดสอบความปลอดภัยแบบคงที่ที่วิเคราะห์ซอร์สโค้ดโดยไม่ต้องรัน) DAST (ไดนามิก — การทดสอบแบบไดนามิกที่ทดสอบแอปพลิเคชันที่ทำงานอยู่ภายนอก) OWASP Top 10 คือรายการมาตรฐานของช่องโหว่บนเว็บแอปพลิเคชันที่พบบ่อยที่สุด การแทรกเป็นช่องโหว่ที่เกิดจากการตีความอินพุตของผู้ใช้เป็นคำสั่ง/การสืบค้น (เช่น การแทรก SQL) แบบสอบถามแบบกำหนดพารามิเตอร์เป็นวิธีที่ถูกต้องที่ป้องกันการแทรกโดยการแยกอินพุตออกจากโค้ด

ตารางประเภทช่องโหว่ทั่วไป

ระดับช่องโหว่

อาการ (เป็นรหัส)

ทางออกที่ถูกต้อง

กับดักของเอไอ

การฉีด SQL

การรวมอินพุตเข้ากับแบบสอบถาม

แบบสอบถามแบบกำหนดพารามิเตอร์

สามารถละเลยการฆ่าเชื้อได้

ความลับแบบฮาร์ดโค้ด

รหัสผ่าน/รหัสเข้า

ตู้เซฟ (ห้องนิรภัย) สภาพแวดล้อม

ผลบวกลวง (ตัวอย่าง/การทดสอบ)

การรับรองความถูกต้องที่อ่อนแอ

การควบคุมหายไป/ไม่ถูกต้อง

การควบคุมแบบรวมศูนย์ที่ทรงพลัง

พลาดบริบท

การควบคุมการเข้าถึงผิดพลาด

ไม่มีการตรวจสอบการอนุญาต

การอนุญาตฝั่งเซิร์ฟเวอร์

ไม่เข้าใจการไหลที่ซับซ้อน

การเปิดเผยข้อมูลที่ละเอียดอ่อน

พื้นที่เก็บข้อมูล/การบันทึกแบบไม่มีรหัสผ่าน

การเข้ารหัส การปกปิด

ไม่สามารถรู้ถึงความวิพากษ์วิจารณ์ได้

การทำให้เป็นอนุกรมไม่ปลอดภัย

ดีซีเรียลไลซ์ข้อมูลที่ไม่น่าเชื่อถือ

การแยกวิเคราะห์ที่ปลอดภัย

พลาดลายหายาก

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

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

กรณีที่ 2 — ความลับคงที่เชิงบวกเท็จ AI เห็นบรรทัดรหัสผ่าน = "test1234" ในไฟล์และระบุว่า "สำคัญ: รหัสผ่านฮาร์ดโค้ด" นักพัฒนาตรวจสอบบริบท: นี่คือไฟล์ทดสอบหน่วย ข้อมูลทดสอบจำลอง ไม่ได้เผยแพร่สู่การใช้งานจริงและไม่ได้ย้ายไปยังระบบจริง การค้นพบนี้เป็นผลบวกลวง นักพัฒนาจัดทำเอกสารนี้แต่ไม่ได้ดำเนินการใดๆ เนื่องจากไม่ใช่ความลับที่แท้จริง บทเรียน: สัญญาณ "ความลับสุดยอด" ของ AI จะต้องถูกกำจัดตามบริบท ไม่ใช่ทุกสายจะเป็นความลับ

กรณีที่ 3 — การแก้ไขช่องโหว่ใหม่ AI เสนอการแก้ไขช่องโหว่ XSS (cross-site scripting) แต่รหัสที่เขาแนะนำจะล้างอินพุตผิดที่และข้ามการเข้ารหัสเอาต์พุตในพื้นที่อื่น ส่งผลให้ช่องว่างปิดไม่สนิท ผู้เชี่ยวชาญด้านความปลอดภัยตรวจสอบการแก้ไข สังเกตเห็นโค้ดที่หายไป และแก้ไขในเลเยอร์ที่ถูกต้อง บทเรียน: แพตช์ที่ AI แนะนำนั้นไม่ปลอดภัยโดยอัตโนมัติ ทุกการแก้ไขได้รับการตรวจสอบและทดสอบแล้ว

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

พรอมต์ที่อ่อนแอ:

รหัสนี้มีช่องโหว่ แก้ไขได้ไหม: [รหัส]

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

พรอมต์อันทรงพลัง:

บทบาทของคุณ: ผู้ช่วยที่เป็นตาที่สองของนักพัฒนาในการตรวจสอบโค้ดที่ปลอดภัย การตัดสินใจ พิจารณาใช้การแก้ไขโดยตรง รหัส: [ระบุภาษา/เฟรมเวิร์ก] บริบท: ฟังก์ชันนี้ [แหล่งอินพุต: เช่น รับ [คำขอ HTTP ภายนอก] เขียนไปที่ [ปลายทางเอาต์พุต] งานของคุณ: (1) ทำเครื่องหมายช่องโหว่ที่เป็นไปได้ด้วยคลาส OWASP ระบุหมายเลขบรรทัด + เหตุใดจึงมีความเสี่ยง + วิธีการหาประโยชน์ + หลักฐานสำหรับแต่ละกรณี (2) เขียนสถานการณ์ผลบวกลวงอย่างน้อย 1 รายการสำหรับการค้นพบแต่ละครั้ง (เช่น หากอินพุตถูกทำให้สะอาดในอีกเลเยอร์หนึ่ง) (3) แนะนำการแก้ไขแต่ใช้เครื่องหมาย "[ตรวจสอบ + เขียนการทดสอบ]"; ประเมินด้วยว่าการแก้ไขทำให้เกิดช่องโหว่/จุดบกพร่องใหม่ๆ หรือไม่ เพิ่มช่องโหว่ปลอม [รหัส]

การแจ้งที่รัดกุมให้บริบท ขอชั้นเรียนและหลักฐานของ OWASP คำถามผลบวกลวงและความเสี่ยงในการแก้ไข บังคับให้มีการตรวจสอบโดยมนุษย์

เทมเพลตพร้อมท์ที่คัดลอกได้

เทมเพลตสแกนช่องโหว่ ตรวจสอบโค้ด [ภาษา/เฟรมเวิร์ก] สำหรับ OWASP Top 10 สำหรับการค้นหาที่เป็นไปได้แต่ละรายการ: หมายเลขบรรทัด คลาสช่องโหว่ เหตุใดจึงมีความเสี่ยง ตัวอย่างการหาประโยชน์ ความแข็งแกร่งของหลักฐาน (แน่นอน/น่าจะ/อ่อนแอ) บริบท: อินพุต [แหล่งที่มา] เอาต์พุต [เป้าหมาย] การเพิ่มการค้นพบที่ประดิษฐ์ขึ้น หากคุณไม่แน่ใจ ให้พิมพ์ "[ต้องตรวจสอบ]" รหัส: [วาง]

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

แก้ไขเทมเพลตการประเมิน แนะนำการแก้ไขสำหรับช่องโหว่ต่อไปนี้ จากนั้นวิจารณ์การแก้ไขของคุณเอง: (1) มันปิดช่องโหว่ได้จริงหรือไม่ (2) มันทำให้เกิดช่องโหว่/ข้อบกพร่องใหม่หรือไม่ (3) ฉันควรเขียนการทดสอบใด (กรณีบวกและลบ) (4) ผลกระทบต่อประสิทธิภาพ/ฟังก์ชันการทำงาน ฉันจะตรวจสอบและทดสอบการแก้ไข ช่องโหว่ + รหัส: [วาง]

เทมเพลตการสอนรูปแบบที่ปลอดภัยสำหรับคลาสที่มีช่องโหว่ [เช่น การแทรก SQL] เปรียบเทียบแสดงรูปแบบการพิมพ์ที่ปลอดภัยและรูปแบบที่ผิดพลาดทั่วไปในภาษา/กรอบงานนี้ กฎทั่วไป + ให้ตัวอย่างโค้ด แต่ฉันต้องการให้คุณถามบริบทก่อนนำไปใช้ในโค้ดของฉัน ภาษา/กรอบงาน: [เขียน]

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

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

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

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

โดยสรุป

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

งานสมัคร

ใช้ตัวอย่างโค้ด (ลบส่วนที่ละเอียดอ่อนออกจากโค้ดของคุณเองหรือโค้ดตัวอย่างที่มีช่องโหว่) ให้ AI ตรวจสอบด้วยเทมเพลต “การสแกนช่องโหว่” ใช้เทมเพลต "False Positive Elimination" สำหรับการค้นพบแต่ละครั้งและกำจัดสิ่งที่มีอยู่จริง แก้ไขสิ่งที่ค้นพบที่ร้ายแรงที่สุดด้วยเทมเพลต "การประเมินการฟื้นฟู" ทบทวนด้วยตัวเอง และเขียนกรณีทดสอบเชิงบวก + หนึ่งกรณีทดสอบเชิงลบ สังเกตว่ามีการค้นพบที่เป็นผลบวกลวงจำนวนเท่าใด

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

• [ ] ฉันให้ภาษา กรอบงาน และบริบทอินพุต/เอาท์พุตก่อนที่จะตรวจสอบโค้ด
• [ ] ฉันขอหมายเลขบรรทัด ระดับช่องโหว่ เส้นทางการหาประโยชน์ และหลักฐานสำหรับการค้นพบแต่ละครั้ง
• [ ] ฉันคัดกรองการค้นพบแต่ละครั้งเพื่อหาผลบวกลวงพร้อมบริบท
• [ ] ฉันไม่ได้ใช้การแก้ไขของ AI แบบสุ่มสี่สุ่มห้า ฉันทบทวนและเขียนแบบทดสอบ
• [ ] แม้ว่าผลลัพธ์จะออกมาเป็น "ไม่มีช่องโหว่" แต่ฉันก็ได้ตรวจสอบเส้นทางวิกฤติด้วยตัวเอง
• [ ] ฉันไม่เปิดเผยชื่อรหัส/ความลับ หรือใช้เครื่องมือแยกส่วนขององค์กร
• [ ] ฉันได้ผ่านการค้นพบและแก้ไขผ่านนักพัฒนาและการอนุมัติด้านความปลอดภัยแล้ว