จ้าง Penetration Test อย่างไรให้ได้รายงานที่นำไปแก้ได้จริง

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

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

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

VA กับ Penetration Test ต่างกันตรงไหน

Vulnerability Assessment (VA) คือการสำรวจหาช่องโหว่ที่เป็นที่รู้จักอยู่แล้วให้ได้กว้างที่สุด โดยพึ่งเครื่องมือสแกนเป็นหลัก แล้วให้ผู้ทดสอบคัดผลที่เป็น false positive ออก ผลลัพธ์คือรายการช่องโหว่ที่อาจมีอยู่ในระบบ

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

สองงานนี้ไม่ได้ใช้แทนกัน VA เหมาะกับการตรวจเป็นรอบเพื่อจับช่องโหว่ใหม่ของซอฟต์แวร์ที่ใช้อยู่ ส่วน penetration test เหมาะกับจังหวะที่ระบบเปลี่ยนมาก เช่น ก่อน go-live หรือหลังเพิ่มโมดูลที่จัดการข้อมูลสำคัญ ใน TOR ควรระบุชื่องานให้ชัด ถ้าเขียนกว้าง ๆ ว่าทดสอบความปลอดภัย ผู้ยื่นข้อเสนอแต่ละรายอาจตีความเป็นงานคนละประเภท และข้อเสนอจะเทียบกันไม่ได้

ถ้า go-live ครั้งนั้นมาพร้อมการเปลี่ยนจากระบบเดิม การตรวจข้อมูลที่ย้ายมาก่อน cutover เป็นอีกงานที่ต้องวางแผนแยกกัน เราเขียนเรื่องนี้ไว้ในย้ายครบ ไม่ได้แปลว่าย้ายถูก

เขียน scope ให้ผู้ทดสอบรู้ว่าต้องทดสอบอะไร

scope กำหนดคุณภาพของรายงานโดยตรง เพราะผู้ทดสอบจะรายงานได้เฉพาะสิ่งที่ได้รับอนุญาตให้แตะ ขอบเขตที่เราแนะนำให้เขียนลงเอกสารมีห้าเรื่อง

• สินทรัพย์ที่อยู่ในขอบเขต ระบุเป็นรายการ เช่น domain, URL ของ API และรุ่นของแอปมือถือที่ใช้ทดสอบ สิ่งที่อยู่นอกขอบเขตต้องเขียนให้ชัดพอกัน โดยเฉพาะบริการของบุคคลที่สามที่ระบบเรียกใช้ ซึ่งองค์กรของคุณไม่มีสิทธิ์อนุญาตให้ใครทดสอบ

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

• ช่วงเวลาทดสอบ ระบุวันและเวลาที่อนุญาต รวมถึงช่วงที่ห้ามทดสอบ เช่น รอบปิดบัญชีสิ้นเดือนหรือช่วงที่มีผู้ใช้หนาแน่น

• Production หรือ Staging staging ลดความเสี่ยงต่อระบบที่ใช้งานอยู่ แต่ผลจะสะท้อนของจริงก็ต่อเมื่อตั้งค่าเหมือน production ทั้งรุ่นซอฟต์แวร์และสิทธิ์ของ service account ถ้าสองสภาพแวดล้อมต่างกันตรงไหน ให้บันทึกความต่างนั้นเป็นข้อจำกัดในรายงาน

• Rules of Engagement เอกสารที่ทั้งสองฝ่ายเซ็นก่อนเริ่มงาน ระบุผู้ติดต่อฉุกเฉินของแต่ละฝ่าย เงื่อนไขที่ต้องหยุดทดสอบทันที เช่น ระบบช้าผิดปกติหรือพบข้อมูลส่วนบุคคลจริง และวิธีเก็บกับลบหลักฐานหลังจบงาน

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

