ไอเดีย #79: ระบบตรวจ dependency ที่มีช่องโหว่ในหลายโปรเจกต์

บริษัทรับทำเว็บที่ดูแลโปรเจกต์ลูกค้าห้าสิบโปรเจกต์ บางตัวใช้ Yii2 บางตัวใช้ Laravel บางตัวมี frontend ที่ลง npm package ไว้เป็นร้อย พอมีข่าวช่องโหว่ร้ายแรงใน library ยอดนิยม คำถามแรกคือ "เรามีโปรเจกต์ไหนใช้ตัวนี้บ้าง" แล้วทุกคนต้องไล่เปิดทีละ repo ระบบตรวจ dependency ที่มีช่องโหว่ในหลายโปรเจกต์จะตอบคำถามนี้ได้ในไม่กี่วินาที และเตือนเราก่อนลูกค้าจะเจอปัญหา

ใครจะใช้

• นักพัฒนา — ดูรายการช่องโหว่ในโปรเจกต์ที่ดูแล และวิธีอัปเดต
• Tech lead/หัวหน้าทีม — จัดลำดับความสำคัญ มอบหมายงานแก้ ดูแนวโน้ม
• ผู้บริหาร/ฝ่ายดูแลลูกค้า — ดูภาพรวมความเสี่ยงของแต่ละลูกค้า

ฟีเจอร์ขั้นต่ำ (MVP)

• ลงทะเบียนโปรเจกต์ (git repository) แล้วอ่านไฟล์ lock เช่น composer.lock, package-lock.json, pubspec.lock
• สร้างรายการ dependency พร้อมเวอร์ชันของทุกโปรเจกต์ (เป็น inventory/SBOM อย่างง่าย)
• เทียบกับฐานข้อมูลช่องโหว่สาธารณะแบบ open source แล้วแสดงระดับความรุนแรง
• Dashboard รวมทุกโปรเจกต์: จำนวนช่องโหว่ตามระดับ เรียงจากเสี่ยงมากไปน้อย
• ค้นหา "package X เวอร์ชันไหนอยู่ในโปรเจกต์ใดบ้าง"
• สแกนตามรอบเวลาและเมื่อมี push ใหม่ แจ้งเตือนเมื่อพบช่องโหว่ใหม่ระดับสูง
• ทำเครื่องหมาย "ยอมรับความเสี่ยง" พร้อมเหตุผลและวันหมดอายุ

ต่อยอดได้อีก

• สร้าง pull request อัปเดตเวอร์ชันอัตโนมัติ
• ตรวจ license ของ dependency
• ตรวจ image ของ Docker และ package ระดับ OS
• รายงาน PDF ส่งลูกค้ารายเดือน

โครงข้อมูลตั้งต้น

• project — id, name, repo_url, client_name, last_scanned_at
• package — id, ecosystem (composer/npm/pub), name
• project_dependency — id, project_id, package_id, version, is_direct, scanned_at
• vulnerability — id, advisory_id, package_id, affected_range, fixed_version, severity, summary
• finding — id, project_dependency_id, vulnerability_id, status (open/fixed/accepted), note, accepted_until

ระดับความยาก และสิ่งที่จะได้เรียนรู้

ปานกลางถึงท้าทาย

• parse ไฟล์ lock หลายรูปแบบ และเข้าใจ dependency ทางตรง/ทางอ้อม
• เปรียบเทียบเวอร์ชันแบบ semver กับช่วงเวอร์ชันที่ได้รับผลกระทบ
• ทำ background job สแกนหลายโปรเจกต์พร้อมกัน
• รับ webhook จากระบบ git เพื่อสแกนเมื่อมีการเปลี่ยนแปลง

ข้อควรระวัง

• token เข้าถึง repository ต้องเป็นแบบอ่านอย่างเดียวและเก็บเข้ารหัส เพราะระบบนี้เข้าถึงโค้ดลูกค้าทุกราย
• รายการช่องโหว่ของลูกค้าเป็นข้อมูลอ่อนไหว ใครได้ไปก็รู้ว่าจะเจาะตรงไหน ต้องจำกัดสิทธิ์อย่างเข้ม
• ผลสแกนมี false positive ได้ เช่น ฟังก์ชันที่มีช่องโหว่ไม่ได้ถูกเรียกใช้จริง ต้องให้นักพัฒนาประเมินก่อนตัดสินใจ

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