DevSecOps برای توسعه‌دهندگان: راهنمای عملی Shift-Left Security

آسیب‌پذیری‌ای که هنگام نوشتن کد پیدا شود، رفع آن برای توسعه‌دهنده چند دقیقه طول می‌کشد. همان آسیب‌پذیری اگر در production کشف شود، یک sprint کامل هزینه دارد. و اگر یک مهاجم اول آن را پیدا کند، هزینه‌اش میلیون‌ها است. این استدلال اصلی پشت shift-left security است - انتقال بررسی‌های امنیتی به زودترین مرحله ممکن در چرخه عمر توسعه.

DevSecOps این ایده را به یک عمل تبدیل می‌کند: امنیت یک مرحله جداگانه در پایان نیست بلکه فرآیندی مداوم است که در هر مرحله از توسعه تنیده شده، از اولین خط کد تا استقرار production.

هزینه امنیت دیرهنگام

گزارش هزینه نقض داده IBM به طور مداوم نشان داده که هزینه رفع مشکلات امنیتی به صورت نمایی رشد می‌کند هرچه دیرتر کشف شوند:

نتیجه‌گیری واضح است: هر مرحله‌ای که امنیت را زودتر جابجا کنید، یک مرتبه در هزینه و زمان صرفه‌جویی می‌کنید.

خط لوله DevSecOps

یک خط لوله بالغ DevSecOps بررسی‌های امنیتی را در هر مرحله ادغام می‌کند:

بیایید هر مرحله را با ابزارها و پیکربندی‌های مشخص بررسی کنیم.

مرحله 1: امنیت در IDE

سریع‌ترین حلقه بازخورد. آسیب‌پذیری‌ها را قبل از ذخیره فایل کشف کنید.

ابزارهای پیشنهادی

• Semgrep: تحلیل استاتیک سبک با قوانین جامعه برای آسیب‌پذیری‌های OWASP
• Snyk IDE Extension: اسکن آسیب‌پذیری وابستگی‌ها در لحظه
• GitLens + GitLeaks: شناسایی secrets در ویرایشگر شما
• ESLint Security Plugins: eslint-plugin-security برای Node.js، eslint-plugin-no-unsanitized برای DOM XSS

مثال: پیکربندی ESLint Security

{
  "extends": ["eslint:recommended"],
  "plugins": ["security", "no-unsanitized"],
  "rules": {
    "security/detect-object-injection": "warn",
    "security/detect-non-literal-regexp": "warn",
    "security/detect-unsafe-regex": "error",
    "security/detect-buffer-noassert": "error",
    "security/detect-eval-with-expression": "error",
    "security/detect-no-csrf-before-method-override": "error",
    "security/detect-possible-timing-attacks": "warn",
    "no-unsanitized/method": "error",
    "no-unsanitized/property": "error"
  }
}

مرحله 2: Pre-commit Hooks

خط دفاع دوم. به صورت خودکار قبل از هر commit اجرا می‌شود و از ورود کد خطرناک به مخزن جلوگیری می‌کند.

Gitleaks: secrets را قبل از رسیدن به Git شناسایی کنید

رایج‌ترین اشتباه امنیتی در codebases، commit کردن secrets است - API keys، database passwords، tokens. وقتی یک secret وارد git history شود، حذف کامل آن بسیار دشوار است (حتی با force pushes، forks و caches ممکن است آن را نگه دارند).

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.0
    hooks:
      - id: gitleaks

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

نصب و فعال‌سازی:

pip install pre-commit
pre-commit install

حالا هر git commit به صورت خودکار برای secrets فاش شده و آسیب‌پذیری‌های رایج اسکن می‌کند. اگر چیزی پیدا شود، commit مسدود می‌شود.

قوانین سفارشی Gitleaks

می‌توانید الگوهای سفارشی برای secrets سازمان خود اضافه کنید:

# .gitleaks.toml
title = "Custom Gitleaks Config"

