ทำไม Codex Security ถึงไม่ใส่รายงาน SAST ไว้ในระบบ

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

แต่เมื่อเราพัฒนา Codex Security เราตั้งใจตัดสินใจเลือกแนวทางที่ต่างออกไป โดยปฏิเสธการใช้รายงานวิเคราะห์แบบสแตติกมาเป็นฐานข้อมูลเริ่มต้นเพื่อให้เอเจนต์ AI เข้าไปวิเคราะห์ความเสี่ยง เราออกแบบระบบให้เริ่มวิเคราะห์จาก Repository โดยตรง ทั้งในส่วนของสถาปัตยกรรม ขอบเขตความปลอดภัย และพฤติกรรมการทำงานที่ตั้งใจไว้ พร้อมทั้งตรวจสอบสิ่งที่ค้นพบให้ถูกต้อง ก่อนจะส่งต่อให้มนุษย์เข้ามาตรวจสอบต่อ 

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

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

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

ลำพังเหตุผลข้อนั้นเพียงอย่างเดียว ยังไม่ใช่สาเหตุที่แท้จริงว่าทำไม Codex Security ถึงเลือกที่จะไม่พึ่งพารายงาน SAST ในช่วงเริ่มต้นของการตรวจสอบ

ปัญหาที่สำคัญกว่านั้นอยู่ที่ขั้นตอนถัดไปคือ สิ่งที่จะเกิดขึ้นหลังจากที่คุณสามารถติดตามเส้นทางข้อมูลจากต้นทางไปจนถึงจุดรับข้อมูลได้สำเร็จ

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

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

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

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

นี่คือรูปแบบหนึ่งที่พบได้ในระบบจริงอยู่เสมอ

เว็บแอปพลิเคชันรับข้อมูลในรูปแบบ JSON แล้วดึงค่า redirect_url ออกมาตรวจสอบกับ Regex ที่กำหนดไว้ใน Allowlist จากนั้นจึงทำการถอดรหัส URL และส่งผลลัพธ์ไปยังส่วนจัดการการเปลี่ยนเส้นทาง

รูปแบบรายงานมาตรฐานที่ติดตามข้อมูลจากต้นทางสู่ปลายทาง จะช่วยระบุเส้นทางการเคลื่อนที่ของข้อมูลได้ดังนี้

อินพุตที่ไม่น่าเชื่อถือ → ตรวจสอบด้วย Regex → ถอดรหัส URL → เปลี่ยนเส้นทาง

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

หาก Regex ทำงาน ก่อนการถอดรหัส มันจะสามารถจำกัดค่าของ URL ที่ถูกถอดรหัสแล้วตามรูปแบบที่ส่วนจัดการรีไดเรกต์ตีความได้จริงหรือ

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

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

นี่ไม่ใช่แค่รูปแบบเชิงทฤษฎีเท่านั้น ใน CVE-2024-29041⁠(เปิดในหน้าต่างใหม่) พบว่า Express ได้รับผลกระทบจากช่องโหว่รีไดเรกต์ ซึ่ง URL ที่สร้างมาเพื่อหลอกระบบสามารถหลบเลี่ยงระบบตรวจสอบรายชื่อที่อนุญาตได้ได้สำเร็จ โดยอาศัยช่องว่างระหว่างขั้นตอนการเข้ารหัสกับการตีความปลายทาง เส้นทางการไหลของข้อมูลนั้นตรงไปตรงมาและไม่มีความซับซ้อน คำถามที่ยากกว่านั้น และเป็นตัวตัดสินว่ามีบั๊กอยู่จริงหรือไม่ คือการตรวจสอบนั้นยังคงมีผลบังคับใช้หรือไม่หลังจากข้อมูลผ่านการแปลงค่าทั้งหมดไปแล้ว

เราสร้าง Codex Security ขึ้นมาด้วยเป้าหมายที่เรียบง่าย คือการลดภาระในการคัดกรองช่องโหว่ ด้วยการแสดงผลลัพธ์ที่มีหลักฐานยืนยันหนักแน่นยิ่งขึ้น ในเชิงผลิตภัณฑ์ เราเลือกใช้บริบทเฉพาะของแต่ละ Repository (รวมถึงโมเดลภัยคุกคาม) และทดสอบประเด็นที่มีความเสี่ยงสูงในสภาพแวดล้อมที่แยกส่วนก่อนจะรายงานผล 

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

รูปแบบที่เกิดขึ้นจริงมักจะมาจากการรวมตัวกันของกระบวนการต่างๆ ต่อไปนี้

