วิธีการทำงาน
จากลิงก์ repository ไปสู่ผลการตรวจพบที่ผ่านการยืนยัน
ไปป์ไลน์นี้จำลองแนวทางที่ Anthropic อธิบายไว้สำหรับ OSS Scanner ได้แก่ threat model การตรวจสอบ การตรวจทานซ้ำ การหาสาเหตุที่แท้จริง และแพตช์ โดยใช้ Claude รุ่นล้ำสมัยที่ให้บริการผ่าน API สาธารณะ
- 1
โคลนอย่างปลอดภัย
เราดึง branch ที่คุณระบุด้วย git clone แบบ shallow และกรอง blob ผ่าน HTTPS โดยปิดใช้ Git hooks เช็กเอาต์ symlink เป็นไฟล์ปกติ และปฏิเสธการเชื่อมต่อทุกรูปแบบที่ไม่ใช่ HTTPS เราบล็อกที่อยู่เครือข่ายส่วนตัว จึงไม่สามารถชี้เครื่องสแกนไปยังโฮสต์ภายในได้
เราไม่เรียกใช้สิ่งใดจาก repository ไม่ว่าจะเป็นการ build การติดตั้งแพ็กเกจ หรือการทดสอบ เมื่อการสแกนสิ้นสุด เราจะลบ checkout ทิ้ง
- 2
จัดทำรายการและจัดอันดับความเสี่ยง
เราจัดทำรายการไฟล์ซอร์สที่เป็นข้อความทุกไฟล์ พร้อมระบุภาษาและขนาด โดยข้ามโค้ดที่ vendored ไฟล์ที่สร้างขึ้นอัตโนมัติ bundle ที่ย่อขนาดแล้ว และ lockfile แต่ละไฟล์จะได้รับคะแนนความเสี่ยงตามจุดที่อาจก่ออันตราย เช่น การคัดลอกหน่วยความจำ การเรียกใช้ shell การ deserialize การประกอบคำสั่ง SQL การเรนเดอร์ template การต่อ path โค้ดเข้ารหัสลับ และโค้ดตรวจสอบสิทธิ์ รวมถึงเส้นทางการทำงานสำคัญ เช่น parser ตัวจัดการโปรโตคอล และการกำหนดเส้นทางคำขอ
- 3
Threat model
หาก repository มี .oss-scanner/threat_model.md (ไฟล์เดียวกับที่เครื่องสแกนของ Anthropic อ่าน), SECURITY.md หรือ threat model ที่คุณส่งไว้ตอนลงทะเบียน เครื่องสแกนจะทำตามนั้น หากไม่มี โมเดลจะอ่าน README โครงสร้างไดเรกทอรี และไฟล์ที่มีความเสี่ยงสูงสุด แล้วร่าง threat model ขึ้นมา โดยระบุว่าโครงการนี้ทำอะไร ข้อมูลที่ไม่น่าเชื่อถือเข้ามาจากที่ใด และเรื่องใดอยู่นอกขอบเขต
Threat model ยังระบุไฟล์ที่ควรเน้น เพื่อให้การตรวจสอบใช้ทรัพยากรกับโค้ดที่ผู้โจมตีเข้าถึงได้จริง
- 4
การตรวจสอบ
ไฟล์ที่มีความเสี่ยงสูงสุดจะถูกรวบรวมเป็นชุดขนาดใหญ่พร้อมหมายเลขบรรทัด แล้วส่งไปยังโมเดลให้เหตุผลพร้อมแนบ threat model โมเดลจะค้นหาปัญหาที่ผู้ตรวจสอบซึ่งทำงานอย่างรอบคอบน่าจะรายงาน:
- ความปลอดภัยของหน่วยความจำ: บัฟเฟอร์ล้น, use-after-free, การตัดทอนจำนวนเต็ม
- การแทรกคำสั่ง: SQL, คำสั่ง, เทมเพลต, การไต่ระดับไดเรกทอรี, SSRF
- ตรรกะการยืนยันตัวตน การอนุญาต และเซสชัน
- การดีซีเรียลไลซ์ที่ไม่ปลอดภัยและความสับสนของตัวแยกวิเคราะห์
- การใช้วิทยาการเข้ารหัสลับอย่างไม่ถูกต้องและการจัดการข้อมูลลับ
การสแกนแบบรวดเร็วใช้ Claude Haiku โดยมีงบประมาณระดับปานกลาง ส่วนการสแกนเชิงลึกสำหรับโปรเจกต์ที่ลงทะเบียนใช้ Claude Sonnet และอ่านโค้ดได้มากขึ้นถึงสี่เท่า
- 5
การตรวจสอบยืนยันโดยอิสระ
ผลการตรวจพบที่อาจเป็นไปได้แต่ละรายการจะถูกส่งให้เอเจนต์ตรวจสอบอีกตัวหนึ่งพร้อมบริบทใหม่ หน้าที่ของเอเจนต์คือหักล้างผลการตรวจพบ โดยติดตามเส้นทางการไหลของข้อมูล ค้นหาการตรวจสอบความถูกต้องในส่วนอื่น และพิจารณาว่าข้อมูลนั้นอยู่ภายใต้การควบคุมของผู้โจมตีจริงหรือไม่ตาม threat model มีเพียงผลการตรวจพบที่เอเจนต์ยืนยันหรือประเมินว่ามีแนวโน้มถูกต้องเท่านั้นที่จะผ่าน ส่วนที่เหลือจะถูกนับเป็นรายการที่ถูกปฏิเสธ
สำหรับผลการตรวจพบที่ผ่านการตรวจสอบ เอเจนต์จะเขียนสาเหตุที่แท้จริง ตัวอย่างข้อมูลที่ใช้ทำให้เกิดปัญหา และแพตช์เบื้องต้นขนาดเล็กในรูปแบบ unified diff
- 6
คอมมิตที่ทำให้เกิดปัญหาและรายงาน
เรารวมรายการซ้ำที่มีสาเหตุที่แท้จริงเดียวกันเข้าด้วยกัน จากนั้นใช้ git blame กับบรรทัดที่มีช่องโหว่เพื่อหาคอมมิตล่าสุดที่แก้ไขบรรทัดเหล่านั้น ซึ่งโดยทั่วไปคือคอมมิตที่ทำให้เกิดข้อบกพร่อง คุณจึงเพิ่มแท็ก Fixes: และตรวจสอบได้ว่ารุ่นใดได้รับผลกระทบบ้าง
รายงานจะจัดเก็บไว้ภายใต้ ID แบบสุ่มที่คาดเดาไม่ได้ คุณส่งออกรายงานเป็น Markdown สำหรับประกาศแจ้งเตือน เป็น JSON สำหรับเครื่องมือ หรือเป็น SARIF 2.1.0 สำหรับการสแกนโค้ดของ GitHub ได้
สิ่งที่เครื่องสแกนไม่ทำ
- ไม่เรียกใช้หรือ build โค้ดของคุณ และไม่ดึง dependency มา
- ไม่เผยแพร่ผลการตรวจพบ ไม่สร้าง issue และไม่ติดต่อใครนอกจากผู้ดูแลโครงการที่ลงทะเบียนไว้
- ไม่เก็บสำเนาซอร์สโค้ดของคุณหลังการสแกน รายงานมีเพียงข้อความบางส่วนสั้น ๆ จากบรรทัดที่ได้รับผลกระทบ
- ไม่รับประกันผลใด ๆ โมเดลอาจพลาดข้อบกพร่อง และบางครั้งก็รายงานข้อผิดพลาด รายงานที่ไม่พบปัญหาไม่ใช่การรับรองความปลอดภัย
เหตุใดจึงซ่อนตัวอย่างที่ใช้ทำให้เกิดปัญหา
ทุกคนสามารถวางลิงก์ repository สาธารณะได้ รวมถึงคนที่ไม่ใช่ผู้ดูแลโครงการ สาเหตุที่แท้จริงและแพตช์ช่วยผู้ป้องกัน แต่ proof of concept ที่ใช้งานได้จริงมักเป็นประโยชน์ต่อผู้โจมตี ดังนั้นเราจึงซ่อนตัวอย่างที่ใช้ทำให้เกิดปัญหาไว้จนกว่าจะมีผู้คอมมิตไฟล์โทเค็นลงใน repository ซึ่งเป็นหลักฐานว่าบุคคลนั้นสามารถส่งแพตช์แก้ไขได้ แนวทางนี้สอดคล้องกับคำแนะนำของเคอร์เนล Linux ที่ให้แชร์ตัวอย่างที่ใช้ทำให้เกิดข้อบกพร่องซึ่ง AI ค้นพบเมื่อผู้ดูแลโครงการร้องขอ
ความแตกต่างระหว่างเครื่องสแกนนี้กับ OSS Scanner ของ Anthropic
Anthropic เรียกใช้เครื่องสแกนภายใน sandbox แบบออฟไลน์ โดย build โครงการของคุณจาก Dockerfile ทำให้เอเจนต์คอมไพล์และเรียกใช้โค้ดเพื่อยืนยันข้อบกพร่องแบบไดนามิกได้ และยังใช้โมเดลที่มีความสามารถสูงสุด รวมถึง Claude Mythos ซึ่งไม่มีให้บริการแก่สาธารณะ ส่วนเราอ่านโค้ดแบบสแตติกด้วย Claude รุ่นที่เปิดให้สาธารณะใช้งาน ข้อแลกเปลี่ยนคือทุกคนใช้ ossscanner.org ได้ภายในไม่กี่นาที โดยไม่ต้องสมัครหรือใช้ Dockerfile