Source Code Review คืออะไร — ตรวจโค้ดหาช่องโหว่ก่อน Deploy

ช่องโหว่ส่วนใหญ่ที่พบใน Web Application สามารถป้องกันได้ตั้งแต่ ระดับซอร์สโค้ด ก่อนที่จะ Deploy ขึ้นระบบ Production บทความนี้อธิบาย Source Code Review คืออะไร ทำไมถึงสำคัญ เครื่องมือที่ใช้ และเวลาที่เหมาะสมในการทำ

Source Code Review คืออะไร

Source Code Review (การตรวจสอบซอร์สโค้ด) คือ กระบวนการตรวจสอบซอร์สโค้ดของแอปพลิเคชันอย่างเป็นระบบ เพื่อค้นหาช่องโหว่ด้านความปลอดภัย ข้อผิดพลาดทางตรรกะ และจุดอ่อนที่ผู้โจมตีอาจใช้ประโยชน์ได้ [1]

แตกต่างจาก Penetration Testing ที่ทดสอบระบบจากภายนอก (Black-box หรือ Grey-box) Source Code Review ตรวจสอบ จากภายใน โดยดูโค้ดโดยตรง ทำให้สามารถค้นพบช่องโหว่ที่ซ่อนอยู่ในตรรกะทางธุรกิจซึ่ง Scanner อาจไม่พบ

กระบวนการ Source Code Review แบ่งเป็น 2 รูปแบบหลัก:

• Manual Code Review — ผู้เชี่ยวชาญด้านความปลอดภัยตรวจสอบโค้ดด้วยตาและประสบการณ์
• Static Application Security Testing (SAST) — ใช้เครื่องมืออัตโนมัติสแกนโค้ดเพื่อหา Pattern ที่เป็นช่องโหว่

ทำไม Source Code Review ถึงสำคัญ

ช่องโหว่ OWASP Top 10 ส่วนใหญ่ป้องกันได้ที่ระดับโค้ด

OWASP Top 10 คือรายการช่องโหว่ที่พบบ่อยที่สุดใน Web Application จัดทำโดย Open Worldwide Application Security Project (OWASP) โดยช่องโหว่เกือบทุกรายการสามารถป้องกันหรือตรวจจับได้ผ่าน Source Code Review [2]:

ค่าใช้จ่ายในการแก้ไขต่ำกว่า

การค้นพบช่องโหว่ในขั้นตอนการเขียนโค้ดมีค่าใช้จ่ายในการแก้ไขต่ำกว่าการค้นพบหลัง Deploy อย่างมาก ตามหลัก “Shift Left” ยิ่งพบช่องโหว่เร็ว ยิ่งแก้ไขได้ถูกและง่ายกว่า [3]

ประเภทของ Source Code Review

1. Manual Peer Review (ตรวจสอบโดยผู้เชี่ยวชาญ)

ผู้เชี่ยวชาญด้านความปลอดภัยตรวจสอบโค้ดทีละบรรทัด โดยเน้นที่:

• Business Logic Flaws — ข้อผิดพลาดทางตรรกะที่เครื่องมือไม่สามารถตรวจจับได้
• Authentication & Authorization — กระบวนการยืนยันตัวตนและการควบคุมสิทธิ์
• Data Flow Analysis — ติดตามเส้นทางข้อมูลจาก Input ถึง Output

ข้อดี: ตรวจจับ Logic Flaws ที่เครื่องมือไม่เห็น, เข้าใจ Context ทางธุรกิจ
ข้อเสีย: ใช้เวลามาก, ขึ้นอยู่กับความเชี่ยวชาญของผู้ตรวจ

2. Automated SAST (Static Application Security Testing)

เครื่องมือสแกนซอร์สโค้ดอัตโนมัติเพื่อค้นหา Pattern ที่เป็นช่องโหว่ โดยวิเคราะห์โค้ดโดยไม่ต้องรันแอปพลิเคชัน [3]:

ข้อดี: สแกนได้ครอบคลุมทุกบรรทัดโค้ด, รวดเร็ว, ทำซ้ำได้ง่าย
ข้อเสีย: มี False Positive สูง, ไม่เข้าใจ Business Logic, ต้องมีผู้เชี่ยวชาญตรวจสอบผลลัพธ์

3. Hybrid Approach (แนวทางผสม) — แนะนำ

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

ช่องโหว่ที่พบบ่อยจาก Source Code Review

1. Hardcoded Secrets (ข้อมูลลับฝังในโค้ด)

# ❌ ข้อผิดพลาดที่พบบ่อย
API_KEY = "sk-live-abc123def456"
DB_PASSWORD = "P@ssw0rd123"
JWT_SECRET = "mysecretkey"

ข้อมูลลับเช่น API Key, Password, Secret Key ที่ฝังอยู่ในซอร์สโค้ดสามารถถูกเข้าถึงได้ง่ายเมื่อโค้ดรั่วไหลหรืออยู่ใน Repository สาธารณะ

แก้ไข: ใช้ Environment Variables หรือ Secret Manager เช่น HashiCorp Vault, AWS Secrets Manager

2. SQL Injection Patterns

