0Pricing
Security+ Academy · บทเรียน

SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST

ผสานความปลอดภัยเข้ากับวงจรชีวิตการพัฒนาซอฟต์แวร์ โดยใช้การวิเคราะห์แบบสถิต (SAST) การวิเคราะห์แบบพลวัต (DAST) และการสร้างแบบจำลองภัยคุกคามตั้งแต่ช่วงต้นของการพัฒนา

SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

Secure SDLC คืออะไร

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

เลื่อน Security ให้เร็วขึ้นในกระบวนการพัฒนา

การเลื่อน Security ไปทางซ้าย หมายถึงการนำ Security มาไว้ตั้งแต่ช่วงต้นของกระบวนการพัฒนา แทนที่จะค่อยเพิ่มเข้าไปในตอนท้าย ในทางปฏิบัติ หมายถึงการใส่ข้อกำหนดด้าน Security ไว้ในเรื่องราวของผู้ใช้ การทำแบบจำลองภัยคุกคามระหว่างการออกแบบ การตรวจสอบโค้ดและเรียกใช้ SAST ระหว่างการพัฒนา และการเรียกใช้ DAST ก่อนการเผยแพร่ Team ที่เลื่อน Security ไปทางซ้ายจะพบช่องโหว่ในช่วงที่แก้ไขได้ถูกที่สุด คือระหว่างการพัฒนา ไม่ใช่ในระบบจริง

การสร้างแบบจำลองภัยคุกคาม: STRIDE และ PASTA

การสร้างแบบจำลองภัยคุกคาม จะระบุและจัดทำเอกสารเกี่ยวกับภัยคุกคามด้าน Security อย่างเป็นระบบในระยะการออกแบบ แบบจำลอง STRIDE จัดหมวดหมู่ภัยคุกคามเป็น: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service และ Elevation of Privilege ส่วน PASTA (กระบวนการจำลองการโจมตีและวิเคราะห์ภัยคุกคาม) เป็นระเบียบวิธีที่มุ่งเน้นความเสี่ยงและจำลองเป้าหมายของผู้โจมตี แบบจำลองภัยคุกคามจะสร้างแนวทางลดความเสี่ยงที่จัดลำดับความสำคัญแล้ว ก่อนที่จะเขียนโค้ดแม้แต่บรรทัดเดียว

# STRIDE threat categories (mnemonic)
# S - Spoofing identity
# T - Tampering with data
# R - Repudiation of actions
# I - Information disclosure
# D - Denial of service
# E - Elevation of privilege

การทดสอบ Security ของแอปพลิเคชันแบบสถิต (SAST)

SAST (การทดสอบแบบกล่องขาว) จะวิเคราะห์ซอร์สโค้ด ไบต์โค้ด หรือไบนารีโดยไม่เรียกใช้แอปพลิเคชัน และค้นหารูปแบบการเขียนโค้ดที่เกี่ยวข้องกับช่องโหว่ที่ทราบแล้ว เครื่องมือ SAST สามารถสแกนฐานโค้ดทั้งหมดได้อย่างรวดเร็ว และรายงานปัญหา เช่น ข้อมูลประจำตัวที่ฝังไว้ในโค้ด จุดรับข้อมูลของการโจมตีแบบ SQL injection และการดีซีเรียลไลซ์ที่ไม่ปลอดภัย เครื่องมือเหล่านี้ทำงานภายใน IDE หรือ CI pipeline และรายงานสิ่งที่พบพร้อมหมายเลข file และ line ทำให้แก้ไขได้โดยตรง

# Example: running Semgrep SAST in CI
semgrep --config=auto --error src/

# Common SAST tools:
# - Checkmarx, Veracode, Fortify (commercial)
# - Semgrep, SonarQube, Bandit (open source)
# - GitHub CodeQL (integrated with GitHub Actions)

ข้อจำกัดของ SAST: ผลบวกลวง

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

การทดสอบ Security ของแอปพลิเคชันแบบไดนามิก (DAST)

DAST (การทดสอบแบบกล่องดำ) จะทดสอบแอปพลิเคชันที่กำลังทำงานอยู่โดยส่งข้อมูลโจมตีไปยังจุดปลายทาง HTTP และวิเคราะห์การตอบสนองเพื่อค้นหาตัวบ่งชี้ช่องโหว่ DAST ไม่จำเป็นต้องเข้าถึงซอร์สโค้ด เพราะทดสอบแอปพลิเคชันในลักษณะเดียวกับผู้โจมตี วิธีนี้เหมาะอย่างยิ่งสำหรับค้นหาปัญหาขณะทำงาน เช่น การข้ามการตรวจสอบ Authentication, XSS ที่สะท้อนกลับในการตอบสนอง และการตั้งค่า Server ที่ไม่ปลอดภัย เครื่องมือ DAST ได้แก่ OWASP ZAP, เบิร์ปสวีต และเน็ตสปาร์กเกอร์

# Running OWASP ZAP baseline scan against a URL
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.example.com \
  -r zap-report.html

# ZAP sends probe requests and analyzes responses
# without requiring source code access

SAST กับ DAST: แนวทางที่เสริมกัน

SAST และ DAST เป็นแนวทางที่เสริมกัน ไม่ใช่คู่แข่งกัน SAST ค้นพบปัญหาระดับโค้ดได้ตั้งแต่เนิ่น ๆ และผสานเข้ากับ IDE ได้ แต่ไม่สามารถมองเห็นพฤติกรรมขณะทำงาน DAST ค้นพบช่องโหว่ขณะทำงานและไม่ต้องใช้ซอร์สโค้ด แต่ไม่สามารถสแกนเส้นทางโค้ดที่ไม่ได้ถูกกระตุ้นโดยตัวตรวจสอบอัตโนมัติ การใช้ทั้งสองอย่างร่วมกัน — SAST ใน CI pipeline และ DAST กับสภาพแวดล้อมสำหรับเตรียมใช้งาน — ช่วยเพิ่มความครอบคลุมของช่องโหว่ให้สูงสุดตลอด SDLC

การทดสอบ Security ของแอปพลิเคชันแบบโต้ตอบ (IAST)

IAST ผสานองค์ประกอบของทั้ง SAST และ DAST โดยติดตั้งเครื่องมือสำหรับตรวจสอบภายในแอปพลิเคชันขณะทำงาน ตัวแทน IAST จะทำงานอยู่ภายในแอปพลิเคชัน (บน Server) และสังเกตการทำงานของโค้ดขณะที่การรับส่งข้อมูลทดสอบไหลผ่าน ตัวแทนนี้สามารถเชื่อมโยง input ของผู้ใช้ที่ปนเปื้อนผ่านเส้นทางโค้ดไปยังจุดรับข้อมูลสำคัญ ทำให้ค้นพบช่องโหว่โดยมีอัตราผลบวกลวงต่ำกว่า SAST แบบล้วน ๆ IAST มีประสิทธิภาพเป็นพิเศษในแอปพลิเคชัน Java และดอตเน็ต และผสานเข้ากับการเรียกใช้การทดสอบเชิงฟังก์ชันได้อย่างเป็นธรรมชาติ

การวิเคราะห์องค์ประกอบซอฟต์แวร์ (SCA)

การวิเคราะห์องค์ประกอบซอฟต์แวร์ (SCA) จะระบุไลบรารีโอเพนซอร์สและ Dependency ของบุคคลที่สามในแอปพลิเคชัน แล้วตรวจสอบกับฐานข้อมูลช่องโหว่ (NVD, OSV) เนื่องจากแอปพลิเคชันสมัยใหม่อาจดึง Dependency มาหลายร้อยรายการ — โดยหลายรายการเป็น Dependency ที่ส่งต่อกันมา — เครื่องมือ SCA เช่น OWASP Dependency-Check, Snyk และ Renovate จึงมีความสำคัญอย่างยิ่งในการตรวจพบ CVEs ที่ทราบแล้ว ก่อนที่ผู้โจมตีจะใช้ประโยชน์จากช่องโหว่เหล่านั้นในห่วงโซ่อุปทานของคุณ

# OWASP Dependency-Check (scans project dependencies)
dependency-check --project myapp --scan ./target --format HTML

# Snyk CLI
snyk test  # finds vulnerabilities in package.json / requirements.txt
snyk monitor  # continuously monitors for new CVEs

Security ใน CI/CD pipeline

การผสานเครื่องมือด้าน Security เข้ากับ CI/CD pipeline ช่วยให้มั่นใจว่าไม่มีโค้ดใดเข้าสู่ระบบจริงโดยไม่ผ่านด่านตรวจด้าน Security pipeline แบบ DevSecOps ทั่วไปจะเรียกใช้: SAST ในทุกการ commit, SCA เมื่อ Dependency เปลี่ยนแปลง การสแกนอิมเมจ Container ก่อนส่งไปยังรีจิสทรี การสแกน IaC สำหรับ Terraform/CloudFormation และ DAST กับการนำไปใช้งานในสภาพแวดล้อมสำหรับเตรียมใช้งาน การตรวจสอบ Security ที่ไม่ผ่านจะบล็อกการ build และบังคับใช้วัฒนธรรมที่กำหนดให้ Security เป็นค่าเริ่มต้น

# GitHub Actions example — security gate in CI
jobs:
  security:
    steps:
      - uses: actions/checkout@v4
      - name: Run SAST
        run: semgrep --config=auto --error .
      - name: SCA check
        run: snyk test --severity-threshold=high
      - name: Container scan
        run: trivy image myapp:latest --exit-code 1

แนวทางการตรวจสอบโค้ดที่ปลอดภัย

เครื่องมืออัตโนมัติไม่สามารถทดแทน การตรวจสอบโค้ด โดยมนุษย์ที่มุ่งเน้นตรรกะด้าน Security ได้ การตรวจสอบโดยเพื่อนร่วมงานควรยืนยันว่า การตรวจสอบ Authentication และสิทธิ์ได้รับการวางไว้ในตำแหน่งที่ถูกต้อง การจัดการข้อผิดพลาดไม่เปิดเผย Information ที่ละเอียดอ่อน ฟังก์ชันการเข้ารหัสใช้อัลกอริทึมและพารามิเตอร์ที่ได้รับอนุมัติ และตรรกะทางธุรกิจไม่สามารถถูกข้ามได้ Security champion ภายใน Team พัฒนา ซึ่งเป็นนักพัฒนาที่ผ่านการฝึกอบรมด้าน Security จะช่วยเชื่อมช่องว่างระหว่าง Team Security กับฝ่าย Engineering

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า SDLC ที่ปลอดภัยผสาน Security เข้ากับทุกระยะของการพัฒนา แทนที่จะค่อยเพิ่มเข้าไปในตอนท้าย SAST วิเคราะห์โค้ดโดยไม่เรียกใช้ ขณะที่ DAST ทดสอบแอปพลิเคชันที่กำลังทำงาน และ SCA ระบุ Dependency โอเพนซอร์สที่มีช่องโหว่ ส่วนด่านตรวจ Security ใน CI/CD จะบังคับใช้สิ่งที่ตรวจพบโดยอัตโนมัติ บทถัดไปเราจะสำรวจบริการ Directory ด้วย LDAP และ Active Directory

คำถามที่พบบ่อย

บทเรียน “SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST”

ผสานความปลอดภัยเข้ากับวงจรชีวิตการพัฒนาซอฟต์แวร์ โดยใช้การวิเคราะห์แบบสถิต (SAST) การวิเคราะห์แบบพลวัต (DAST) และการสร้างแบบจำลองภัยคุกคามตั้งแต่ช่วงต้นของการพัฒนา คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม

ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การแทรกคำสั่ง SQL และคำสั่งระบบ
  2. การเขียนสคริปต์ข้ามไซต์ (XSS) และ CSRF
  3. การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย
  4. SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST
← กลับไปที่ Security+ Academy