ถ้าระบบจะเปิด API ให้ระบบอัตโนมัติหรือ AI Agent เรียกใช้ บัญชีของระบบเหล่านั้นควรอยู่ใน scope ด้วย เราเขียนเรื่องด่านที่องค์กรควรผ่านก่อนให้ AI Agent เข้าถึงระบบจริงไว้ในบทความนี้ ส่วนเงื่อนไขทั้งหมดข้างต้นควรอยู่ใน TOR ตั้งแต่รอบแรก แบบเดียวกับเงื่อนไขการส่งมอบที่เราเขียนไว้ในเขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้

อ้างอิงวิธีทดสอบ: WSTG เป็นคู่มือ ส่วน Top 10 ใช้สร้างความเข้าใจร่วม

ประโยคว่าทดสอบครอบคลุม OWASP Top 10 ฟังดูครบถ้วน แต่ OWASP เองอธิบาย Top 10 ว่าเป็นเอกสารมาตรฐานเพื่อสร้างความตระหนักด้านความปลอดภัยของ web application สำหรับนักพัฒนา ฉบับล่าสุดที่ OWASP ระบุไว้คือ Top 10 2025 (ที่มา: OWASP Top 10 ตรวจสอบเมื่อ 30 ก.ย. 2026)

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

ถ้าต้องการอ้างอิงวิธีทดสอบ ให้ระบุ OWASP Web Security Testing Guide (WSTG) ซึ่งเป็นคู่มือทดสอบความปลอดภัยของ web application โดยตรง และขอให้ผู้ทดสอบแนบ checklist ที่ใช้จริงไว้ในภาคผนวก คุณจะเห็นได้ว่าข้อไหนทดสอบแล้ว ข้อไหนไม่ได้ทดสอบ และเพราะอะไร

คะแนน CVSS บอกอะไร และไม่บอกอะไร

เมื่อรายงานให้คะแนนช่องโหว่ด้วย CVSS คำถามแรกที่ควรถามคือใช้รุ่นไหน และคำนวณจาก metric กลุ่มใดบ้าง รุ่นปัจจุบันคือ CVSS v4.0 ที่ FIRST เผยแพร่เมื่อเดือนพฤศจิกายน 2023 และแบ่ง metric เป็นสี่กลุ่ม คือ Base, Threat, Environmental และ Supplemental

เอกสาร specification ของ CVSS v4.0 ระบุว่ากลุ่ม Threat และ Environmental เป็นส่วนที่องค์กรผู้ใช้กำหนดเอง เพราะเป็นฝ่ายที่ประเมินผลกระทบในบริบทของตัวเองได้ดีที่สุด เอกสารยังแนะนำให้เติมสองกลุ่มนี้ลงบน Base เพื่อให้คะแนนเป็นข้อมูลประกอบการประเมินความเสี่ยงที่ครบขึ้น

specification กำหนดชื่อเรียกไว้ให้ด้วย CVSS-B คือคะแนนจาก Base อย่างเดียว CVSS-BT คือ Base กับ Threat CVSS-BE คือ Base กับ Environmental ส่วน CVSS-BTE คือรวมทั้ง Threat และ Environmental ใน TOR ควรขอให้รายงานระบุชื่อเรียกนี้กำกับทุกคะแนน

เหตุผลในทางปฏิบัติคือ ผู้ทดสอบจากภายนอกไม่รู้ว่าระบบไหนของคุณเก็บข้อมูลส่วนบุคคล หรือมีมาตรการอื่นป้องกันอยู่แล้ว ในตัวอย่างสมมติ ช่องโหว่ CVSS-B 7.5 บนเครื่องทดสอบที่ไม่มีข้อมูลจริง อาจสำคัญน้อยกว่าช่องโหว่ 5.3 บนหน้าที่แสดงข้อมูลลูกค้าขององค์กร

ตาราง severity ของ CVSS v4.0 ให้ 9.0 ถึง 10.0 เป็น Critical และ 7.0 ถึง 8.9 เป็น High ตัวเลขนี้ช่วยเรียงลำดับเบื้องต้นได้ แต่การตัดสินว่าจะแก้อะไรก่อนยังเป็นงานของเจ้าของระบบ