• ใช้วิธีอ่านเส้นทางของโค้ดที่เกี่ยวข้องโดยพิจารณาบริบททั้งหมดของ Repository เหมือนที่นักวิจัยด้านความปลอดภัยทำ เพื่อค้นหาความไม่สอดคล้องกันระหว่างเจตนารมณ์กับการเขียนโค้ดจริง ข้อมูลนี้ครอบคลุมถึงคอมเมนต์ในโค้ดด้วย แต่ตัวโมเดลไม่ได้หลงเชื่อคอมเมนต์เหล่านั้นเสมอไป ดังนั้นการใส่คำสั่ง //Halvar says: this is not a bug ไว้เหนือโค้ดจึงไม่สามารถหลอกระบบได้ หากมีบั๊กอยู่จริง
• ใช้วิธีตัดทอนปัญหาให้เหลือแค่ส่วนเล็กๆ ที่ตรวจเช็กได้จริง อย่างเช่นขั้นตอนการแปรรูปข้อมูลเพียงชุดเดียว เพื่อให้คุณโฟกัสกับตรรกะได้เต็มที่โดยไม่ต้องพะวงกับระบบส่วนใหญ่ กระบวนการของ Codex Security คือการแยกแยะโค้ดออกเป็นชิ้นเล็กๆ ก่อนจะเขียนโปรแกรมสุ่มทดสอบเพื่อหาจุดบกพร่องในแต่ละชิ้นส่วนเหล่านั้น
• เราเน้นการวิเคราะห์เงื่อนไขความปลอดภัยที่ส่งต่อผ่านการแปลงข้อมูลทั้งหมด แทนที่จะตรวจสอบแต่ละจุดแยกจากกันโดยไม่เกี่ยวข้องกัน ระบบสามารถแปลงปัญหาให้เป็นรูปแบบตรรกะเชิงสัญลักษณ์หากจำเป็น เพื่อพิสูจน์หาค่าข้อมูลที่ทำให้ระบบพัง กล่าวอีกนัยหนึ่ง เราเปิดโอกาสให้โมเดลใช้ Python และ z3-solver เพื่อช่วยในการวิเคราะห์ ซึ่งระบบก็ใช้งานเครื่องมือนี้ได้อย่างเชี่ยวชาญเมื่อจำเป็น เหมือนกับที่มนุษย์ต้องทำเวลาแก้โจทย์ปัญหาเงื่อนไขอินพุตที่ซับซ้อนมากๆ วิธีการนี้มีประโยชน์อย่างยิ่งในการตรวจหาปัญหา Integer Overflow หรือบั๊กในลักษณะเดียวกันบนสถาปัตยกรรมคอมพิวเตอร์ที่ไม่ใช่มาตรฐานทั่วไป
• เราทดสอบสมมติฐานในสภาพแวดล้อมจำลองทุกครั้งที่ทำได้ เพื่อแยกแยะระหว่าง “สิ่งที่อาจจะเป็นปัญหา” กับ “สิ่งที่เป็นปัญหาจริง” ไม่มีหลักฐานใดดีไปกว่าการทำ PoC แบบครบวงจรตั้งแต่ต้นจนจบ โดยคอมไพล์โค้ดในโหมดดีบั๊ก 

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

ปฏิกิริยาที่ฟังดูสมเหตุสมผลคือทำไมเราไม่เลือกทำทั้งสองอย่างไปพร้อมกันเลยล่ะ เริ่มต้นด้วยรายงาน SAST จากนั้นใช้เอเจนต์เพื่อให้เหตุผลเชิงลึกยิ่งขึ้น

ในบางกรณีข้อมูลที่ตรวจพบไว้ล่วงหน้าก็มีประโยชน์อย่างมาก โดยเฉพาะกับประเภทของบั๊กที่ระบุขอบเขตได้ชัดเจนและเป็นที่รู้จักกันดี แต่สำหรับเอเจนต์ที่ออกแบบมาเพื่อค้นหาและยืนยันช่องโหว่ตามบริบทจริง การเริ่มต้นจากรายงาน SAST ก่อให้เกิดรูปแบบความล้มเหลวที่คาดการณ์ได้ 3 ประการ

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

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

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

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

เรายอมรับว่า SAST มีประสิทธิภาพสูงในงานเฉพาะด้านอย่างการคุมมาตรฐานความปลอดภัยของซอร์สโค้ด การตรวจจับปัญหาทางเดินข้อมูลจากต้นทางสู่ปลายทางที่ตรงไปตรงมา และตรวจหาพฤติกรรมสุ่มเสี่ยงที่พบบ่อยได้คราวละมากๆ โดยมีจุดเด่นและข้อจำกัดที่ประเมินได้ล่วงหน้า เป็นองค์ประกอบสำคัญในการสร้างเกราะป้องกันหลายชั้นที่มีประสิทธิภาพสูง

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

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

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

เราตั้งเป้าหมายให้ Codex Security เชี่ยวชาญในส่วนที่ทีมรักษาความปลอดภัยต้องจ่ายต้นทุนสูงที่สุด ซึ่งก็คือการเปลี่ยนจากคำว่า “นี่ดูน่าสงสัย” ให้กลายเป็น “นี่คือปัญหาจริง นี่คือวิธีที่มันล้มเหลว และนี่คือวิธีแก้ที่สอดคล้องกับเจตนาของระบบ” 

หากคุณต้องการทำความเข้าใจเพิ่มเติมเกี่ยวกับขั้นตอนที่ Codex Security ใช้สแกน Repository ตรวจสอบสิ่งที่ค้นพบ และเสนอแนวทางแก้ไข โปรดศึกษารายละเอียดในเอกสารของเรา⁠(เปิดในหน้าต่างใหม่)