[[rules]]
id = "internal-api-key"
description = "Internal API key detected"
regex = '''INTERNAL_KEY_[A-Za-z0-9]{32}'''
tags = ["key", "internal"]

مرحله 3: امنیت CI/CD Pipeline

اینجاست که کار سنگین انجام می‌شود. خط لوله CI شما باید چندین اسکن امنیتی را روی هر pull request اجرا کند.

SAST (Static Application Security Testing)

ابزارهای SAST کد منبع را بدون اجرا تحلیل می‌کنند و به دنبال الگوهایی هستند که نشان‌دهنده آسیب‌پذیری است.

# .github/workflows/security.yml
name: Security Scan
on:
  pull_request:
    branches: [main]

jobs:
  sast:
    name: Static Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/typescript
            p/nodejs
            p/react
          generateSarif: true

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

مجموعه قوانین p/owasp-top-ten در Semgrep رایج‌ترین آسیب‌پذیری‌ها را شناسایی می‌کند: SQL injection، XSS، SSRF، path traversal، insecure deserialization و موارد دیگر.

SCA (Software Composition Analysis)

SCA وابستگی‌های شما را برای آسیب‌پذیری‌های شناخته شده اسکن می‌کند. این بسیار مهم است - بیش از 80% کد برنامه‌های مدرن از وابستگی‌های open-source می‌آید.

  dependency-scan:
    name: Dependency Audit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: npm audit
        run: npm audit --audit-level=high

امنیت کانتینر با Trivy