รายงานที่นำไปแก้ได้ต้องมีอะไร

บท Reporting ใน OWASP WSTG v4.2 วางโครงรายงานไว้เป็นตัวอย่าง ส่วนนำมีขอบเขตงาน ข้อจำกัดของการทดสอบ และช่วงเวลาที่ทดสอบ ต่อด้วยบทสรุปผู้บริหารที่เน้นผลกระทบต่อธุรกิจ

ในส่วน findings แต่ละรายการมีรหัสอ้างอิงกับชื่อเรื่อง การประเมินโอกาสเกิดและผลกระทบ ระดับความเสี่ยง คำอธิบายพร้อมขั้นตอนที่ทำให้เกิดผลซ้ำได้ วิธีแก้ และแหล่งอ้างอิง ภาคผนวกมีวิธีการทดสอบ คำอธิบายเกณฑ์ให้ระดับความรุนแรง ผลจากเครื่องมือที่คัดกรองแล้ว และ checklist ที่ใช้

WSTG เขียนไว้เองว่านี่เป็นเพียงแนวทางหนึ่ง และเหมาะกับรายงานแบบงานที่ปรึกษามากที่สุด เราจึงแนะนำให้ใช้เป็นฐานของเงื่อนไขรายงานใน TOR แล้วเพิ่มสองข้อที่เห็นว่าจำเป็นต่อทีมพัฒนา ทุก finding ต้องระบุสินทรัพย์ที่พบกับบทบาทของบัญชีที่ใช้ทดสอบ และต้องมีเกณฑ์ว่าแก้ถึงจุดไหนจึงนับว่าปิด

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

Retest และคนรับผิดชอบงานแก้

NIST SP 800-115 ซึ่งเผยแพร่ปี 2008 เขียนขึ้นเพื่อช่วยองค์กรวางแผนและลงมือทดสอบ วิเคราะห์ผลที่พบ และพัฒนาแนวทางลดความเสี่ยง งานทดสอบในความหมายนี้จึงไม่ได้จบในวันที่ได้รับรายงาน

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

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

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

ข้อจำกัดที่ต้องพูดตรง ๆ

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

อีกความเชื่อหนึ่งคือ รายงานไม่พบช่องโหว่ร้ายแรง แปลว่าระบบปลอดภัยแล้ว รายงานยืนยันได้เฉพาะสิ่งที่อยู่ใน scope ภายในช่วงเวลาที่ทดสอบเท่านั้น ส่วนข้อจำกัดในรายงานมีไว้บอกขอบเขตนั้น โค้ดที่ deploy หลังวันทดสอบ ไม่ได้อยู่ในผลของรายงานฉบับนั้น

จะเริ่มตรงไหน

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

2. ทำรายการสินทรัพย์ บทบาทผู้ใช้ และบริการของบุคคลที่สามที่ระบบเรียกใช้ รายการนี้จะกลายเป็น scope และส่วนที่อยู่นอกขอบเขตในคราวเดียว

3. เขียนสิ่งที่รายงานต้องมีและจำนวนรอบ retest ลงใน TOR ก่อนประกาศ ไม่ใช่เจรจาเพิ่มหลังได้รายงานฉบับแรก

4. กำหนดคนรับผิดชอบงานแก้และผู้มีอำนาจยอมรับความเสี่ยงไว้ก่อนวันรับรายงาน

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

หากองค์กรของคุณกำลังเตรียมระบบก่อน go-live และอยากคุยเรื่อง scope ร่วมกับฝั่งทีมพัฒนาระบบ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ไม่ต้องมีเอกสารครบก่อนคุย และไม่ต้องรีบตัดสินใจ ดูข้อมูลเพิ่มเติมเกี่ยวกับเราได้ที่ superdev.tech