DevSecOps: SAST, DAST และ SCA ใช้อย่างไร

DevSecOps คือแนวทางที่ฝังการตรวจความปลอดภัยไว้ในทุกขั้นตอนของการเขียนและปล่อยซอฟต์แวร์ ไม่รอไปตรวจตอนท้ายสุด ทุกครั้งที่ทีมแก้งาน เครื่องมืออัตโนมัติจะตรวจทั้งโค้ดและระบบที่รันอยู่ เครื่องมือที่ใช้บ่อยมี 3 ชนิด ได้แก่ SAST (ตรวจซอร์สโค้ดซึ่งเป็นโค้ดต้นฉบับ โดยไม่ต้องรันโปรแกรม) DAST (ทดสอบแอปที่กำลังรันอยู่จากภายนอก เหมือนผู้โจมตีลองเจาะ) และ SCA (ตรวจไลบรารี คือชุดโค้ดสำเร็จรูปของบุคคลที่สามที่ซอฟต์แวร์นำมาใช้ ว่ามีช่องโหว่ที่เปิดเผยแล้วหรือไม่) บทความนี้อธิบายว่าทั้ง 3 ชนิดต่างกันอย่างไร ควรวางไว้ตรงไหนของสายงานพัฒนา และเริ่มใช้อย่างไรไม่ให้การแจ้งเตือนท่วมทีม

DevSecOps ในทางปฏิบัติ

ทีมพัฒนาส่วนใหญ่มี CI/CD pipeline อยู่แล้ว คือสายงานอัตโนมัติที่ build (ประกอบโค้ดให้เป็นซอฟต์แวร์) ทดสอบ และปล่อยซอฟต์แวร์ทุกครั้งที่โค้ดเปลี่ยน DevSecOps คือการแทรกการตรวจความปลอดภัยเข้าไปในสายงานนี้ โดยทั่วไป ช่องโหว่ที่เจอตอนเขียนโค้ดแก้ง่ายกว่าช่องโหว่ที่เจอหลังระบบขึ้นใช้งานจริง แนวคิดนี้มักเรียกว่า shift left คือย้ายการตรวจไปไว้ต้นทางของงาน

SAST DAST และ SCA ต่างกันอย่างไร

เครื่องมือทั้ง 3 ชนิดมองซอฟต์แวร์คนละมุม จึงตอบคำถามคนละข้อ

• SAST: ตรวจซอร์สโค้ดที่ทีมเขียนเอง โดยไม่ต้องรันโปรแกรม ใช้ได้ตั้งแต่ช่วงเขียนโค้ด เพื่อหาช่องโหว่ ข้อผิดพลาดในการเขียนโปรแกรม และโค้ดที่ไม่เป็นไปตามมาตรฐานการเขียนโค้ด
• DAST: ส่งข้อมูลโจมตีจำลองเข้าไปในแอปที่กำลังรันอยู่ เหมือนผู้โจมตีที่มองไม่เห็นซอร์สโค้ด (เรียกว่าการทดสอบแบบ black-box) เพื่อหาช่องโหว่ เช่น SQL injection (การแทรกคำสั่งฐานข้อมูลผ่านช่องกรอกข้อมูล) และ XSS (cross-site scripting คือการแทรกสคริปต์ให้ไปทำงานในเบราว์เซอร์ของผู้ใช้) รวมถึงปัญหาการยืนยันตัวตนและการตั้งค่าเซิร์ฟเวอร์ผิดพลาด DAST ไม่ต้องใช้ซอร์สโค้ด
• SCA: ตรวจไลบรารีโอเพนซอร์สและไลบรารีของบุคคลที่สามที่ซอฟต์แวร์เรียกใช้ ว่ามีช่องโหว่ที่เปิดเผยต่อสาธารณะแล้วหรือไม่ และแต่ละตัวใช้สัญญาอนุญาต (license) แบบใด

ไม่มีเครื่องมือชนิดใดครอบคลุมได้ทุกเรื่อง SCA หาได้เฉพาะช่องโหว่ที่เปิดเผยแล้วในส่วนประกอบที่รู้จัก และไม่ตรวจโค้ดที่ทีมเขียนเอง SAST ไม่เห็นพฤติกรรมของระบบตอนรันจริง และผลบางรายการอาจไม่ใช่ช่องโหว่จริง เรียกว่า false positive (การแจ้งเตือนผิดพลาด) จึงต้องมีคนคัดกรองว่ารายการไหนจริง DAST ทดสอบได้เฉพาะแอปที่รันอยู่ และมักบอกไม่ได้ว่าปัญหามาจากโค้ดบรรทัดใด ด้วยเหตุนี้องค์กรจึงใช้ทั้ง 3 ชนิดร่วมกัน

วางการตรวจไว้ตรงไหนของสายงาน

