DevSecOps คืออะไร? สอนทำ Security ใน CI/CD Pipeline สำหรับ DevOps Engineer 2026

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

บทความนี้จะพาคุณเข้าใจ DevSecOps อย่างลึกซึ้ง ตั้งแต่แนวคิดพื้นฐาน ไปจนถึงการนำไปใช้จริงใน CI/CD Pipeline ครอบคลุมเครื่องมือ SAST, DAST, SCA, Container Security, Secrets Management และอีกมากมาย พร้อมตัวอย่าง Configuration ที่ใช้ได้จริงทันที

DevSecOps คืออะไร?

DevSecOps คือการรวมเอา Security (Sec) เข้าไปในกระบวนการ DevOps (Development + Operations) ทำให้เกิดเป็น Development + Security + Operations ที่ทำงานร่วมกันอย่างไร้รอยต่อ แนวคิดหลักคือ "Security is everyone's responsibility" ไม่ใช่แค่เรื่องของทีม Security เพียงทีมเดียว

ในอดีต Security มักถูกทำในขั้นตอนสุดท้ายก่อน Deploy ซึ่งเรียกว่า "Security as a Gate" หรือ "Security at the End" ทำให้เกิดปัญหาหลายอย่าง เช่น ค้นพบ Bug ด้านความปลอดภัยช้าเกินไป แก้ไขยาก ต้นทุนสูง และทำให้ Release ล่าช้า DevSecOps แก้ปัญหานี้โดยการ "Shift Left" คือเลื่อน Security มาทำตั้งแต่ขั้นตอนแรกของการพัฒนา

DevOps vs DevSecOps

Shift-Left Security คืออะไร?

Shift-Left คือแนวคิดการเลื่อนกิจกรรมด้าน Security มาทำในช่วงต้นของ Software Development Lifecycle (SDLC) แทนที่จะรอทำตอนท้าย คำว่า "Left" มาจากการมองแผนภาพ SDLC จากซ้ายไปขวา (Plan → Code → Build → Test → Deploy → Monitor) การ Shift Left คือการนำ Security มาใส่ตั้งแต่ขั้นตอน Plan และ Code

ทำไม Shift-Left ถึงสำคัญ? จากงานวิจัยของ IBM พบว่า ต้นทุนการแก้ไข Bug ที่พบในขั้นตอน Production สูงกว่า Bug ที่พบในขั้นตอน Design ถึง 100 เท่า ดังนั้นยิ่งพบปัญหาเร็วเท่าไหร่ ต้นทุนในการแก้ไขก็ยิ่งต่ำลง

หลักการของ Shift-Left Security ประกอบด้วย การให้ความรู้ด้าน Secure Coding แก่นักพัฒนาทุกคน การใช้เครื่องมือ Automated Security Testing ตั้งแต่ขั้นตอน Coding เช่น IDE Plugin ที่ตรวจจับ Vulnerability ขณะเขียน Code การทำ Threat Modeling ตั้งแต่ขั้นตอนออกแบบ (Design Phase) การเขียน Security Requirements ควบคู่ไปกับ Functional Requirements และการทำ Code Review ที่ให้ความสำคัญกับ Security ด้วย

Security ในแต่ละขั้นตอนของ CI/CD Pipeline

CI/CD Pipeline ที่มี Security จะมีการตรวจสอบความปลอดภัยในทุกขั้นตอน ตั้งแต่ Code Commit จนถึง Production Deployment มาดูรายละเอียดแต่ละขั้นตอนกัน

ขั้นตอนที่ 1: Pre-Commit (ก่อน Commit Code)

ก่อนที่ Code จะถูก Commit เข้า Repository เราสามารถตรวจสอบเบื้องต้นได้ด้วย Git Hooks โดยใช้เครื่องมืออย่าง pre-commit framework

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: detect-private-key
      - id: check-added-large-files
      - id: no-commit-to-branch
        args: ['--branch', 'main']

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

  - repo: https://github.com/returntocorp/semgrep
    rev: v1.50.0
    hooks:
      - id: semgrep
        args: ['--config', 'auto']

