AppSec & DevSecOps

ทีม security ที่ทำ code review ตอน release week มักถูกมองว่าเป็นปัญหา เพราะพบช่องโหว่ในเวลาที่แก้ได้ยากและราคาแพงที่สุด บทนำนี้อธิบายแนวคิด shift-left security, DevSecOps และ security champion program ที่ทำให้ security กลายเป็นส่วนหนึ่งของ development lifecycle ไม่ใช่ door ที่ปิดกั้นก่อน production พร้อมเล่าถึง SSDF ของ NIST และ OWASP ASVS ที่เป็นมาตรฐานอ้างอิงในการวาง AppSec program ปัจจุบัน

 

กรณี MOVEit ในปี 2566 และ XZ Utils backdoor ในปี 2567 แสดงให้เห็นว่าช่องโหว่ของ application และ open source component เป็นช่องทางหลักของเหตุการณ์ระดับวงกว้าง การทดสอบเฉพาะช่วง UAT หรือก่อนขึ้น production เพียงอย่างเดียว ไม่สามารถครอบคลุมช่องโหว่ที่ซ่อนอยู่ใน dependency หรือใน configuration ได้ ด้วยเหตุนี้ องค์กรชั้นนำในภูมิภาคจึงปรับแนวทางไปสู่ secure-by-design ที่ฝังการตรวจสอบเข้าไปในทุก phase ของ SDLC

 

Series J จัดโครงสร้างตามกรอบสามเสา ประกอบด้วย Shift Left ที่วาง control ในเฟสออกแบบและเขียนโค้ด, Shift Right ที่ทดสอบในสภาพ production-like และ runtime และ Shift Everywhere ที่ครอบคลุม infrastructure as code, container และ API ซึ่งเป็นพื้นที่ที่การโจมตีสมัยใหม่เล็งเป้าเป็นพิเศษ

 

70%

ของ application ในองค์กรทั่วโลกมีช่องโหว่ระดับ OWASP Top 10 อย่างน้อยหนึ่งรายการ (Veracode)

 

9 วัน

ค่าเฉลี่ยเวลาที่ผู้โจมตีใช้จาก disclosure ถึงการ exploit ช่องโหว่ใน application สมัยใหม่

 

หลายสิบเท่า

ของความแตกต่างระหว่างต้นทุนแก้ช่องโหว่ในเฟสออกแบบ/พัฒนา เทียบกับช่วงหลัง production (NIST/IBM Systems Sciences Institute)

 

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

 

 

CHAPTER ONE · THE BASELINE

 

 

OWASP Top 10 ปี 2021 ประกอบด้วย A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable Components, A07 Authentication Failures, A08 Software & Data Integrity, A09 Security Logging Failures และ A10 SSRF จากการ pentest องค์กรไทยโดยทั่วไป ช่องโหว่ที่พบบ่อยที่สุดคือ A01 Broken Access Control และ A06 Vulnerable Components ซึ่งสะท้อนว่า access control design และ dependency management ยังเป็นจุดอ่อน

 

“OWASP Top 10 ปี 2021 ไม่ต่างจากปี 2017 เท่าไหร่ — เพราะองค์กรยังแก้ไม่จบจากรอบก่อน”

 

 

CHAPTER TWO · THE TESTING

 

 

SAST (Static Application Security Testing) วิเคราะห์ source code หา pattern ของช่องโหว่ เหมาะกับทีมที่เริ่มต้น เพราะ integrate เข้า IDE และ CI/CD ได้ง่าย — Semgrep (free), SonarQube, Checkmarx, Veracode เป็นตัวเลือกยอดนิยม DAST (Dynamic) ทดสอบ running application เหมาะกับ application ที่ deploy แล้ว — OWASP ZAP (free), Burp Suite, Invicti

 

“Security test ที่ใช้เวลา 2 ชั่วโมงต่อ PR = dev team จะพยายามหลบ security”

 

 

CHAPTER THREE · THE DEPENDENCIES

 

 