# ❌ ช่องโหว่ SQL Injection
query = "SELECT * FROM users WHERE id = " + user_input

# ✅ ใช้ Parameterized Query
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, (user_input,))

การต่อ String ในคำสั่ง SQL โดยตรงเปิดโอกาสให้ผู้โจมตีแทรกคำสั่ง SQL ที่เป็นอันตราย

3. Insecure Cryptography (การเข้ารหัสที่ไม่ปลอดภัย)

• ใช้อัลกอริทึมที่ล้าสมัย เช่น MD5, SHA-1 สำหรับ Hash Password
• ใช้ Encryption Key ที่สั้นเกินไป
• ไม่ใช้ Salt ในการ Hash Password
• ใช้ ECB Mode ในการเข้ารหัส

แก้ไข: ใช้ bcrypt, Argon2 หรือ PBKDF2 สำหรับ Password Hashing และ AES-256-GCM สำหรับ Encryption

4. Missing Input Validation (ไม่ตรวจสอบ Input)

• ไม่ตรวจสอบประเภทข้อมูล ขนาด หรือรูปแบบของ Input
• ไม่ทำ Output Encoding ก่อนแสดงผลบนหน้าเว็บ (XSS)
• ไม่จำกัดขนาดไฟล์ที่อัปโหลด
• ไม่ตรวจสอบ File Type ของไฟล์ที่อัปโหลด

5. Insecure Direct Object Reference (IDOR)

# ❌ ช่องโหว่ IDOR
@app.route('/api/user/<user_id>')
def get_user(user_id):
    return db.get_user(user_id)  # ไม่ตรวจสอบสิทธิ์

# ✅ ตรวจสอบสิทธิ์ก่อนเข้าถึง
@app.route('/api/user/<user_id>')
@login_required
def get_user(user_id):
    if current_user.id != user_id and not current_user.is_admin:
        return abort(403)
    return db.get_user(user_id)

เครื่องมือ SAST ที่นิยมใช้

เครื่องมือเสริมที่ควรใช้คู่กัน

• Gitleaks / TruffleHog — ตรวจจับ Secrets ในโค้ดและ Git History
• Dependency-Check (OWASP) — ตรวจสอบ Library ที่มีช่องโหว่ (SCA)
• ESLint Security Plugin — ตรวจสอบ JavaScript/TypeScript

เมื่อไหร่ควรทำ Source Code Review

1. ก่อน Deploy ขึ้น Production

ทุกครั้งที่มีโค้ดใหม่จะขึ้น Production ควรผ่านการ Review ทั้งจาก SAST และ Manual Review สำหรับส่วนที่สำคัญ

2. หลัง Major Change หรือ Feature ใหม่

เมื่อมีการเปลี่ยนแปลงครั้งใหญ่ เช่น ระบบ Authentication ใหม่, Payment Gateway, API ใหม่ ควรทำ Security-focused Code Review

3. ตาม Secure SDLC (Software Development Life Cycle)

ในกระบวนการพัฒนาซอฟต์แวร์ที่ปลอดภัย (Secure SDLC) Source Code Review ควรเป็นส่วนหนึ่งของทุก Sprint:

Requirements → Design Review → Coding → SAST + Code Review → Testing → DAST/Pentest → Deploy → Monitoring

4. เมื่อต้องปฏิบัติตาม Compliance

มาตรฐานหลายฉบับกำหนดให้ต้องทำ Code Review:

• PCI DSS (Requirement 6.3) — กำหนดให้ทำ Code Review สำหรับ Custom Code
• ISO 27001:2022 (A.8.28) — Secure Coding เป็น Control ใหม่
• PDPA — มาตรการรักษาความปลอดภัยที่เหมาะสมรวมถึงการตรวจสอบโค้ด

Source Code Review vs. Penetration Testing

คำแนะนำ: ควรทำทั้งสองอย่างเพื่อความครอบคลุมสูงสุด — Source Code Review เป็นด่านแรก, Penetration Testing เป็นด่านสุดท้ายก่อน Go-live

ITSL ช่วยองค์กรได้อย่างไร

• Secure Coding Training — อบรมทีม Developer ให้เขียนโค้ดที่ปลอดภัยตาม OWASP
• Web Application Penetration Testing — ทดสอบเจาะระบบ Web Application คู่กับ Code Review

---

แหล่งอ้างอิง

1. OWASP, “OWASP Code Review Guide v2,” Open Worldwide Application Security Project. https://owasp.org/www-project-code-review-guide/
2. OWASP, “OWASP Top 10:2021,” Open Worldwide Application Security Project, 2021. https://owasp.org/Top10/
3. SentinelOne, “OWASP Top 10: Vulnerabilities, Risks and How to Fix Them,” 2025. https://www.sentinelone.com/cybersecurity-101/cybersecurity/owasp-top-10
4. Codacy, “OWASP Explained: Secure Coding Best Practices,” 2025. https://blog.codacy.com/owasp-top-10
5. GitLab, “OWASP Top 10 2025: What’s changed and why it matters,” 2025. https://about.gitlab.com/blog/2025-owasp-top-10-whats-changed-and-why-it-matters