ตัวอย่างการวางต่อไปนี้เป็นแนวทางที่พบบ่อย ไม่ใช่ข้อบังคับ ทีมปรับได้ตามเครื่องมือและเวลาที่มี หลักคิดคือให้เครื่องมือที่ตรวจเร็วและไม่ต้องมีแอปรันอยู่ ไปอยู่ต้นสายงาน ส่วนเครื่องมือที่ต้องมีแอปรันอยู่ ให้ไปอยู่หลังติดตั้งแอปในระบบทดสอบ OWASP DevSecOps Guideline ระบุว่าเพิ่มระบบอัตโนมัติทีละส่วนและปรับให้เข้ากับกระบวนการพัฒนาของตนได้ รายการ pipeline พื้นฐานของแนวทางนี้วาง SCA เป็นลำดับที่สอง ต่อจากการสแกนหาความลับที่รั่วในที่เก็บโค้ด และก่อน SAST กับ DAST โดยไม่ได้ระบุว่าเป็นลำดับที่บังคับ

• ตอนเขียนโค้ด: ตรวจหารหัสผ่านหรือ token ที่เผลอใส่ลงในโค้ด (เรียกว่า secrets scanning) ก่อนโค้ดเข้าที่เก็บโค้ดกลาง (repository)
• ตอนส่งโค้ดเข้าตรวจ (pull request คือคำขอรวมโค้ด ที่ผู้เขียนส่งให้ทีมตรวจก่อนรวมเข้าโค้ดหลัก): รัน SCA และ SAST แล้วแสดงผลให้ผู้เขียนเห็นทันที
• ตอน build: ตรวจไลบรารีอีกรอบ และสร้าง SBOM (รายการส่วนประกอบของซอฟต์แวร์) เก็บไว้คู่กับงานที่ build ออกมา
• ตอนทดสอบในระบบทดสอบ (staging): รัน DAST กับแอปที่ติดตั้งแล้ว อาจตั้งให้รันทุกคืน
• หลังขึ้นระบบจริง: เฝ้าดูช่องโหว่ใหม่ของไลบรารีที่ใช้อยู่อย่างต่อเนื่อง เพราะมีช่องโหว่ใหม่ประกาศได้ทุกวัน แม้โค้ดของเราไม่ได้เปลี่ยน

การตรวจแบบอื่นในสายงานเดียวกัน

OWASP DevSecOps Guideline ยังรวมการตรวจแบบอื่นที่เติมเพิ่มได้ภายหลัง

• การตรวจ IaC (infrastructure as code คือไฟล์ที่ใช้สร้างระบบโครงสร้างพื้นฐานโดยอัตโนมัติ): ตรวจไฟล์ เช่น Terraform และ Helm chart ก่อนนำไปสร้างระบบจริง
• IAST (การตรวจจากภายในแอป ขณะที่แอปรันและกำลังถูกทดสอบ): ตัวตรวจฝังอยู่ในแอป จึงเห็นการทำงานจริงระหว่างทดสอบ
• ความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์ (supply chain): เช่น SBOM การเซ็นรับรองไฟล์ที่ build ออกมา และการรักษาความปลอดภัยของ CI/CD pipeline ดู SBOM และความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์
• ความปลอดภัยของ API (ช่องทางที่แอปเปิดให้โปรแกรมอื่นเรียกใช้): ตรวจ API ที่แอปเปิดให้ใช้ แยกจากหน้าเว็บ

โค้ดที่ AI ช่วยเขียนควรผ่านการตรวจชุดเดียวกับโค้ดที่คนเขียน ดู ความปลอดภัยของ AI Coding Assistant และ Vibe Coding ส่วนประเภทช่องโหว่ที่พบบ่อยในเว็บแอปพลิเคชันสรุปไว้ใน สรุป OWASP Top 10 สำหรับเว็บแอปพลิเคชัน

วัดความพร้อมด้วยกรอบอ้างอิง

NIST SP 800-218 หรือ SSDF (กรอบแนวปฏิบัติสำหรับพัฒนาซอฟต์แวร์อย่างปลอดภัย) แบ่งแนวปฏิบัติเป็น 4 กลุ่ม ได้แก่ เตรียมองค์กร (PO) ปกป้องซอฟต์แวร์ (PS) สร้างซอฟต์แวร์ให้ปลอดภัย (PW) และตอบสนองต่อช่องโหว่ (RV) งานตรวจโค้ดและทดสอบซอฟต์แวร์อยู่ในกลุ่ม PW เป็นหลัก

SSDF เวอร์ชัน 1.1 เป็นฉบับสมบูรณ์ (กุมภาพันธ์ 2022) NIST ออกฉบับร่างเวอร์ชัน 1.2 (SP 800-218 Rev. 1) เมื่อ 17 ธันวาคม 2025 และปิดรับความเห็นเมื่อ 30 มกราคม 2026 หน้ารวมเอกสาร SSDF ที่ตรวจเมื่อ 27 ตุลาคม 2026 ยังแสดงเวอร์ชัน 1.2 เป็นฉบับร่าง ควรตรวจสถานะล่าสุดที่เว็บไซต์ NIST ก่อนอ้างอิง

