หน้าแรก Opensource Vigolium: เครื่องมือสแกนหาช่องโหว่แบบโอเพนซอร์ส ที่คุณต้องไม่พลาด

Vigolium: เครื่องมือสแกนหาช่องโหว่แบบโอเพนซอร์ส ที่คุณต้องไม่พลาด

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

เครื่องมือนี้มีเส้นทางการสแกน 2 รูปแบบด้วยกัน ได้แก่:

Advertisement

vigolium scan สำหรับรันไปป์ไลน์แบบกำหนดเงื่อนไขหลายขั้นตอน ครอบคลุมตั้งแต่การค้นหาเนื้อหา การใช้สไปเดอร์  ตรวจสอบผ่านเบราว์เซอร์ ไปจนถึงการตรวจสอบเชิงรุกและเชิงรับ

vigolium agent สำหรับส่งต่อการควบคุมไปยังระบบที่ขับเคลื่อนด้วย LLM  ซึ่งจะทำหน้าที่เลือกโมดูล สร้างส่วนขยาย JavaScript แบบกำหนดเอง และตรวจสอบซอร์สโค้ดควบคู่ไปกับการสแกนแบบไดนามิก

การจำกัดงบประมาณกับต้นทุนความอิสระของเอเจนต์

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

Jessie Ho ผู้พัฒนาเครื่องมือนี้ กล่าวกับว่า ผู้ใช้งานควรตั้งค่าการจำกัดให้เหมาะสมกับประเภทงาน

“หากเป็นงานทดสอบเจาะระบบที่จำกัดเวลา หรือการรันในระบบ CI: ให้เน้นไปที่การจำกัดเวลาและจำนวนรอบ เพื่อให้งานจบได้เสมอ แต่หากเป็นการเจาะลึกไปที่เป้าหมายเดียว: ให้เพิ่มงบโทเค็นและปล่อยให้เอเจนต์วางแผนใหม่ได้ ส่วนการสแกนหาช่องโหว่เป็นวงกว้าง: ให้จำกัดงบประมาณต่อหนึ่งเป้าหมายไว้ให้แน่นหนา มิฉะนั้นเป้าหมายใดเป้าหมายหนึ่งที่ซับซ้อนเกินไปจะดึงงบไปจนหมด”

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

แยกขั้นตอนคัดกรอง  ออกมาเฉพาะ

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

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

ส่วนขยาย, แซนด์บ็อกซ์ และความเป็นไปได้ของระบบลงทะเบียนรวม

เอนจิน JavaScript ของ Vigolium ช่วยให้ผู้ใช้สามารถเขียนโมดูลสแกนแบบกำหนดเองและเชื่อมต่อกับ HTTP API ที่รับรู้อินสแตนซ์ของเซสชันได้ ทว่า ส่วนขยายเหล่านี้สามารถรันคำสั่งใด ๆ ก็ได้โดยไม่มีการจำกัดในแซนด์บ็อกซ์ เมื่อถามถึงแนวโน้มที่จะสร้างระบบลงทะเบียนรวมสำหรับชุมชนผู้ใช้ Ho แสดงความกังวลเกี่ยวกับรูปแบบความน่าเชื่อถือ ที่ระบบลักษณะนี้ต้องการ

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

โมเดล Open Core ควบคู่กับ Commercial Console

Vigolium เปิดตัวควบคู่ไปกับบริการแบบมีค่าใช้จ่ายที่เรียกว่า Cloud Console โดย Ho ได้ลากเส้นแบ่งระหว่างสองส่วนนี้ในแง่ของการดำเนินงาน “ตัวสแกนคือส่วนที่เป็น Open Core ส่วนการบริหารจัดการ จะเป็นเชิงพาณิชย์ อะไรก็ตามที่ทำหน้าที่ค้นหาช่องโหว่จะอยู่ในคลังโค้ด AGPL เสมอ ส่วน Console เป็นเพียงเลเยอร์การจัดการที่อยู่ข้างบน เช่น การโฮสต์, การทำงานร่วมกัน, การขยายระบบ และการตั้งเวลาทำงาน”

เขากล่าวทิ้งท้ายว่า ความเชื่อมั่นของผู้ร่วมพัฒนาโปรเจกต์นี้ขึ้นอยู่กับใบอนุญาต  และพฤติกรรมที่แสดงให้เห็นในระยะยาว “ระบบตรวจจับใหม่ ๆ จะต้องลงในคลังโอเพนซอร์สก่อนเสมอ วันใดที่ฟังก์ชันหลักเริ่มถูกย้ายออกไปเพื่อบีบให้คนซื้อ Console วันนั้นความเชื่อมั่นที่มีก็จะหมดไปทันที”

คลิกดาวน์โหลดฟรีได้ที่นี่ – Github