ขั้นตอนนี้จะตรวจจับ Secrets (API Keys, Passwords) ที่อาจหลุดเข้าไปใน Code, ตรวจสอบไฟล์ขนาดใหญ่ที่ไม่ควรอยู่ใน Repository และทำ Basic Security Scanning ด้วย Semgrep

ขั้นตอนที่ 2: Static Application Security Testing (SAST)

SAST คือการวิเคราะห์ Source Code โดยไม่ต้อง Run Application เพื่อหา Vulnerability ต่างๆ เช่น SQL Injection, Cross-Site Scripting (XSS), Buffer Overflow และอื่นๆ ทำในขั้นตอน Build ของ CI/CD Pipeline

ขั้นตอนที่ 3: Software Composition Analysis (SCA)

SCA คือการตรวจสอบ Third-party Dependencies (Libraries, Packages) ที่โปรเจกต์ใช้ว่ามี Vulnerability ที่รู้จักแล้ว (Known Vulnerabilities) หรือไม่ เนื่องจากแอปพลิเคชันสมัยใหม่ใช้ Open Source Dependencies จำนวนมาก SCA จึงเป็นขั้นตอนที่สำคัญมาก

ขั้นตอนที่ 4: Container Security Scanning

ถ้าแอปพลิเคชันใช้ Docker Container จะต้องตรวจสอบ Container Image ว่าปลอดภัยหรือไม่ เช่น Base Image มี Vulnerability หรือเปล่า, มี Misconfiguration หรือไม่ และ Container รันด้วย Root User หรือเปล่า

ขั้นตอนที่ 5: Dynamic Application Security Testing (DAST)

DAST คือการทดสอบความปลอดภัยโดยการ Run Application จริงแล้วส่ง Request โจมตีเข้าไป เหมือนการทำ Penetration Testing แบบ Automated ทำในขั้นตอน Testing หลังจาก Deploy ไปยัง Staging Environment

ขั้นตอนที่ 6: Infrastructure Security

ตรวจสอบ Infrastructure as Code (IaC) เช่น Terraform, CloudFormation ว่ามี Misconfiguration ที่อาจเป็น Security Risk หรือไม่

SAST Tools: เครื่องมือวิเคราะห์ Source Code

SonarQube

SonarQube เป็นเครื่องมือ Code Quality และ Security Analysis ที่ได้รับความนิยมมากที่สุด รองรับหลายภาษา เช่น Java, Python, JavaScript, TypeScript, Go, C/C++ และอื่นๆ มีทั้งแบบ Open Source (Community Edition) และ Commercial

# ติดตั้ง SonarQube ด้วย Docker
docker run -d --name sonarqube \
  -p 9000:9000 \
  -v sonarqube_data:/opt/sonarqube/data \
  sonarqube:community

# sonar-project.properties
sonar.projectKey=my-project
sonar.projectName=My Project
sonar.sources=src
sonar.language=java
sonar.sourceEncoding=UTF-8
sonar.java.binaries=target/classes

# รัน Scanner
sonar-scanner \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=your-token

SonarQube สามารถตรวจจับปัญหาด้าน Security ได้หลายประเภท เช่น SQL Injection, XSS, Path Traversal, Hardcoded Credentials, Insecure Deserialization และอื่นๆ นอกจากนี้ยังสามารถตั้ง Quality Gate ที่กำหนดเกณฑ์คุณภาพ เช่น ไม่มี Critical Vulnerability, Code Coverage ต้องมากกว่า 80 เปอร์เซ็นต์ เป็นต้น

Semgrep

Semgrep เป็นเครื่องมือ SAST ที่เน้นความเร็วและง่ายต่อการเขียน Custom Rules ใช้ Pattern-based Approach ในการค้นหา Vulnerability รองรับภาษามากกว่า 30 ภาษา

# ติดตั้ง Semgrep
pip install semgrep

# รันด้วย Default Rules
semgrep --config auto .

