ผลบวกลวงเป็นปัญหาเชิงวัฒนธรรมก่อนจะเป็นปัญหาของโมเดล

3.2% ก็เพียงพอจะทำให้ทีมพัง

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

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

ต้นทุนของผลบวกลวงคือความเชื่อถือ ไม่ใช่เวลา

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

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

สี่สิ่งที่ต่างกันแต่ถูกเรียกว่าผลบวกลวง

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

ผลบวกลวงที่ทีมสร้างขึ้นเอง

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

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

ห้าแนวปฏิบัติที่ได้ผล

1. 01

   กำหนด SLA ของการคัดกรอง

   ข้อบกพร่องระดับวิกฤตต้องมีคำตัดสินแรกภายใน 24 ชั่วโมง ระดับสูงภายในสามวันทำการ เป็นคำตัดสิน ไม่ใช่การแก้ไข ข้อบกพร่องที่ยังไม่ถูกตัดสินกองสะสมอันตรายกว่าข้อบกพร่องที่ยังไม่ได้แก้กองสะสม

2. 02

   บังคับให้การระงับมีวันหมดอายุ

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

3. 03

   ตกลงกันว่าอะไรคือเข้าถึงได้

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

4. 04

   ให้ทุกข้อบกพร่องมีเจ้าของ

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

5. 05

   ทบทวนผลบวกลวงทุกไตรมาส

   รวบรวมเฉพาะกรณีที่จัดเป็นผลบวกลวงจริงแล้วใช้เวลา 30 นาทีแยกออกเป็นสามกอง คือแก้ได้ด้วยการปรับกฎ ต้องเพิ่มการรู้จักเฟรมเวิร์ก และธรรมเนียมการเขียนโค้ดของเราเองที่ควรเปลี่ยน

กฎการระงับควรอยู่ในรีโพ

ถ้าการระงับมีอยู่แค่ในรูปการคลิกบนแดชบอร์ด อีกหกเดือนจะไม่มีใครรู้ว่าใครกดและเพราะอะไร ปลอดภัยกว่าถ้าเก็บการระงับเป็นไฟล์ในรีโพที่ผ่านการรีวิว แล้วบังคับวันหมดอายุใน CI

- finding: FD-2026-05-0417
  rule: CWE-22/path-traversal
  path: internal/tools/migrate.go
  class: unreachable          # false-positive | unreachable | accepted-risk
  reason: >
    เส้นทางสำหรับ CLI เท่านั้น พาธอินพุตถูกสร้างโดยไปป์ไลน์การดีพลอย
    และไม่ถูกเปิดเผยบนพื้นผิว HTTP ดูเอกสาร threat model ประกอบ
  evidence: docs/threat-model.md#migrate-cli
  owner: platform-team
  expires: 2026-11-30         # เปิดใหม่อัตโนมัติในการสแกนครั้งถัดไป

- finding: FD-2026-05-0902
  rule: CWE-327/weak-hash
  path: legacy/auth/session.rb
  class: accepted-risk
  reason: "รองรับเซสชันระบบเดิม จะถูกถอดออกพร้อมการย้ายระบบเดือน 2026-09"
  compensating-control: "TTL ของเซสชัน 15 นาที และการผูกกับ IP"
  evidence: JIRA-SEC-2841
  owner: identity-team
  expires: 2026-09-30

จากนั้นให้ CI ตรวจไฟล์นี้เอง การระงับที่หมดอายุ ลิงก์หลักฐานที่เสีย และการระงับที่ทีมเจ้าของไม่มีอยู่แล้ว จะถูกไปป์ไลน์จับได้ทั้งหมด

# ตรวจการหมดอายุและการระงับที่ไร้เจ้าของ (ตั้งเป็นงานประจำสัปดาห์)
flawdetector suppressions lint \
  --max-age 180d \
  --require-evidence \
  --require-owner \
  --fail-on expired,orphaned

# ดูว่าตอนนี้อะไรถูกซ่อนอยู่บ้าง
flawdetector scan --include-suppressed --format table

ควรวัดอะไรแทน

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

ถ้าสี่ตัวนี้แข็งแรง ไปป์ไลน์เดินหน้าได้ไม่ว่าอัตราผลบวกลวงจะเป็น 3% หรือ 5% ตรงกันข้าม ถ้าสี่ตัวนี้พัง ต่อให้เปลี่ยนไปใช้เครื่องมือที่ผลบวกลวง 1% ผลก็เหมือนเดิม คิวยังค้างและการแจ้งเตือนยังถูกเพิกเฉย

สรุป

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

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