ไฟล์ทักษะ ไฟล์กฎ การตั้งค่าเซิร์ฟเวอร์ MCP ข้อความธรรมดา 3 บรรทัด commitไฟล์เหล่านั้นดูเหมือนเอกสาร ตรวจสอบแล้วเหมือนเอกสาร และไม่มีไฟล์ใดที่ดูเหมือนโค้ดเลย แต่ถึงกระนั้น ไฟล์แต่ละไฟล์ก็สามารถเขียนทับคำสั่งที่ผู้ช่วย AI ของคุณได้รับ และขอบเขตการเข้าถึงของมันได้อย่างเงียบๆ นี่คือความจริงที่น่าอึดอัดใจเบื้องหลังความปลอดภัยของ AI ในปี 2026อุตสาหกรรมใช้เวลาสองปีในการกังวลเกี่ยวกับเนื้อหาของโค้ดที่สร้างโดย AI ปัญหาที่ยากกว่ากลับกลายเป็นห่วงโซ่อุปทานของ AI เอง: โมเดล เอเจนต์ เซิร์ฟเวอร์ MCP และไฟล์การกำหนดค่าที่ตอนนี้อยู่ร่วมกับซอร์สโค้ดและส่วนประกอบโอเพนซอร์สของคุณ โดยส่วนใหญ่ไม่ได้ถูกจัดทำบัญชีและตรวจสอบ นี่คือเหตุผลที่การรักษาความปลอดภัยห่วงโซ่อุปทานของ AI กลายเป็นศาสตร์เฉพาะทาง และเหตุผลที่การเลือกบริษัทรักษาความปลอดภัย AI ที่เหมาะสมมีความสำคัญพอๆ กับการเลือกสแกนเนอร์ที่เหมาะสม
พื้นที่เสี่ยงที่ไม่มีใครคาดคิดมาก่อน
เดิมทีซอฟต์แวร์มีจุดอ่อนที่ผู้โจมตีสามารถเจาะเข้าไปได้เพียงไม่กี่จุด ได้แก่ โค้ด ส่วนประกอบต่างๆ และ... pipelineAI ได้เพิ่มอีกสองรายการ และทั้งสองรายการนี้เชื่อมโยงโดยตรงกับห่วงโซ่อุปทานของ AI
แบบจำลองและตัวแทน การโจมตีด้วยมัลแวร์ การฉีดโค้ดเข้าระบบ การทำงานอัตโนมัติของเอเจนต์ที่เกินความคาดหมาย คำสั่งที่ซ่อนอยู่ในการอธิบายเซิร์ฟเวอร์ MCP สามารถเปลี่ยนเส้นทางการทำงานของผู้ช่วยนักบินได้อย่างเงียบๆ โดยที่นักพัฒนาไม่เห็นการเปลี่ยนแปลงนั้นเลย
สภาพแวดล้อมของนักพัฒนาเอง IDE, AI copilot, เซิร์ฟเวอร์ MCP, CLI ของเอเจนต์ สิ่งเหล่านี้มองไม่เห็นสำหรับสแกนเนอร์ AppSec รุ่นเก่าที่ไม่รู้จักโมเดล และมองไม่เห็นสำหรับ EDR ซึ่งเฝ้าดูระบบปฏิบัติการและไม่รู้ว่าการพึ่งพาหรือการเรียกใช้ MCP คืออะไร
ข้อมูลทั้งหมดนี้ไม่ใช่ทฤษฎี ในช่วงสิบแปดเดือนที่ผ่านมา:
- ช่องโหว่ "ไฟล์กฎ" ที่ซ่อนอยู่ด้วย Unicode ทำให้ผู้โจมตีสามารถแทรกคำสั่งที่มองไม่เห็นเข้าไปในไฟล์การกำหนดค่าที่ Copilot และ Cursor อ่าน ซึ่งเป็นการแอบแฝงโค้ดที่ผู้ช่วยสร้างขึ้น GitHub ได้เพิ่มคำเตือนเกี่ยวกับช่องโหว่นี้ในปี 2025
- ช่องโหว่การแทรกคำสั่งใน MCP bridge ยอดนิยม (CVSS 9.6) ส่งผลกระทบต่อการดาวน์โหลดกว่า 400,000 ครั้งก่อนที่จะได้รับการแก้ไข ซึ่งเป็นกรณีแรกที่มีการบันทึกไว้เกี่ยวกับการเรียกใช้โค้ดจากระยะไกลอย่างสมบูรณ์โดยเพียงแค่เชื่อมต่อกับเซิร์ฟเวอร์ MCP ที่ไม่น่าเชื่อถือ
- เวิร์ม npm ที่แพร่กระจายตัวเองได้เปลี่ยนนักพัฒนาซอฟต์แวร์ให้กลายเป็นกลไกในการส่งมอบ และรูปแบบนี้ก็เกิดขึ้นซ้ำในวงกว้างในอีกหลายเดือนต่อมาในระบบนิเวศอื่นๆ ซึ่งเป็นตัวอย่างความล้มเหลวในการรักษาความปลอดภัยในห่วงโซ่อุปทานของ AI อย่างชัดเจน
- นักวิจัยพบว่าแพ็กเกจจำนวนมากที่ LLM แนะนำนั้นไม่มีอยู่จริง เป็นชื่อที่ผู้โจมตีจดทะเบียนไว้ก่อนที่นักพัฒนาซอฟต์แวร์ตัวจริงจะขอให้โมเดลนำเข้าเสียอีก
งานวิจัยของ Google เองเกี่ยวกับการรักษาความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์ AI ก็ได้ข้อสรุปที่คล้ายคลึงกันจากมุมมองที่แตกต่างออกไป: โมเดลที่พบว่ามีการหมุนเวียนในปี 2023 และ 2024 ดูเหมือนถูกต้องตามกฎหมาย แต่มีโค้ดที่สามารถขโมยข้อมูลหรือฝังช่องโหว่ได้เมื่อดาวน์โหลด และวิธีแก้ไขไม่ได้อยู่ที่การสร้างเครื่องมือประเภทใหม่ แต่เป็นการนำระเบียบวินัยของห่วงโซ่อุปทาน เช่น การตรวจสอบแหล่งที่มาและการลงนาม มาใช้กับสิ่งประดิษฐ์ที่ไม่มีใครเคยติดตามมาก่อน นั่นคือปัญหาด้านความปลอดภัยของห่วงโซ่อุปทาน AI ในประโยคเดียว: สิ่งประดิษฐ์นั้นใหม่ แต่ระเบียบวินัยที่จำเป็นนั้นไม่ใช่ของใหม่
เหตุใดเครื่องมือที่มีอยู่ของคุณจึงใช้งานได้ไม่เต็มประสิทธิภาพ
SAST อ่านโค้ด SCA อ่านรายการความสัมพันธ์ของส่วนประกอบต่างๆ ทั้งสองฝ่ายไม่รู้ว่าโมเดลคืออะไร เซิร์ฟเวอร์ MCP เปิดเผยอะไร หรือไฟล์ทักษะสั่งให้เอเจนต์ทำอะไร ช่องว่างนี้เองที่เป็นจุดที่การโจมตีในยุค AI เข้ามาเกี่ยวข้อง อยู่ในพื้นที่ระหว่าง “โค้ดที่เราสแกน” กับ “AI ที่เรานำมาใช้โดยไม่เปิดเผยตัวตน”
ผลลัพธ์คือหมวดหมู่ของ AI เงาหมายเลข CISปัจจุบัน O สามารถตอบคำถามได้เพียงว่า: เรากำลังใช้โมเดลอะไรอยู่ เอเจนต์ใดสามารถเข้าถึงอะไรได้บ้าง และมีใครเชื่อมต่อกับเซิร์ฟเวอร์ MCP ใดเมื่อวันอังคารที่ผ่านมาโดยไม่บอกใคร การตอบคำถามนั้นให้ดีคืองานด้านความปลอดภัยของห่วงโซ่อุปทาน AI และนี่คือเหตุผลที่เครื่องมือ AppSec ทั่วไปยังคงไม่เพียงพอในเรื่องนี้
ความปลอดภัยด้าน AI หมายความว่าอย่างไรกันแน่
ไซเกนี คือบริษัทรักษาความปลอดภัย AI ที่มองสิ่งนี้เป็นการเคลื่อนไหวที่เชื่อมโยงกันสามอย่างทั่วทั้งระบบ SDLC: ค้นหา ตรวจจับ และบังคับใช้
ค้นพบ: รู้ว่าคุณมี AI ประเภทใดอยู่จริง ๆ
การค้นหาอัตโนมัติอย่างต่อเนื่องทั่วทั้งคลังเก็บข้อมูลของคุณจะแสดงสินทรัพย์ AI ทั้งหมด ได้แก่ โมเดล เฟรมเวิร์ก ชุดข้อมูล จุดสิ้นสุดการอนุมาน เอเจนต์ เซิร์ฟเวอร์ MCP ทักษะ และข้อความแจ้งเตือน guardrailsและเครื่องมือเขียนโค้ด AI ที่นักพัฒนาของคุณใช้งานจริง ไม่มีการสำรวจ ไม่มีการรายงานตนเอง หากมันทิ้งร่องรอยไว้ในที่เก็บข้อมูล มันก็จะปรากฏในสินค้าคงคลัง ซึ่งเป็นข้อกำหนดแรกและพื้นฐานที่สุดของความปลอดภัยในห่วงโซ่อุปทาน AI ที่แท้จริง
จากนั้นกราฟ AI จะแสดงให้เห็นว่าสินทรัพย์เหล่านั้นเชื่อมต่อกันอย่างไร: ชุดข้อมูลหนึ่งป้อนข้อมูลให้กับโมเดลใด เอเจนต์ใดเรียกใช้เครื่องมือใด เซิร์ฟเวอร์ MCP ใดอยู่เบื้องหลังผู้ช่วยใด สินทรัพย์เพียงอย่างเดียวให้ข้อมูลเพียงเล็กน้อย กราฟจะแสดงให้เห็นว่าความเสี่ยงกระจุกตัวอยู่ที่ใด
จากการค้นพบเดียวกันนั้น Xygeni จึงสร้างสิ่งหนึ่งขึ้นมา AI-BOM: รายการข้อมูลทุกอย่างที่เกี่ยวข้องกับ AI ในซอฟต์แวร์ของคุณที่พร้อมสำหรับการตรวจสอบและอ่านได้ด้วยเครื่อง เมื่อหน่วยงานกำกับดูแล ผู้ตรวจสอบบัญชี หรือลูกค้าถามว่าคุณใช้ AI อะไรอยู่ คำตอบก็จะเปลี่ยนเป็นการดาวน์โหลดทันที แทนที่จะต้องเร่งหาข้อมูลเป็นเวลาสามสัปดาห์
ตรวจจับ: ความเสี่ยงที่เครื่องสแกนแบบทั่วไปตรวจไม่พบ
เครื่องมือสแกน AI เฉพาะทางจะตรวจสอบหาโหมดความล้มเหลวที่เฉพาะเจาะจงกับระบบ AI ได้แก่ การแทรกข้อความแจ้งเตือน การแทรกเครื่องมือและการเรียกใช้เครื่องมือที่ไม่น่าเชื่อถือ การรั่วไหลของข้อมูลผ่านการดึงข้อมูล การข้ามข้อความแจ้งเตือนของระบบ และการควบคุมมากเกินไป ทุกการค้นพบจะถูกแมปไปยัง... OWASP Top 10 สำหรับการสมัครเรียน LLM และชี้ไปยังไฟล์และบรรทัดที่ทำให้เกิดปัญหาอย่างแม่นยำ ไม่ใช่การแจ้งเตือนแบบคลุมเครือว่า "ตรวจสอบการใช้งาน AI ของคุณ"
ชั้นการตรวจจับเดียวกันนี้จะจัดการไฟล์ทักษะ ไฟล์กฎ และการกำหนดค่า MCP ในฐานะสิ่งประดิษฐ์ด้านความปลอดภัย ไม่ใช่เอกสารที่ไม่เป็นอันตราย มันจะระบุทักษะที่เป็นอันตรายหรือถูกโจมตี ตรวจสอบการกำหนดค่าเซิร์ฟเวอร์ MCP เพื่อหาการโจมตีเครื่องมือ และแสดงข้อความแจ้งเตือนที่ขับเคลื่อนเวิร์กโหลด AI ของคุณจริงๆ
ให้ความสำคัญ: กับกระบวนการที่ช่วยลดเสียงรบกวน ไม่ใช่การตัดส่วนที่ไม่จำเป็นออกไป
ทุกการค้นพบจะถูกกรองอย่างต่อเนื่อง: เริ่มจากสิ่งที่สามารถเข้าถึงได้ในโค้ดแอปพลิเคชัน จากนั้นจึงกรองสิ่งที่สามารถใช้ประโยชน์ได้จริง และสุดท้ายคือสิ่งที่อยู่ในโค้ดที่ทีมของคุณกำลังพัฒนาอยู่ สิ่งที่ส่งไปยังคิวของนักพัฒนาคือรายการย่อๆ ที่คุกคามระบบการผลิตจริง พร้อมด้วยการอ้างอิงเฟรมเวิร์ก ช่วงเวลาที่อาจได้รับผลกระทบ และคำแนะนำในการลดผลกระทบ
บังคับใช้: หยุดมันก่อนที่มันจะเริ่มทำงาน
Shield นำการบังคับใช้นโยบายมาสู่ปลายทางของนักพัฒนาเอง: มันจะบล็อกการติดตั้งที่ไม่ได้รับอนุญาตและเป็นอันตราย โมเดลที่ไม่ได้รับการอนุมัติ และเซิร์ฟเวอร์ MCP ที่ไม่ได้รับอนุญาต ก่อนที่สิ่งใดจะทำงาน ภายใต้ระบบนี้คือ Xygeni's ระบบแจ้งเตือนมัลแวร์ล่วงหน้า (MEW)ซึ่งตรวจจับแพ็กเกจที่เป็นอันตรายก่อนที่จะมีลายเซ็นเกิดขึ้น เครื่องมือที่ใช้ระบบชื่อเสียงในระดับนี้ยังคงเชื่อถือได้ เพราะยังไม่มีใครรายงานแพ็กเกจนั้นมาก่อน นี่คือส่วนบังคับใช้ของระบบรักษาความปลอดภัยห่วงโซ่อุปทานด้วย AI: การค้นพบและการตรวจจับจะบอกคุณว่ามีอะไรผิดปกติ Shield นั่นคือสิ่งที่หยุดยั้งมันได้จริง ๆ
ความเสี่ยงด้าน AI ของคุณไม่ได้จำกัดอยู่แค่ในโค้ด AI เท่านั้น
ภาพรวมด้านความปลอดภัยของห่วงโซ่อุปทาน AI ที่สมบูรณ์แบบนั้นต้องการมากกว่าแค่สินค้าคงคลังตามแบบจำลอง และมันแทบจะไม่ใช่แค่สิ่งที่ดูหวือหวาเท่านั้น:
- ข้อมูลประจำตัวผู้ให้บริการ AI เหลืออยู่ในไฟล์ข้อความแจ้งเตือน การกำหนดค่าเอเจนต์ หรือ pipeline ไฟล์บันทึกข้อมูลก็เป็นความลับเช่นเดียวกับข้อมูลอื่นๆ และระบบตรวจจับความลับของ Xygeni จะตรวจจับไฟล์เหล่านั้นได้ก่อนที่จะถูกเผยแพร่สู่สาธารณะ
- การพึ่งพา AI และ ML ที่เปราะบาง มีช่องโหว่ CVE ทั่วไป ซึ่งตรวจพบได้จากการวิเคราะห์องค์ประกอบซอฟต์แวร์แบบเดียวกันกับที่ครอบคลุมส่วนอื่นๆ ของระบบอยู่แล้ว งานวิจัยจากภายนอกเกี่ยวกับการนำ AI มาใช้ชี้ให้เห็นว่า ส่วนประกอบต่างๆ ของระบบ AI สมัยใหม่นั้นส่วนใหญ่เป็นแพ็กเกจที่มาจากภายนอกและส่วนประกอบที่ซ่อนอยู่ ซึ่งเป็นสิ่งที่การวิเคราะห์องค์ประกอบซอฟต์แวร์ถูกสร้างขึ้นมาเพื่อตรวจสอบนั่นเอง
- แพ็กเกจที่เป็นอันตราย เผยแพร่เร็วกว่าคำแนะนำใดๆ pipeline สามารถจัดทำรายการและตรวจจับได้ก่อนการลงนาม ซึ่งเป็นความสามารถ MEW เดียวกันที่ปกป้องส่วนที่เหลือของห่วงโซ่อุปทานของคุณ
ชั้นตัวแทน: DevAI และ CoreAI
การค้นหาและการตรวจจับจะครอบคลุมสิ่งที่มีอยู่แล้วในคลังข้อมูลของคุณ เดฟเอไอ ทำงานในจุดที่มีความเสี่ยง: ภายใน IDE ในฐานะเลเยอร์เชิงรุกต่อเนื่องที่สแกนโค้ดที่สร้างโดยมนุษย์และ AI ขณะที่เขียน โดยไม่จำเป็นต้องมีการแจ้งเตือนใดๆ มันจะอธิบายเส้นทางการโจมตีทั้งหมดที่อยู่เบื้องหลังการค้นพบ และเสนอวิธีแก้ไขที่ได้รับการตรวจสอบโดย MCP ซึ่งนักพัฒนาสามารถนำไปใช้ได้อย่างมั่นใจโดยไม่ทำให้ระบบเสียหาย
คอร์ไอ ทำหน้าที่เป็นชั้นประมวลผลอัจฉริยะ อยู่เหนือเครื่องสแกนแต่ละตัว โดยทำหน้าที่เชื่อมโยงรหัส ความสัมพันธ์ และอื่นๆ pipelineและนำข้อมูลเชิงท่ามารวมไว้ในแบบจำลองความเสี่ยงเดียว ตอบคำถามด้วยภาษาธรรมชาติ และสร้างรายงานที่พร้อมสำหรับผู้บริหาร ซึ่งเป็นสิ่งที่ผู้นำด้านความปลอดภัยต้องการเพื่อแสดงให้เห็นว่าการกำกับดูแลเกิดขึ้นจริง ไม่ใช่แค่กล่าวอ้าง
ต่อยอดจากสิ่งที่คุณมีอยู่แล้วในระบบรักษาความปลอดภัย AI อย่าตัดอะไรออกไปเลย
ข้อโต้แย้งที่พบบ่อยที่สุดเกี่ยวกับหมวดหมู่ความปลอดภัยใหม่คือ “เรามีเครื่องมือเพียงพอแล้ว” ในฐานะบริษัทด้านความปลอดภัยที่ใช้ AI Xygeni ไม่ได้ขอให้คุณเปลี่ยนอะไร: การคัดกรอง การอธิบาย และการจัดลำดับความสำคัญแบบเดียวกันที่ใช้กับผลการค้นพบของ Xygeni นั้น สามารถนำไปใช้กับผลการค้นพบจากระบบที่มีอยู่ของคุณได้เช่นกัน SAST, SCAรวมถึงเครื่องสแกนจากภายนอก ระบบปัจจุบันของคุณจะกลายเป็นข้อมูลป้อนเข้า ไม่ใช่สิ่งที่เสียหาย และสถานะความปลอดภัยของห่วงโซ่อุปทาน AI ของคุณจะดีขึ้นโดยไม่ต้องมีโครงการรื้อและเปลี่ยนใหม่ทั้งหมด
ทำไมเรื่องนี้ถึงสำคัญในตอนนี้ ไม่ใช่ในภายหลัง
หน่วยงานกำกับดูแลต่าง ๆ กำลังมุ่งไปสู่ความคาดหวังเดียวกันจากหลายทิศทาง: กฎหมาย AI ของสหภาพยุโรป, NIS2 และ ENS ของสเปน ล้วนผลักดันไปสู่การจัดทำบัญชีรายการและติดตามแหล่งที่มาของระบบ AI ซึ่งเป็นหลักฐานเดียวกันกับที่รายการวัสดุ (BOM) ของ AI ถูกสร้างขึ้นมา ทิศทางของการดำเนินการนั้นชัดเจน แม้ว่ากลไกการปฏิบัติตามกฎระเบียบที่แน่นอนจะยังไม่ลงตัวก็ตาม: คุณไม่สามารถรับรอง AI ที่คุณไม่เคยจัดทำบัญชีรายการ และคุณไม่สามารถอ้างความปลอดภัยของห่วงโซ่อุปทาน AI ได้หากห่วงโซ่อุปทานนั้นมองไม่เห็นสำหรับคุณ
การเลือกบริษัทรักษาความปลอดภัย AI
ไม่ใช่ทุกบริษัทที่ให้บริการด้านความปลอดภัยของ AI จะกำหนดขอบเขตการทำงานไว้ที่เดียวกัน บางบริษัทอาจหยุดอยู่ที่การสแกนโค้ดที่สร้างโดย AI ของคุณเอง ในขณะที่บางบริษัทอาจหยุดอยู่ที่ปลายทาง (endpoint) ปัญหาด้านความปลอดภัยของห่วงโซ่อุปทาน AI นั้นกว้างกว่าแค่ส่วนใดส่วนหนึ่ง มันครอบคลุมตั้งแต่โมเดล เอเจนต์ เซิร์ฟเวอร์ MCP ไฟล์ทักษะ และส่วนประกอบอื่นๆ ที่อยู่เบื้องหลังทั้งหมด มุมมองแบบครบวงจรตั้งแต่การค้นพบไปจนถึงการบังคับใช้ ในคอนโซลเดียวกับข้อมูลด้านความปลอดภัยของแอปพลิเคชัน (AppSec) อื่นๆ คือสิ่งที่คุณควรพิจารณาเมื่อประเมินบริษัทที่ให้บริการด้านความปลอดภัยของ AI มากกว่าเครื่องมือเพียงจุดเดียว
ไฟล์ที่ไม่มีใครตรวจสอบกลายเป็นช่องทางในการเข้าถึง ระบบรักษาความปลอดภัย AI คือระเบียบวินัยในการตรวจสอบไฟล์เหล่านั้น และระบบรักษาความปลอดภัยห่วงโซ่อุปทาน AI คือสิ่งที่ทำให้ระเบียบวินัยนั้นมีความยั่งยืนตั้งแต่ต้นจนจบ บนแพลตฟอร์มเดียวกันกับที่คุณตรวจสอบทุกอย่างอยู่แล้ว
ตรวจสอบว่า AI ของคุณสามารถทำอะไรได้บ้าง เริ่มฟรี or กำหนดเวลาการสาธิต.
คำถามที่พบบ่อย
โค้ดของ Xygeni จะถูกส่งออกจากโครงสร้างพื้นฐานของฉันหรือไม่?
ไม่ การสแกนจะทำงานภายในสภาพแวดล้อมของคุณเอง และไม่มีการอัปโหลดซอร์สโค้ดไปยังเซิร์ฟเวอร์ของ Xygeni ข้อมูลสินค้าคงคลังและรายการวัสดุ (BOM) ที่สร้างขึ้นโดย AI นั้นมาจากสิ่งที่เครื่องสแกนเห็นในเครื่อง ไม่ใช่จากสำเนาที่ส่งมาจากภายนอก
AI Security, DevAI และ CoreAI แตกต่างกันอย่างไร?
AI Security ค้นพบและตรวจจับ: มันสร้างรายการ AI, AI-BOM และค้นหาความเสี่ยง เช่น การแทรกข้อความแจ้งเตือนหรือไฟล์ทักษะที่ถูกดัดแปลง DevAI ทำงานภายใน IDE ขณะที่นักพัฒนาเขียนโค้ด โดยเสนอวิธีแก้ไขไปพร้อมกัน CoreAI อยู่เหนือทั้งสองระบบ โดยเชื่อมโยงผลการค้นพบจากทั่วทั้งแพลตฟอร์มและตอบคำถามเกี่ยวกับสถานะความปลอดภัยของคุณด้วยภาษาธรรมชาติ
Xygeni สอดคล้องกับกรอบการรักษาความปลอดภัย AI ใดบ้าง?
ผลการวิจัยสอดคล้องกับ OWASP Top 10 สำหรับการสมัครเรียน LLM, OWASP Top 10 สำหรับ MCP และ OWASP Top 10 สำหรับทักษะการเป็นผู้นำ รวมถึง NIST SP 800-218A ด้วย CISแนวทาง A/G7 เกี่ยวกับรายการวัสดุของ AI การจับคู่ดังกล่าวทำให้ AI-BOM สามารถนำไปใช้เป็นหลักฐานการปฏิบัติตามข้อกำหนดได้ แทนที่จะเป็นเพียงแค่รายการสินค้าคงคลัง
วิธีนี้จะทำให้ทุกไลบรารีหรือโมเดล AI ถูกจัดว่ามีความเสี่ยงหรือไม่?
ไม่เลย กระบวนการจัดลำดับความสำคัญจะคัดกรองผลการค้นหาให้เหลือเฉพาะสิ่งที่สามารถเข้าถึงได้ในโค้ดแอปพลิเคชัน สามารถนำไปใช้ประโยชน์ได้อย่างแท้จริง และอยู่ในระหว่างการพัฒนาอย่างต่อเนื่อง ดังนั้นรายการที่นักพัฒนาเห็นจึงสั้น ไม่ใช่การแสดงสินทรัพย์ AI ทั้งหมดที่ตรวจพบ