# รันด้วย OWASP Top 10 Rules
semgrep --config "p/owasp-top-ten" .

# รันเฉพาะ Security Rules
semgrep --config "p/security-audit" .

# Custom Rule Example (semgrep-rules.yml)
rules:
  - id: hardcoded-password
    patterns:
      - pattern: |
          password = "..."
    message: "Hardcoded password detected"
    languages: [python]
    severity: ERROR

# รัน Custom Rules
semgrep --config semgrep-rules.yml .

CodeQL (GitHub)

CodeQL เป็นเครื่องมือ SAST ของ GitHub ที่ใช้ Query Language เฉพาะทางในการวิเคราะห์ Code ทำงานร่วมกับ GitHub Actions ได้อย่างราบรื่น และฟรีสำหรับ Public Repository

# .github/workflows/codeql.yml
name: CodeQL Analysis
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # ทุกวันจันทร์ 6:00

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: read
      security-events: write

    strategy:
      matrix:
        language: ['javascript', 'python']

    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: +security-and-quality

      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3
        with:
          category: "/language:${{ matrix.language }}"

เปรียบเทียบ SAST Tools

DAST Tools: ทดสอบ Application ขณะรัน

OWASP ZAP (Zed Attack Proxy)

OWASP ZAP เป็นเครื่องมือ DAST แบบ Open Source ที่ได้รับความนิยมมากที่สุด พัฒนาโดย OWASP Foundation สามารถทำ Active Scan (โจมตีจริง) และ Passive Scan (แค่สังเกต Traffic) ได้ และยังรองรับ API Scanning ด้วย

# รัน OWASP ZAP ด้วย Docker (Baseline Scan)
docker run -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t https://staging.example.com \
  -r zap-report.html

# Full Scan (ใช้เวลานานกว่า)
docker run -t ghcr.io/zaproxy/zaproxy:stable \
  zap-full-scan.py \
  -t https://staging.example.com \
  -r zap-full-report.html

# API Scan (สำหรับ REST API)
docker run -t ghcr.io/zaproxy/zaproxy:stable \
  zap-api-scan.py \
  -t https://staging.example.com/api/openapi.json \
  -f openapi \
  -r zap-api-report.html

# ใช้ใน GitHub Actions
# .github/workflows/dast.yml
name: DAST Scan
on:
  push:
    branches: [main]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Staging
        run: docker compose up -d
      - name: OWASP ZAP Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: 'http://localhost:8080'
          rules_file_name: '.zap-rules.tsv'

ZAP สามารถตรวจจับปัญหาด้าน Security หลายประเภท เช่น Cross-Site Scripting (XSS), SQL Injection, Server-Side Request Forgery (SSRF), Directory Traversal, Information Disclosure, Missing Security Headers, Insecure Cookie Settings และอื่นๆ อีกมาก

Burp Suite

Burp Suite เป็นเครื่องมือ DAST ระดับ Professional ที่นิยมใช้ในวงการ Penetration Testing มี Extension มากมาย และสามารถทำ Manual Testing ได้ดีเยี่ยม มี Community Edition (ฟรี) และ Professional Edition (จ่ายเงิน) Burp Suite Professional สามารถใช้ใน CI/CD ได้ผ่าน Burp Suite Enterprise Edition ที่รองรับ REST API สำหรับ Automated Scanning

SCA & Dependency Scanning: ตรวจสอบ Dependencies

Snyk

Snyk เป็นเครื่องมือ SCA ที่ได้รับความนิยมมากที่สุด รองรับหลาย Ecosystem เช่น npm, pip, Maven, Go modules, Docker images และ IaC

# ติดตั้ง Snyk CLI
npm install -g snyk

# Authenticate
snyk auth

# ตรวจสอบ Dependencies
snyk test

# ตรวจสอบ + แก้ไขอัตโนมัติ
snyk fix

# Monitor (ส่ง Alert เมื่อมี Vulnerability ใหม่)
snyk monitor

# ตรวจสอบ Docker Image
snyk container test my-app:latest