اگر Docker images می‌سازید، اسکن آنها برای آسیب‌پذیری ضروری است. Trivy محبوب‌ترین اسکنر کانتینر open-source است.

  container-scan:
    name: Container Security
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t my-app:${{ github.sha }} .

      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-app:${{ github.sha }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

      - name: Upload Trivy SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

تولید SBOM

Software Bill of Materials (SBOM) فهرست کاملی از هر مولفه در برنامه شماست. به طور فزاینده‌ای توسط چارچوب‌های انطباق و مقررات دولتی مورد نیاز است (فرمان اجرایی آمریکا درباره امنیت سایبری SBOM را برای نرم‌افزار فدرال الزامی می‌کند).

  sbom:
    name: Generate SBOM
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM with Syft
        uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.spdx.json

مرحله 4: تصاویر امن Docker

یک تصویر Docker برای production باید اصل حداقل دسترسی را رعایت کند. یک Dockerfile تقویت شده به این شکل است:

# Build stage
FROM node:22-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:22-alpine AS runner
WORKDIR /app

# Install dumb-init before dropping root
RUN apk add --no-cache dumb-init

# Don't run as root
RUN addgroup -S app && adduser -S app -G app

# Copy only what's needed
COPY --from=builder --chown=app:app /app/dist ./dist
COPY --from=builder --chown=app:app /app/node_modules ./node_modules
COPY --from=builder --chown=app:app /app/package.json ./

# Drop to non-root user
USER app
ENTRYPOINT ["dumb-init", "--"]

# Health check
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

EXPOSE 3000
CMD ["node", "dist/server.js"]

شیوه‌های کلیدی:

1. از multi-stage builds استفاده کنید: مرحله builder شامل dev dependencies است؛ مرحله runner فقط کد production دارد
2. به عنوان root اجرا نکنید: یک کاربر غیر root بسازید و به آن تغییر دهید
3. از تصاویر Alpine استفاده کنید: سطح حمله کوچکتر (بسته‌های کمتر به طور پیش‌فرض نصب شده)
4. نسخه تصاویر را ثابت کنید: node:22-alpine به جای node:latest برای جلوگیری از حملات زنجیره تامین
5. از npm ci استفاده کنید: نصب‌های قطعی از فایل قفل، نه npm install

مرحله 5: مدیریت Secrets

Secrets نوشته شده در کد علت شماره یک نقض‌ها در حوادث ناشی از توسعه‌دهندگان هستند.

آنچه نباید انجام دهید

// NEVER do this
const API_KEY = "sk-1234567890abcdef";
const DB_PASSWORD = "supersecret123";

const client = new Client({
  connectionString: `postgres://admin:${DB_PASSWORD}@db.example.com/prod`
});

آنچه باید به جای آن انجام دهید

// Use environment variables
const client = new Client({
  connectionString: process.env.DATABASE_URL
});

// Or use a secret manager
import { SecretManagerServiceClient } from '@google-cloud/secret-manager';

const client = new SecretManagerServiceClient();
const [version] = await client.accessSecretVersion({
  name: 'projects/my-project/secrets/db-password/versions/latest',
});
const dbPassword = version.payload?.data?.toString();

سلسله مراتب مدیریت Secrets

OWASP Top 10: مرجع سریع

هر توسعه‌دهنده‌ای باید OWASP Top 10 را بداند. نسخه خلاصه:

جریان کار کامل GitHub Actions Security

یک جریان کار کامل و آماده production که همه موارد بالا را ترکیب می‌کند:

# .github/workflows/security.yml
name: Security Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write

jobs:
  secrets-scan:
    name: Secret Detection
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  sast:
    name: Static Analysis (SAST)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/owasp-top-ten p/typescript p/nodejs

  dependency-audit:
    name: Dependency Scan (SCA)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm audit --audit-level=high
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high
        continue-on-error: true

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

  sbom:
    name: SBOM Generation
    runs-on: ubuntu-latest
    needs: [container-scan]
    steps:
      - uses: actions/checkout@v4
      - uses: anchore/sbom-action@v0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

معیارهایی برای پیگیری

چگونه بفهمید برنامه DevSecOps شما کار می‌کند؟ این معیارها را پیگیری کنید:

• Mean time to remediate (MTTR): چقدر سریع آسیب‌پذیری‌ها را پس از شناسایی رفع می‌کنید
• Vulnerability escape rate: درصد آسیب‌پذیری‌هایی که به production می‌رسند
• False positive rate: مثبت‌های کاذب بیش از حد منجر به خستگی هشدار و نادیده گرفتن هشدارها می‌شود
• Dependency freshness: میانگین سن وابستگی‌های شما (قدیمی‌تر = احتمال بیشتر CVEهای شناخته شده)
• SBOM coverage: درصد پروژه‌ها با SBOMهای به‌روز

شروع کار: یک نقشه راه عملی

سعی نکنید همه چیز را یکجا پیاده‌سازی کنید. رویکرد مرحله‌ای بهتر عمل می‌کند:

نتیجه‌گیری

DevSecOps درباره اضافه کردن ابزارهای بیشتر به خط لوله نیست - درباره تبدیل امنیت به بخشی طبیعی از نحوه ساخت نرم‌افزار است. هدف مسدود کردن هر PR با هشدارهای امنیتی نیست بلکه دادن بازخورد سریع به توسعه‌دهندگان است تا بتوانند مشکلات را زمانی رفع کنند که کد هنوز در ذهنشان تازه است.

با اصول شروع کنید: pre-commit hooks برای secrets، dependency scanning در CI، و container scanning برای Docker images. سپس بر اساس نیازهای تیم خود تکرار کنید.

امنیت یک ویژگی نیست که یک بار ارسال می‌کنید. یک عمل است که در هر commit می‌سازید.

DevSecOps Starter Checklist:

• Gitleaks pre-commit hooks نصب شده
• فایل‌های .env و secret در .gitignore
• Semgrep SAST در CI pipeline
• Snyk یا npm audit برای اسکن وابستگی‌ها
• Trivy برای اسکن تصاویر کانتینر
• کاربر غیر root در Dockerfiles
• Secrets در environment variables یا secret manager
• تولید SBOM در هر انتشار
• آگاهی OWASP Top 10 در سراسر تیم