OWASP SAMM (แบบจำลองวัดระดับความพร้อมด้านความปลอดภัยของการพัฒนาซอฟต์แวร์) ช่วยให้องค์กรรู้ว่าตอนนี้อยู่ตรงไหนและควรไปต่อทางไหน แบ่งเป็น 5 ด้านหลักของธุรกิจ (business function) ได้แก่ Governance (ธรรมาภิบาล) Design (ออกแบบ) Implementation (พัฒนา) Verification (ตรวจสอบ) และ Operations (ปฏิบัติการ) แต่ละด้านมี 3 แนวปฏิบัติ รวมเป็น 15 แนวปฏิบัติ การทดสอบความปลอดภัย (Security Testing) อยู่ในด้าน Verification หน้าโครงการ OWASP ระบุเวอร์ชันล่าสุดเป็น 2.2.0

ข้อผิดพลาดที่พบบ่อย

• เปิดทุกกฎของเครื่องมือตั้งแต่วันแรก: ผลการตรวจหลายร้อยรายการท่วมทีมจนไม่มีใครอ่าน
• ให้ build ล้มทุกครั้งที่เจอผลการตรวจ โดยยังไม่เคยทดลองใช้ก่อน: ทีมจะหาทางปิดเครื่องมือแทนที่จะแก้ปัญหา
• มองผล SAST ทุกรายการว่าเป็นช่องโหว่จริง: ไม่มีขั้นคัดกรอง และไม่มีใครตัดสินว่ารายการนั้นจริงหรือไม่
• ใช้เครื่องมือชนิดเดียวแล้วเข้าใจว่าครอบคลุมทุกเรื่อง: เช่น มี SCA แต่ไม่มีการตรวจโค้ดที่ทีมเขียนเอง
• สแกนแล้วไม่มีเจ้าของรับผิดชอบการแก้: รายงานค้างอยู่โดยไม่มีผู้รับงานและไม่มีกำหนดเวลา
• สแกนเฉพาะก่อนปล่อยครั้งสุดท้าย: ช่องโหว่ใหม่ของไลบรารีที่ใช้อยู่อาจประกาศหลังปล่อยซอฟต์แวร์แล้ว

ขั้นแรกที่ทำได้ทันที

• ทำรายการระบบ: จดแอปที่ทีมพัฒนาเอง ภาษาโปรแกรมที่ใช้ และสายงาน build ของแต่ละแอป
• เริ่มจาก SCA ในโหมดรายงานอย่างเดียว: แสดงผลโดยยังไม่บล็อกการ build เพื่อดูว่าไลบรารีที่ใช้อยู่มีช่องโหว่มากแค่ไหน
• ตรวจหารหัสผ่านและ token ในโค้ด: เปิดใช้ที่ที่เก็บโค้ดกลาง เพื่อจับความลับที่เผลอใส่ลงไป
• เพิ่ม SAST กับโค้ดใหม่ก่อน: เลือกกฎที่ตรวจช่องโหว่ร้ายแรงก่อน แล้วค่อยขยายเพิ่ม
• ตั้ง DAST ในระบบทดสอบ: สแกนเฉพาะระบบที่องค์กรเป็นเจ้าของและได้รับอนุญาตให้ทดสอบ
• ตกลงกฎและเจ้าของงาน: ช่องโหว่ระดับความรุนแรงใดต้องบล็อก build ใครคัดกรอง ใครแก้ และต้องแก้ภายในกี่วัน ดูวิธีจัดลำดับความสำคัญใน โปรแกรมบริหารจัดการช่องโหว่

หากต้องการทราบว่าการพัฒนาและทดสอบซอฟต์แวร์ขององค์กรอยู่ในระดับใดเมื่อเทียบกับแนวปฏิบัติทั่วไป ลองใช้ แบบประเมินตนเอง

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• NIST SP 800-218: SSDF Version 1.1: ฉบับสมบูรณ์ของกรอบแนวปฏิบัติ
• NIST SP 800-218 Rev. 1 (SSDF 1.2) ฉบับร่างแรก: ฉบับร่างเมื่อธันวาคม 2025
• NIST SSDF: หน้าโครงการ: กลุ่มแนวปฏิบัติ PO PS PW RV
• OWASP SAMM: ภาพรวมและเวอร์ชันล่าสุด
• OWASP SAMM: โครงสร้างแบบจำลอง: 5 หน้าที่ทางธุรกิจและ 15 แนวปฏิบัติ
• OWASP DevSecOps Guideline: ภาพรวมเครื่องมือที่เติมในสายงานได้
• OWASP DevSecOps Guideline: SAST: การตรวจซอร์สโค้ด
• OWASP DevSecOps Guideline: DAST: การทดสอบแอปที่รันอยู่
• OWASP DevSecOps Guideline: SCA: การตรวจไลบรารีของบุคคลที่สาม