# ตรวจสอบ IaC (Terraform/CloudFormation)
snyk iac test terraform/

# ใช้ใน GitHub Actions
name: Snyk Security
on: push
jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

Dependabot (GitHub)

Dependabot เป็นเครื่องมือของ GitHub ที่ตรวจสอบ Dependencies แล้วสร้าง Pull Request อัปเดต Dependency ที่มี Vulnerability อัตโนมัติ ใช้งานง่ายมากแค่สร้างไฟล์ Configuration

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    open-pull-requests-limit: 10
    reviewers:
      - "security-team"
    labels:
      - "dependencies"
      - "security"

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    allow:
      - dependency-type: "direct"

Trivy

Trivy เป็นเครื่องมือ Scanner แบบ All-in-One ของ Aqua Security สามารถ Scan ได้ทั้ง Container Images, Filesystem, Git Repository, Kubernetes, IaC และ SBOM เป็น Open Source และใช้งานง่ายมาก

# ติดตั้ง Trivy
# Linux
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

# Scan Container Image
trivy image my-app:latest

# Scan เฉพาะ Critical & High
trivy image --severity CRITICAL,HIGH my-app:latest

# Scan Filesystem (Project Dependencies)
trivy fs --security-checks vuln,secret,config .

# Scan IaC (Terraform, CloudFormation, Kubernetes)
trivy config ./terraform/

# Scan ใน CI/CD (GitHub Actions)
name: Trivy Scan
on: push
jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Image
        run: docker build -t my-app:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'my-app:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

Container Security: รักษาความปลอดภัย Docker

Container Security เป็นส่วนสำคัญของ DevSecOps เนื่องจากแอปพลิเคชันสมัยใหม่ส่วนใหญ่รันบน Container การรักษาความปลอดภัยของ Container ต้องทำทั้งตอน Build Time (Scan Image), Runtime (Monitor Container) และ Registry (Scan Image ก่อน Pull มาใช้)

Best Practices สำหรับ Dockerfile ที่ปลอดภัย

# Dockerfile ที่ปลอดภัย
# 1. ใช้ Specific Version Tag (ไม่ใช้ latest)
FROM node:20.11-alpine3.19

# 2. ใช้ Non-root User
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# 3. Copy เฉพาะไฟล์ที่จำเป็น
COPY package*.json ./
RUN npm ci --only=production

COPY --chown=appuser:appgroup src/ ./src/

# 4. ลบ Cache และ Temp files
RUN rm -rf /var/cache/apk/* /tmp/*

# 5. ใช้ Read-only Filesystem
USER appuser

# 6. ไม่ Expose Port ที่ไม่จำเป็น
EXPOSE 3000

# 7. Health Check
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget --spider -q http://localhost:3000/health || exit 1

# 8. ใช้ Multi-stage Build
FROM node:20.11-alpine3.19 AS builder
WORKDIR /build
COPY . .
RUN npm ci && npm run build

FROM node:20.11-alpine3.19
WORKDIR /app
COPY --from=builder /build/dist ./dist
COPY --from=builder /build/node_modules ./node_modules
USER appuser
CMD ["node", "dist/server.js"]

Docker Bench Security

# รัน Docker Bench Security
docker run --rm --net host --pid host \
  --userns host --cap-add audit_control \
  -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
  -v /etc:/etc:ro \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  docker/docker-bench-security

Docker Bench Security จะตรวจสอบ Configuration ของ Docker Host และ Container ตาม CIS Docker Benchmark แล้วให้คะแนนพร้อมคำแนะนำในการแก้ไข ครอบคลุมเรื่อง Host Configuration, Docker Daemon Configuration, Container Images, Container Runtime, Docker Security Operations และ Docker Swarm Configuration

Secrets Management: จัดการ Secrets อย่างปลอดภัย

Secrets เช่น API Keys, Database Passwords, Certificates ต้องไม่เก็บใน Source Code หรือ Environment Variables แบบ Plain Text ต้องใช้ Secrets Management Tool ที่เข้ารหัสและควบคุมการเข้าถึง

HashiCorp Vault

HashiCorp Vault เป็นเครื่องมือ Secrets Management ที่ได้รับความนิยมมากที่สุด รองรับ Dynamic Secrets (สร้าง Secret แบบชั่วคราว), Encryption as a Service, Key Management และ Identity-based Access

# ติดตั้ง Vault (Dev Mode)
vault server -dev

# เขียน Secret
vault kv put secret/myapp/config \
  db_host=db.example.com \
  db_user=admin \
  db_pass=super-secret-password

# อ่าน Secret
vault kv get secret/myapp/config
vault kv get -field=db_pass secret/myapp/config

# ใช้ใน Application (Python)
import hvac

client = hvac.Client(url='http://vault:8200', token='s.xxxx')
secret = client.secrets.kv.v2.read_secret_version(
    path='myapp/config'
)
db_password = secret['data']['data']['db_pass']

# Dynamic Database Credentials
vault secrets enable database

vault write database/config/mydb \
  plugin_name=mysql-database-plugin \
  connection_url="{{username}}:{{password}}@tcp(db:3306)/" \
  allowed_roles="readonly" \
  username="vault" \
  password="vault-pass"

vault write database/roles/readonly \
  db_name=mydb \
  creation_statements="CREATE USER '{{name}}'@'%' \
    IDENTIFIED BY '{{password}}'; \
    GRANT SELECT ON *.* TO '{{name}}'@'%';" \
  default_ttl="1h" \
  max_ttl="24h"

# ขอ Credential ชั่วคราว
vault read database/creds/readonly

AWS Secrets Manager

# สร้าง Secret
aws secretsmanager create-secret \
  --name myapp/database \
  --secret-string '{"username":"admin","password":"secret123"}'

# อ่าน Secret
aws secretsmanager get-secret-value \
  --secret-id myapp/database

# ใช้ใน Application (Python boto3)
import boto3, json

client = boto3.client('secretsmanager', region_name='ap-southeast-1')
response = client.get_secret_value(SecretId='myapp/database')
secret = json.loads(response['SecretString'])
db_password = secret['password']

# Automatic Rotation
aws secretsmanager rotate-secret \
  --secret-id myapp/database \
  --rotation-lambda-arn arn:aws:lambda:...:function:rotate-secret \
  --rotation-rules AutomaticallyAfterDays=30

GitHub Actions Secrets

# ใช้ Secrets ใน GitHub Actions
name: Deploy
on: push
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
          API_KEY: ${{ secrets.API_KEY }}
        run: |
          echo "Deploying with secure credentials"
          ./deploy.sh

Infrastructure Security: IaC Scanning

Infrastructure as Code (IaC) เช่น Terraform, CloudFormation, Kubernetes Manifests ต้องถูกตรวจสอบด้านความปลอดภัยเช่นกัน เพราะ Misconfiguration ใน Infrastructure สามารถเปิดช่องโหว่ร้ายแรงได้ เช่น S3 Bucket เปิด Public, Security Group เปิด Port ทั้งหมด, IAM Policy ให้สิทธิ์มากเกินไป เป็นต้น

Checkov

Checkov เป็นเครื่องมือ IaC Scanner ของ Bridgecrew (Palo Alto Networks) รองรับ Terraform, CloudFormation, Kubernetes, Helm, ARM Templates, Serverless Framework และอื่นๆ

# ติดตั้ง Checkov
pip install checkov

# Scan Terraform
checkov -d ./terraform/

# Scan Kubernetes Manifests
checkov -d ./k8s/

# Scan Dockerfile
checkov --framework dockerfile -f Dockerfile

# Scan เฉพาะ Specific Checks
checkov -d ./terraform/ --check CKV_AWS_18,CKV_AWS_19

# Skip Specific Checks
checkov -d ./terraform/ --skip-check CKV_AWS_18

# Output เป็น JUnit XML (สำหรับ CI/CD)
checkov -d ./terraform/ -o junitxml > checkov-results.xml

# ใช้ใน GitHub Actions
name: IaC Security
on: push
jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          soft_fail: true

tfsec

tfsec (ตอนนี้ถูกรวมเข้ากับ Trivy แล้ว) เป็นเครื่องมือ Terraform Security Scanner ที่เร็วและง่ายต่อการใช้งาน สามารถตรวจจับ Misconfiguration ใน Terraform ได้หลากหลาย

# ติดตั้ง tfsec
brew install tfsec  # macOS
choco install tfsec  # Windows

# Scan Terraform Directory
tfsec ./terraform/

# Scan พร้อมแสดงระดับความรุนแรง
tfsec ./terraform/ --minimum-severity HIGH

# Output เป็น SARIF
tfsec ./terraform/ -f sarif > tfsec-results.sarif

SBOM: Software Bill of Materials

SBOM (Software Bill of Materials) คือเอกสารที่ระบุ Component ทั้งหมดที่ใช้ในซอฟต์แวร์ เปรียบเหมือน "รายการส่วนผสม" ของอาหาร ช่วยให้รู้ว่าซอฟต์แวร์ประกอบด้วยอะไรบ้าง ทำให้สามารถติดตาม Vulnerability ได้เมื่อมีการค้นพบ Vulnerability ใหม่ใน Component ที่ใช้

ในปี 2026 รัฐบาลสหรัฐอเมริกาและสหภาพยุโรปกำหนดให้ซอฟต์แวร์ที่ขายให้หน่วยงานรัฐต้องมี SBOM ด้วย ทำให้ SBOM กลายเป็นมาตรฐานที่ทุกองค์กรควรทำ

# สร้าง SBOM ด้วย Syft (Anchore)
# ติดตั้ง Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# สร้าง SBOM จาก Container Image
syft my-app:latest -o spdx-json > sbom.spdx.json

# สร้าง SBOM จาก Directory
syft dir:./my-project -o cyclonedx-json > sbom.cdx.json

# Scan SBOM หา Vulnerability ด้วย Grype
grype sbom:./sbom.spdx.json

# ใช้ใน CI/CD (GitHub Actions)
name: SBOM
on: push
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anchore/sbom-action@v0
        with:
          image: my-app:${{ github.sha }}
          format: spdx-json
          output-file: sbom.spdx.json
      - uses: anchore/scan-action@v4
        with:
          sbom: sbom.spdx.json
          fail-build: true
          severity-cutoff: high

Compliance as Code

Compliance as Code คือการเปลี่ยน Compliance Requirements (เช่น PCI DSS, SOC 2, HIPAA, ISO 27001) จากเอกสาร Manual มาเป็น Code ที่สามารถทำ Automated Testing ได้ ทำให้การตรวจสอบ Compliance เป็นเรื่องต่อเนื่อง ไม่ใช่แค่ทำปีละครั้งตอน Audit

# ใช้ Open Policy Agent (OPA) สำหรับ Policy as Code
# policy.rego
package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Deployment"
  not input.request.object.spec.template.spec.securityContext.runAsNonRoot
  msg := "Containers must not run as root"
}

deny[msg] {
  input.request.kind.kind == "Deployment"
  container := input.request.object.spec.template.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("Container %v must have memory limits", [container.name])
}

# ทดสอบ Policy
opa eval --data policy.rego --input deployment.json "data.kubernetes.admission.deny"

# ใช้ Kyverno สำหรับ Kubernetes Policy
# kyverno-policy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
  - name: require-team-label
    match:
      any:
      - resources:
          kinds:
          - Deployment
          - StatefulSet
    validate:
      message: "Label 'team' is required"
      pattern:
        metadata:
          labels:
            team: "?*"

Security Gates ใน Pipeline

Security Gate คือจุดตรวจสอบใน CI/CD Pipeline ที่จะหยุด Pipeline ถ้าไม่ผ่านเกณฑ์ด้าน Security ที่กำหนดไว้ ช่วยป้องกันไม่ให้ Code ที่มี Vulnerability ร้ายแรงถูก Deploy ไปยัง Production

# ตัวอย่าง Complete Security Pipeline (GitHub Actions)
name: Security Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  # Gate 1: Secret Detection
  secrets-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

  # Gate 2: SAST
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/security-audit

  # Gate 3: SCA
  dependency-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

  # Gate 4: Container Scan
  container-scan:
    runs-on: ubuntu-latest
    needs: [sast, dependency-check]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t my-app:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'my-app:${{ github.sha }}'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

  # Gate 5: IaC Scan
  iac-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/

  # Final: Deploy (ต้องผ่านทุก Gate)
  deploy:
    runs-on: ubuntu-latest
    needs: [secrets-scan, sast, dependency-check, container-scan, iac-scan]
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: echo "Deploying to production..."

Threat Modeling

Threat Modeling คือกระบวนการระบุ วิเคราะห์ และจัดลำดับความสำคัญของภัยคุกคามที่อาจเกิดขึ้นกับระบบ ควรทำตั้งแต่ขั้นตอนออกแบบ (Design Phase) เพื่อให้สามารถป้องกันปัญหาได้ก่อนที่จะเขียน Code

วิธีการทำ Threat Modeling ที่นิยมใช้คือ STRIDE ซึ่งย่อมาจาก Spoofing (การปลอมตัว), Tampering (การแก้ไขข้อมูล), Repudiation (การปฏิเสธการกระทำ), Information Disclosure (การเปิดเผยข้อมูล), Denial of Service (การทำให้ระบบใช้งานไม่ได้), Elevation of Privilege (การยกระดับสิทธิ์)

ขั้นตอนการทำ Threat Modeling มีดังนี้ ขั้นตอนแรกคือการวาด Architecture Diagram แสดง Component ต่างๆ และ Data Flow ระหว่างกัน ขั้นตอนที่สองคือการระบุ Trust Boundaries (ขอบเขตความไว้วางใจ) เช่น ระหว่าง Internet กับ Application, ระหว่าง Application กับ Database ขั้นตอนที่สามคือการใช้ STRIDE Model ระบุภัยคุกคามแต่ละจุด ขั้นตอนที่สี่คือการจัดลำดับความสำคัญโดยใช้ Risk Assessment (Likelihood x Impact) ขั้นตอนสุดท้ายคือการกำหนดมาตรการป้องกัน (Mitigation) สำหรับแต่ละภัยคุกคาม

เครื่องมือที่ช่วยทำ Threat Modeling เช่น Microsoft Threat Modeling Tool (ฟรี), OWASP Threat Dragon (Open Source), IriusRisk (Commercial), Threagile (Open Source, Code-based) เป็นต้น

Security Champions Program

Security Champions Program คือโปรแกรมที่คัดเลือกนักพัฒนาจากแต่ละทีม (1-2 คนต่อทีม) มาเป็น "Security Champion" ทำหน้าที่เป็นตัวแทนด้าน Security ของทีม ช่วยสร้าง Security Culture ในองค์กรโดยไม่ต้องจ้างทีม Security จำนวนมาก

หน้าที่ของ Security Champion ประกอบด้วย Review Code ด้าน Security ให้ทีมตัวเอง แชร์ความรู้ด้าน Security ให้เพื่อนร่วมทีม ช่วยทีม Security กำหนด Security Requirements เข้าร่วม Security Training และนำความรู้กลับมาสอนทีม ช่วย Triage Security Vulnerabilities ที่พบจาก Scanning Tools รายงาน Security Metrics ให้ผู้บริหาร และทำ Threat Modeling ร่วมกับทีม

การเริ่มต้น Security Champions Program ที่ดีควรเริ่มจากการหาอาสาสมัคร (ไม่ใช่บังคับ) จากแต่ละทีม จัดฝึกอบรมเฉพาะทาง (OWASP Top 10, Secure Coding, Threat Modeling) กำหนดเวลาสำหรับงาน Security ประมาณ 10-20 เปอร์เซ็นต์ของเวลาทำงาน สร้าง Community ให้ Champions แลกเปลี่ยนความรู้กัน และให้ Recognition (รางวัลหรือการยกย่อง) แก่ Champions ที่ทำผลงานดี

DevSecOps Maturity Model

DevSecOps Maturity Model ช่วยให้องค์กรประเมินระดับความพร้อมด้าน DevSecOps และวางแผนพัฒนาได้อย่างเป็นขั้นตอน

เปรียบเทียบเครื่องมือ DevSecOps ทั้งหมด

ตัวอย่าง Complete DevSecOps Pipeline

นี่คือตัวอย่าง Pipeline ที่สมบูรณ์สำหรับโปรเจกต์จริง รวมทุกขั้นตอน Security ตั้งแต่ต้นจนจบ

# .github/workflows/devsecops-pipeline.yml
name: DevSecOps Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  IMAGE_NAME: my-app
  REGISTRY: ghcr.io

jobs:
  # Stage 1: Pre-build Security Checks
  pre-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      # Secret Detection
      - name: Detect Secrets
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

      # License Compliance
      - name: Check Licenses
        run: |
          pip install pip-licenses
          pip-licenses --format=json --with-urls > licenses.json

  # Stage 2: SAST + SCA
  code-analysis:
    runs-on: ubuntu-latest
    needs: pre-build
    steps:
      - uses: actions/checkout@v4

      # SAST with Semgrep
      - name: SAST Scan
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten p/security-audit

      # SCA with Snyk
      - name: Dependency Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

  # Stage 3: Build + Container Scan
  build-and-scan:
    runs-on: ubuntu-latest
    needs: code-analysis
    steps:
      - uses: actions/checkout@v4

      - name: Build Image
        run: docker build -t $IMAGE_NAME:${{ github.sha }} .

      # Container Vulnerability Scan
      - name: Trivy Scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: '${{ env.IMAGE_NAME }}:${{ github.sha }}'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      # Generate SBOM
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ${{ env.IMAGE_NAME }}:${{ github.sha }}
          format: spdx-json

  # Stage 4: IaC Scan
  iac-security:
    runs-on: ubuntu-latest
    needs: pre-build
    steps:
      - uses: actions/checkout@v4
      - name: Checkov Scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          soft_fail: false

  # Stage 5: Deploy to Staging + DAST
  staging-dast:
    runs-on: ubuntu-latest
    needs: [build-and-scan, iac-security]
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Staging
        run: echo "Deploy to staging..."

      - name: DAST Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: 'https://staging.example.com'

  # Stage 6: Deploy to Production
  production:
    runs-on: ubuntu-latest
    needs: staging-dast
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - name: Deploy to Production
        run: echo "Deploying to production..."

      - name: Notify Security Team
        run: echo "Notify security team of deployment"

สรุป

DevSecOps ไม่ใช่แค่การเพิ่มเครื่องมือ Security เข้าไปใน Pipeline แต่เป็นการเปลี่ยนแปลงวัฒนธรรม (Culture Shift) ที่ทำให้ Security เป็นความรับผิดชอบของทุกคนในทีม การเริ่มต้นไม่จำเป็นต้องทำทุกอย่างพร้อมกัน สามารถเริ่มจากสิ่งง่ายๆ เช่น Secret Detection และ Dependency Scanning ก่อน แล้วค่อยๆ เพิ่ม SAST, DAST, Container Scanning และอื่นๆ ตามลำดับ

สิ่งที่สำคัญที่สุดคือการเริ่มต้นวันนี้ อย่ารอจนกว่าจะสมบูรณ์แบบ เพราะ Security ที่ไม่สมบูรณ์ยังดีกว่าไม่มี Security เลย จำไว้ว่า Security is a journey not a destination ใช้ Maturity Model เป็นแนวทาง แล้วค่อยๆ พัฒนาไปทีละขั้น องค์กรของคุณจะปลอดภัยมากขึ้นอย่างยั่งยืน