SCA คือการ scan dependency (library, package) เพื่อหา known vulnerability ใน component ที่ใช้ Snyk, Dependabot, Trivy, OWASP Dependency-Check เป็นเครื่องมือยอดนิยม การ scan ควรทำทั้งที่ PR time (fail build ถ้ามี critical vuln ใหม่) และต่อเนื่อง (alert เมื่อมี CVE ใหม่ใน component ที่ deploy อยู่)

 

“Open source dependency ไม่ใช่ฟรี — คุณจ่ายด้วยภาระในการ patch ตลอด lifetime”

 

 

CHAPTER FOUR · THE REPOSITORY

 

 

Secret ที่ commit เข้า repository (API key, password, private key, token) เป็นต้นเหตุของ breach หลายกรณี เครื่องมือ secret scanning เช่น GitGuardian, GitHub Secret Scanning, Gitleaks, TruffleHog ควรติดตั้งในระดับ repo level พร้อมกับ pre-commit hook ที่ block commit ที่มี secret การตรวจจับย้อนหลัง (ใน git history) เป็นสิ่งสำคัญ เพราะ secret ที่ commit แล้วลบไม่ได้ช่วยหากมีใครเห็นก่อน

 

“Secret ใน repo เป็น time bomb — คำถามคือใครจะพบก่อน คุณหรือผู้โจมตี”

 

 

CHAPTER FIVE · THE RUNTIME

 

 

WAF ที่ deploy ดี protect application จาก common attack (SQL injection, XSS, path traversal) โดยไม่ต้องแก้ code ทันที แต่ WAF ที่ไม่ tune = block legitimate traffic หรือปล่อย attack ผ่าน การ tune WAF ต้องเริ่มจาก monitor mode, analyze traffic pattern, และปรับ rule ตามลักษณะของ application — generic rule ของ OWASP Core Rule Set เป็นจุดเริ่มต้น แต่ต้องปรับสำหรับ API, form validation และ business logic

 

“WAF ที่เปิดทั้งหมด rule จะ block ทุก legitimate request — ต้อง tune”

 

 

CHAPTER SIX · THE DESIGN

 

 

Threat modeling แบบดั้งเดิม (STRIDE, PASTA, LINDDUN) ใช้เวลา 1-2 วันต่อ feature ซึ่งไม่ scale ใน agile team แนวทางที่ใช้งานได้คือ lightweight threat modeling — 30-60 นาทีต่อ feature โดยใช้คำถามมาตรฐาน 4 ข้อ (Shostack's Four Question Framework) — what are we building, what can go wrong, what are we going to do about it, did we do a good enough job

 

“Threat modeling ที่ใช้เวลา 2 วันต่อ feature = ไม่มีใครทำ”

 

 

CHAPTER SEVEN · THE GOVERNANCE

 

 

KPI ของ AppSec ที่ดีที่สุดไม่ใช่จำนวน vuln ที่พบ แต่คือ — Mean Time to Remediate (MTTR) แยกตาม severity, % ของ PR ที่มี security review, % coverage ของ SAST/DAST, จำนวน critical vuln ที่ reach production, และจำนวน security incident ที่เกิดจาก code ของ application การรายงาน KPI ในรูปแบบที่สะท้อนต่อ business (เช่น 'feature ใหม่ 5 ฟีเจอร์ผ่าน security review โดยไม่มี critical finding') ช่วยให้ผู้บริหารเข้าใจคุณค่า

 

“KPI ที่ดีของ AppSec ไม่ใช่จำนวน vuln ที่พบ แต่คือเวลาเฉลี่ยในการแก้”

 

 

AppSec ที่ประสบความสำเร็จในปี 2569 คือ AppSec ที่ไม่ถูกมองว่าเป็นอุปสรรค เพราะถูกฝังใน developer workflow ตั้งแต่ต้น การออกแบบ DevSecOps pipeline ที่ balance ระหว่าง security และ velocity จึงเป็นโจทย์ของทั้งทีม security และ engineering ร่วมกัน

 

หากท่านต้องการเนื้อหาฉบับเต็มที่ครอบคลุมทุกบท พร้อมแนวปฏิบัติเชิงเทคนิค ตัวอย่าง workflow และคำศัพท์เฉพาะทาง กดตาม URL นี้เพื่อดาวน์โหลด: