DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์
ฝังการตรวจสอบความปลอดภัย SAST, DAST, การสแกนคอนเทนเนอร์ และการตรวจสอบความปลอดภัย IaC ไว้ในไปป์ไลน์ CI/CD เพื่อให้ด่านความปลอดภัยถูกบังคับใช้อัตโนมัติทุกครั้งที่ส่งการเปลี่ยนแปลง
DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์ เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
การเลื่อนการรักษาความปลอดภัยไปทางซ้ายคืออะไร
การเลื่อนการรักษาความปลอดภัยไปทางซ้าย หมายถึงการผสานกิจกรรมด้านความปลอดภัยให้เกิดขึ้นเร็วขึ้นในวงจรชีวิตการพัฒนาซอฟต์แวร์ เช่น ใน IDE ของนักพัฒนา การตรวจสอบโค้ด และไปป์ไลน์ CI/CD แทนการทดสอบความปลอดภัยเป็นด่านสุดท้ายก่อนนำไปใช้งาน การตรวจสอบความปลอดภัยแบบดั้งเดิมเกิดขึ้นเมื่อสิ้นสุดรอบการพัฒนา ทำให้การแก้ไขมีค่าใช้จ่ายสูงและใช้เวลานาน การค้นพบช่องโหว่ระหว่างการพัฒนามีค่าใช้จ่ายในการแก้ไขต่ำกว่าการค้นพบในระบบจริงหลังเกิดการรั่วไหลประมาณ 100 เท่า
DevSecOps คืออะไร
DevSecOps ขยายแนวคิดของ DevOps ด้วยการผสานความปลอดภัยให้เป็นความรับผิดชอบร่วมกันของทีมพัฒนา ทีมปฏิบัติการ และทีมความปลอดภัยตลอดทั้ง SDLC เป้าหมายคือการ ทำให้การทดสอบความปลอดภัยเป็นแบบอัตโนมัติ เพื่อให้ทำงานในทุกขั้นตอนได้โดยไม่ทำให้การส่งมอบล่าช้า ความปลอดภัยจึงกลายเป็นคุณสมบัติที่ต้องมีอย่างต่อเนื่องใน pipeline แทนที่จะเป็นเพียงจุดตรวจครั้งเดียว ในโครงการ DevSecOps ที่มีวุฒิภาวะ นักพัฒนาจะได้รับผลป้อนกลับด้านความปลอดภัยภายในไม่กี่วินาทีหลังเขียนโค้ด แทนที่จะต้องรอหลายสัปดาห์หลังการตรวจสอบด้วยมือ
SAST: การทดสอบความปลอดภัยของแอปพลิเคชันแบบสถิต
SAST (การทดสอบความปลอดภัยของแอปพลิเคชันแบบสถิต) วิเคราะห์ซอร์สโค้ด ไบต์โค้ด หรือไบนารีโดยไม่ execute แอปพลิเคชัน เครื่องมือ SAST จะสแกนหารูปแบบที่บ่งชี้ช่องโหว่ เช่น SQL concatenation, เอาต์พุตที่ไม่ได้ทำให้ปลอดภัย, การใช้ฟังก์ชันต้องห้าม, ข้อมูลรับรองที่ฝังตายตัว และการใช้การเข้ารหัสที่ไม่ปลอดภัย SAST ทำงานใน CI pipeline ทุกครั้งที่มีการคอมมิต จึงตรวจพบปัญหาก่อนจะไปถึง QA หรือระบบจริง เครื่องมือที่ได้รับความนิยม ได้แก่ Semgrep, SonarQube, Checkmarx และ Veracode
# Semgrep SAST rule example:
# Detect raw SQL string concatenation (SQL injection risk):
# rules:
# - id: sql-injection-string-concat
# pattern: |
# $QUERY = '...' + $USER_INPUT
# $DB.execute($QUERY)
# message: 'SQL injection risk: use parameterized queries'
# severity: ERROR
# languages: [python]
# Running Semgrep in CI:
# semgrep --config auto --error src/
# -> Fails build if ERROR severity findings foundDAST: การทดสอบความปลอดภัยของแอปพลิเคชันแบบไดนามิก
DAST (การทดสอบความปลอดภัยของแอปพลิเคชันแบบไดนามิก) ทดสอบแอปพลิเคชันที่กำลังทำงานอยู่ด้วยการส่งข้อมูลโจมตีและสังเกตการตอบสนอง เพื่อจำลองพฤติกรรมของ Attacker ในสถานการณ์จริง ต่างจาก SAST ตรงที่ DAST ตรวจพบช่องโหว่ซึ่งจะปรากฏเฉพาะขณะทำงาน เช่น ข้อบกพร่องด้านการยืนยันตัวตน ปัญหาการจัดการเซสชัน ข้อผิดพลาดทางตรรกะทางธุรกิจ และช่องโหว่จากการแทรกข้อมูลในกระแสข้อมูลที่ซับซ้อน เครื่องมือ DAST ที่ได้รับความนิยม ได้แก่ OWASP ZAP (ฟรี), Burp Suite Enterprise และ Acunetix โดย DAST จะทำงานกับสภาพแวดล้อมสำหรับจัดเตรียมระบบใน pipeline
# OWASP ZAP automated DAST in CI pipeline:
# docker run -t owasp/zap2docker-stable zap-baseline.py \
# -t https://staging.myapp.com \
# -r zap-report.html \
# -I (do not fail on alerts, report only)
# For blocking builds on high findings:
# zap-full-scan.py -t https://staging.myapp.com \
# -l HIGH (fail if HIGH or CRITICAL alerts found)
# ZAP tests for:
# SQL injection, XSS, CSRF, insecure headers,
# path traversal, broken authentication, open redirectsการสแกนอิมเมจคอนเทนเนอร์
อิมเมจคอนเทนเนอร์สร้างจากอิมเมจพื้นฐานที่มีแพ็กเกจของ OS, รันไทม์ของภาษา และส่วนพึ่งพาของแอปพลิเคชัน ซึ่งล้วนเป็นแหล่งที่อาจมีช่องโหว่ที่เป็นที่รู้จัก เครื่องมือ การสแกนอิมเมจคอนเทนเนอร์ จะวิเคราะห์แต่ละเลเยอร์ของอิมเมจและระบุแพ็กเกจที่มีช่องโหว่ Trivy (ฟรีและรวดเร็ว), Grype (Anchore) และ Clair เป็นเครื่องมือที่ใช้กันอย่างแพร่หลาย การสแกนจะทำเป็นส่วนหนึ่งของ pipeline สำหรับสร้างอิมเมจ และจะบล็อกการเลื่อนระดับอิมเมจที่มี CVE ระดับร้ายแรงไปยังรีจิสทรีสำหรับระบบจริง
# Trivy container scan in CI pipeline:
# trivy image --severity HIGH,CRITICAL \
# --exit-code 1 \
# myapp:latest
# Output example:
# library/python:3.9-slim (debian 11.6)
# ===================================
# CVE-2023-1234 CRITICAL openssl 1.1.1n-0+deb11u3 -> 1.1.1t
# CVE-2023-5678 HIGH libssl 1.1.1n -> 1.1.1t
# --exit-code 1 causes pipeline to fail
# on any HIGH or CRITICAL finding -> blocks push to registryการสแกนความปลอดภัยของโครงสร้างพื้นฐานในรูปแบบโค้ด (IaC)
การสแกนความปลอดภัยของ IaC จะวิเคราะห์ Terraform, CloudFormation, ไฟล์กำหนดค่า Kubernetes และชาร์ต Helm เพื่อค้นหาการตั้งค่าที่ไม่ปลอดภัยก่อนนำไปใช้ เครื่องมืออย่าง Checkov และ tfsec จะตรวจสอบการละเมิดต่าง ๆ เช่น Bucket S3 ที่ไม่มีการเข้ารหัสฝั่ง Server, กลุ่มความปลอดภัยที่อนุญาตการรับส่งข้อมูลขาเข้าทั้งหมด บทบาท IAM ที่มีสิทธิ์แบบไวลด์การ์ด และพ็อด Kubernetes ที่ทำงานในสิทธิ์ root การสแกน IaC ช่วยป้องกันการตั้งค่าคลาวด์ที่ไม่ปลอดภัยก่อนจะไปถึงสภาพแวดล้อมใด ๆ
# Checkov IaC scan example:
# checkov -d ./terraform/ --compact
# Findings example:
# FAILED: CKV_AWS_20: S3 Bucket has an ACL defined which allows public access
# File: /terraform/s3.tf, Line: 15
# FAILED: CKV_AWS_57: S3 Bucket has server access logging disabled
# File: /terraform/s3.tf, Line: 15
# FAILED: CKV_AWS_24: Ensure no security groups allow all ingress traffic
# File: /terraform/sg.tf, Line: 8
# Passed checks: 47, Failed: 3, Skipped: 0การสแกนข้อมูลลับใน pipeline
เครื่องมือ การสแกนข้อมูลลับ จะตรวจสอบซอร์สโค้ดและคอมมิตเพื่อค้นหาข้อมูลรับรองที่ถูกใส่ไว้โดยไม่ตั้งใจ เครื่องมืออย่าง truffleHog, GitLeaks และ detect-secrets จะสแกนประวัติ git และคอมมิตใหม่ เพื่อค้นหารูปแบบที่ตรงกับคีย์ API สตริงการเชื่อมต่อ คีย์ส่วนตัว และโทเค็น JWT เมื่อใช้เป็นฮุกก่อนคอมมิต การสแกนข้อมูลลับจะบล็อกคอมมิตที่มีข้อมูลรับรอง เมื่อใช้เป็นด่านตรวจของ CI ระบบจะสแกนไฟล์ทั้งหมดในคลังทุกครั้งที่มีการพุช และทำให้การสร้างล้มเหลวหากตรวจพบข้อมูลลับ
# GitLeaks pre-commit hook configuration:
# .gitleaks.toml:
# [allowlist]
# description = 'Known false positives'
# paths = ['test/fixtures/fake_key.txt']
# Install as pre-commit hook:
# gitleaks protect --staged
# (scans staged files before commit is created)
# In CI pipeline:
# gitleaks detect --source=. --report-format=json \
# --report-path=gitleaks-report.json
# exit code 1 = secrets found -> blocks pipelineการสร้างแบบจำลองภัยคุกคามใน SDLC
การสร้างแบบจำลองภัยคุกคาม คือกระบวนการอย่างเป็นระบบเพื่อระบุข้อกำหนดด้านความปลอดภัยและข้อบกพร่องในการออกแบบก่อนเขียนโค้ด โมเดล STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) ช่วยให้ทีมแจกแจงภัยคุกคามต่อแผนภาพกระแสข้อมูลของระบบได้อย่างเป็นระบบ การประชุมสร้างแบบจำลองภัยคุกคามจะจัดขึ้นระหว่างการออกแบบ และจัดทำรายการภัยคุกคามที่จัดลำดับความสำคัญแล้ว เพื่อนำไปกำหนดข้อกำหนดด้านความปลอดภัยและเลือกกฎสำหรับ SAST/DAST
# STRIDE threat categories applied to a web login API:
# S - Spoofing: Attacker impersonates valid user
# Control: Strong authentication, MFA
# T - Tampering: Attacker modifies login request
# Control: TLS, HMAC, input validation
# R - Repudiation: User denies actions taken
# Control: Audit logging with tamper-evident storage
# I - Info Disclosure: Password exposed in logs
# Control: Never log sensitive fields
# D - Denial of Service: Flood login endpoint
# Control: Rate limiting, CAPTCHA
# E - Elevation of Privilege: Bypass authorization
# Control: Server-side authorization checksด่านตรวจความปลอดภัย: แบบบล็อกกับแบบให้คำแนะนำ
pipeline ของ DevSecOps จะใช้การตรวจสอบความปลอดภัยในรูปแบบใดรูปแบบหนึ่ง ได้แก่ ด่านตรวจแบบบล็อก (ทำให้การสร้างล้มเหลวและป้องกันการนำระบบไปใช้งาน) หรือ การตรวจสอบแบบให้คำแนะนำ (รายงานผลการค้นพบและอนุญาตให้การนำระบบไปใช้งานดำเนินต่อ) โดยทั่วไปผลการค้นพบระดับความรุนแรงสูงและร้ายแรงจาก SAST การสแกนคอนเทนเนอร์ และการตรวจจับข้อมูลลับจะเป็นตัวบล็อก ส่วนผลการค้นพบระดับปานกลางและต่ำจะสร้างการแจ้งเตือนหรืองานติดตามโดยไม่บล็อก วิธีถ่วงดุลนี้ช่วยป้องกันไม่ให้ความปลอดภัยหยุดการส่งมอบทั้งหมด พร้อมทั้งทำให้มั่นใจว่าสภาวะที่เป็นอันตรายอย่างแท้จริงจะไม่ไปถึงระบบจริงโดยอัตโนมัติ
ตัวชี้วัดความปลอดภัยใน DevSecOps
ควรวัดผลโครงการ DevSecOps ด้วยตัวชี้วัดที่ชัดเจน ตัวชี้วัดสำคัญ ได้แก่ เวลาเฉลี่ยในการแก้ไข (MTTR) ของผลการค้นพบที่มีความรุนแรงสูง ความหนาแน่นของช่องโหว่ (จำนวนผลการค้นพบต่อโค้ด 1,000 บรรทัดในช่วงเวลาต่าง ๆ) อัตราการหลุดรอด (เปอร์เซ็นต์ของช่องโหว่ที่พบหลังนำขึ้นระบบจริงเทียบกับก่อนนำขึ้นระบบจริง) และ อัตราการผ่านด่านตรวจความปลอดภัยของ pipeline การติดตามแนวโน้มของตัวชี้วัดเหล่านี้เมื่อเวลาผ่านไปจะแสดงให้เห็นประสิทธิผลของโครงการ และช่วยชี้นำการตัดสินใจลงทุนด้านเครื่องมือหรือการฝึกอบรมเพิ่มเติม
วัฒนธรรม: ความปลอดภัยคือความรับผิดชอบร่วมกัน
ส่วนที่ยากที่สุดของ DevSecOps คือเรื่องวัฒนธรรม ไม่ใช่เรื่องเทคนิค ความปลอดภัยต้องกลายเป็น ความรับผิดชอบของนักพัฒนาทุกคน ไม่ใช่เฉพาะทีมความปลอดภัยเท่านั้น สิ่งนี้ต้องอาศัย การฝึกอบรมด้านความปลอดภัยสำหรับนักพัฒนา (สร้างความตระหนักเรื่องการเขียนโค้ดอย่างปลอดภัย) ตัวแทนด้านความปลอดภัย ที่ทำงานอยู่ภายในทีมพัฒนา การทบทวนหลังเหตุการณ์โดยไม่กล่าวโทษบุคคล เมื่อช่องโหว่ไปถึงระบบจริง (มุ่งปรับปรุงกระบวนการ ไม่ใช่ลงโทษ) และความมุ่งมั่นจากผู้บริหารที่จะยอมแลกความรวดเร็วเมื่อความเสี่ยงด้านความปลอดภัยที่แท้จริงจำเป็นต้องทำเช่นนั้น เทคโนโลยีที่ไม่มีการเปลี่ยนแปลงวัฒนธรรมจะสร้างเพียงเครื่องมือสแกนที่นักพัฒนาเรียนรู้จะเพิกเฉย
ตรวจสอบความเข้าใจ
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า DevSecOps ผสาน SAST, DAST, การสแกนข้อมูลลับ การสแกนคอนเทนเนอร์ และการสแกน IaC ให้เป็นด่านตรวจอัตโนมัติใน pipeline การ บล็อกผลการค้นพบที่มีความรุนแรงสูง ช่วยป้องกันไม่ให้สภาวะอันตรายไปถึงระบบจริง และ การเลื่อนการรักษาความปลอดภัยให้เร็วขึ้นในกระบวนการพัฒนาช่วยลดค่าใช้จ่ายในการแก้ไข ได้อย่างมาก ด้วยการตรวจพบช่องโหว่ระหว่างการพัฒนาแทนที่จะพบหลังการนำไปใช้งาน บทถัดไปเราจะสำรวจมาตรการควบคุมความปลอดภัยทางกายภาพสำหรับสถานที่และศูนย์ข้อมูล
คำถามที่พบบ่อย
บทเรียน “DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์”
ฝังการตรวจสอบความปลอดภัย SAST, DAST, การสแกนคอนเทนเนอร์ และการตรวจสอบความปลอดภัย IaC ไว้ในไปป์ไลน์ CI/CD เพื่อให้ด่านความปลอดภัยถูกบังคับใช้อัตโนมัติทุกครั้งที่ส่งการเปลี่ยนแปลง คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การตรวจสอบข้อมูลนำเข้าและการเข้ารหัสข้อมูลส่งออก
- การจัดการความลับอย่างปลอดภัยและตัวแปรสภาพแวดล้อม
- ความปลอดภัยของการพึ่งพาและการวิเคราะห์องค์ประกอบซอฟต์แวร์
- DevSecOps: ย้ายการรักษาความปลอดภัยไปไว้ตั้งแต่ต้นในไปป์ไลน์