1~
2آسیب‌پذیری‌ای که هنگام نوشتن کد پیدا شود، رفع آن برای توسعه‌دهنده چند دقیقه طول می‌کشد. همان آسیب‌پذیری اگر در production کشف شود، یک sprint کامل هزینه دارد. و اگر یک مهاجم اول آن را پیدا کند، هزینه‌اش میلیون‌ها است. این استدلال اصلی پشت **shift-left security** است  -  انتقال بررسی‌های امنیتی به زودترین مرحله ممکن در چرخه عمر توسعه.
3~
4DevSecOps این ایده را به یک عمل تبدیل می‌کند: امنیت یک مرحله جداگانه در پایان نیست بلکه فرآیندی مداوم است که در هر مرحله از توسعه تنیده شده، از اولین خط کد تا استقرار production.
5~
6## هزینه امنیت دیرهنگام
7~
8گزارش هزینه نقض داده IBM به طور مداوم نشان داده که هزینه رفع مشکلات امنیتی به صورت نمایی رشد می‌کند هرچه دیرتر کشف شوند:
9~
10| مرحله | هزینه رفع | زمان رفع |
11|-------|------------|-------------|
12| **IDE / Local Dev** | دقیقه | ثانیه تا دقیقه |
13| **Code Review / PR** | ساعت | دقیقه تا ساعت |
14| **CI/CD Pipeline** | روز | ساعت تا روز |
15| **Staging / QA** | هفته | روز |
16| **Production** | ماه | هفته تا ماه |
17| **Post-breach** | میلیون‌ها ($) | ماه تا سال |
18~
19نتیجه‌گیری واضح است: هر مرحله‌ای که امنیت را زودتر جابجا کنید، یک مرتبه در هزینه و زمان صرفه‌جویی می‌کنید.
20~
21## خط لوله DevSecOps
22~
23یک خط لوله بالغ DevSecOps بررسی‌های امنیتی را در هر مرحله ادغام می‌کند:
24~
25```mermaid
26graph LR
27    IDE[IDE / Editor] --> PC[Pre-commit Hooks]
28    PC --> PR[Pull Request]
29    PR --> CI[CI Pipeline]
30    CI --> Build[Build / Package]
31    Build --> Deploy[Deploy]
32    Deploy --> Runtime[Runtime / Production]
33~
34    IDE -.- S1[SAST\nSecret Detection\nLinting]
35    PC -.- S2[Secrets Scan\nFormat Check]
36    PR -.- S3[Code Review\nDependency Audit]
37    CI -.- S4[SAST\nSCA\nContainer Scan\nSBOM]
38    Build -.- S5[Image Signing\nArtifact Verification]
39    Deploy -.- S6[Policy Enforcement\nAdmission Control]
40    Runtime -.- S7[DAST\nWAF\nMonitoring]
41```
42~
43بیایید هر مرحله را با ابزارها و پیکربندی‌های مشخص بررسی کنیم.
44~
45## مرحله 1: امنیت در IDE
46~
47سریع‌ترین حلقه بازخورد. آسیب‌پذیری‌ها را قبل از ذخیره فایل کشف کنید.
48~
49### ابزارهای پیشنهادی
50~
51- **Semgrep**: تحلیل استاتیک سبک با قوانین جامعه برای آسیب‌پذیری‌های OWASP
52- **Snyk IDE Extension**: اسکن آسیب‌پذیری وابستگی‌ها در لحظه
53- **GitLens + GitLeaks**: شناسایی secrets در ویرایشگر شما
54- **ESLint Security Plugins**: `eslint-plugin-security` برای Node.js، `eslint-plugin-no-unsanitized` برای DOM XSS
55~
56### مثال: پیکربندی ESLint Security
57~
58```json
59{
60  "extends": ["eslint:recommended"],
61  "plugins": ["security", "no-unsanitized"],
62  "rules": {
63    "security/detect-object-injection": "warn",
64    "security/detect-non-literal-regexp": "warn",
65    "security/detect-unsafe-regex": "error",
66    "security/detect-buffer-noassert": "error",
67    "security/detect-eval-with-expression": "error",
68    "security/detect-no-csrf-before-method-override": "error",
69    "security/detect-possible-timing-attacks": "warn",
70    "no-unsanitized/method": "error",
71    "no-unsanitized/property": "error"
72  }
73}
74```
75~
76## مرحله 2: Pre-commit Hooks
77~
78خط دفاع دوم. به صورت خودکار قبل از هر commit اجرا می‌شود و از ورود کد خطرناک به مخزن جلوگیری می‌کند.
79~
80### Gitleaks: secrets را قبل از رسیدن به Git شناسایی کنید
81~
82رایج‌ترین اشتباه امنیتی در codebases، commit کردن secrets است  -  API keys، database passwords، tokens. وقتی یک secret وارد git history شود، حذف کامل آن بسیار دشوار است (حتی با force pushes، forks و caches ممکن است آن را نگه دارند).
83~
84```yaml
85# .pre-commit-config.yaml
86repos:
87  - repo: https://github.com/gitleaks/gitleaks
88    rev: v8.21.0
89    hooks:
90      - id: gitleaks
91~
92  - repo: https://github.com/semgrep/semgrep
93    rev: v1.90.0
94    hooks:
95      - id: semgrep
96        args: ['--config', 'auto']
97```
98~
99نصب و فعال‌سازی:
100~
101```bash
102pip install pre-commit
103pre-commit install
104```
105~
106حالا هر `git commit` به صورت خودکار برای secrets فاش شده و آسیب‌پذیری‌های رایج اسکن می‌کند. اگر چیزی پیدا شود، commit مسدود می‌شود.
107~
108### قوانین سفارشی Gitleaks
109~
110می‌توانید الگوهای سفارشی برای secrets سازمان خود اضافه کنید:
111~
112```toml
113# .gitleaks.toml
114title = "Custom Gitleaks Config"
115~
116[[rules]]
117id = "internal-api-key"
118description = "Internal API key detected"
119regex = '''INTERNAL_KEY_[A-Za-z0-9]{32}'''
120tags = ["key", "internal"]
121```
122~
123## مرحله 3: امنیت CI/CD Pipeline
124~
125اینجاست که کار سنگین انجام می‌شود. خط لوله CI شما باید چندین اسکن امنیتی را روی هر pull request اجرا کند.
126~
127### SAST (Static Application Security Testing)
128~
129ابزارهای SAST کد منبع را بدون اجرا تحلیل می‌کنند و به دنبال الگوهایی هستند که نشان‌دهنده آسیب‌پذیری است.
130~
131```yaml
132# .github/workflows/security.yml
133name: Security Scan
134on:
135  pull_request:
136    branches: [main]
137~
138jobs:
139  sast:
140    name: Static Analysis
141    runs-on: ubuntu-latest
142    steps:
143      - uses: actions/checkout@v4
144~
145      - name: Run Semgrep
146        uses: semgrep/semgrep-action@v1
147        with:
148          config: >-
149            p/owasp-top-ten
150            p/typescript
151            p/nodejs
152            p/react
153          generateSarif: true
154~
155      - name: Upload SARIF
156        uses: github/codeql-action/upload-sarif@v3
157        with:
158          sarif_file: semgrep.sarif
159```
160~
161مجموعه قوانین `p/owasp-top-ten` در Semgrep رایج‌ترین آسیب‌پذیری‌ها را شناسایی می‌کند: SQL injection، XSS، SSRF، path traversal، insecure deserialization و موارد دیگر.
162~
163### SCA (Software Composition Analysis)
164~
165SCA وابستگی‌های شما را برای آسیب‌پذیری‌های شناخته شده اسکن می‌کند. این بسیار مهم است  -  بیش از 80% کد برنامه‌های مدرن از وابستگی‌های open-source می‌آید.
166~
167```yaml
168  dependency-scan:
169    name: Dependency Audit
170    runs-on: ubuntu-latest
171    steps:
172      - uses: actions/checkout@v4
173~
174      - name: Run Snyk
175        uses: snyk/actions/node@master
176        env:
177          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
178        with:
179          args: --severity-threshold=high
180~
181      - name: npm audit
182        run: npm audit --audit-level=high
183```
184~
185### امنیت کانتینر با Trivy
186~
187اگر Docker images می‌سازید، اسکن آنها برای آسیب‌پذیری ضروری است. **Trivy** محبوب‌ترین اسکنر کانتینر open-source است.
188~
189```yaml
190  container-scan:
191    name: Container Security
192    runs-on: ubuntu-latest
193    steps:
194      - uses: actions/checkout@v4
195~
196      - name: Build image
197        run: docker build -t my-app:${{ github.sha }} .
198~
199      - name: Run Trivy
200        uses: aquasecurity/trivy-action@master
201        with:
202          image-ref: my-app:${{ github.sha }}
203          format: 'sarif'
204          output: 'trivy-results.sarif'
205          severity: 'CRITICAL,HIGH'
206          exit-code: '1'
207~
208      - name: Upload Trivy SARIF
209        uses: github/codeql-action/upload-sarif@v3
210        with:
211          sarif_file: trivy-results.sarif
212```
213~
214### تولید SBOM
215~
216**Software Bill of Materials (SBOM)** فهرست کاملی از هر مولفه در برنامه شماست. به طور فزاینده‌ای توسط چارچوب‌های انطباق و مقررات دولتی مورد نیاز است (فرمان اجرایی آمریکا درباره امنیت سایبری SBOM را برای نرم‌افزار فدرال الزامی می‌کند).
217~
218```yaml
219  sbom:
220    name: Generate SBOM
221    runs-on: ubuntu-latest
222    steps:
223      - uses: actions/checkout@v4
224~
225      - name: Generate SBOM with Syft
226        uses: anchore/sbom-action@v0
227        with:
228          format: spdx-json
229          output-file: sbom.spdx.json
230~
231      - name: Upload SBOM
232        uses: actions/upload-artifact@v4
233        with:
234          name: sbom
235          path: sbom.spdx.json
236```
237~
238## مرحله 4: تصاویر امن Docker
239~
240یک تصویر Docker برای production باید اصل حداقل دسترسی را رعایت کند. یک Dockerfile تقویت شده به این شکل است:
241~
242```dockerfile
243# Build stage
244FROM node:22-alpine AS builder
245WORKDIR /app
246COPY package.json package-lock.json ./
247RUN npm ci
248COPY . .
249RUN npm run build
250~
251# Production stage
252FROM node:22-alpine AS runner
253WORKDIR /app
254~
255# Install dumb-init before dropping root
256RUN apk add --no-cache dumb-init
257~
258# Don't run as root
259RUN addgroup -S app && adduser -S app -G app
260~
261# Copy only what's needed
262COPY --from=builder --chown=app:app /app/dist ./dist
263COPY --from=builder --chown=app:app /app/node_modules ./node_modules
264COPY --from=builder --chown=app:app /app/package.json ./
265~
266# Drop to non-root user
267USER app
268ENTRYPOINT ["dumb-init", "--"]
269~
270# Health check
271HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
272  CMD wget -qO- http://localhost:3000/health || exit 1
273~
274EXPOSE 3000
275CMD ["node", "dist/server.js"]
276```
277~
278شیوه‌های کلیدی:
279~
2801. **از multi-stage builds استفاده کنید**: مرحله builder شامل dev dependencies است؛ مرحله runner فقط کد production دارد
2812. **به عنوان root اجرا نکنید**: یک کاربر غیر root بسازید و به آن تغییر دهید
2823. **از تصاویر Alpine استفاده کنید**: سطح حمله کوچکتر (بسته‌های کمتر به طور پیش‌فرض نصب شده)
2834. **نسخه تصاویر را ثابت کنید**: `node:22-alpine` به جای `node:latest` برای جلوگیری از حملات زنجیره تامین
2845. **از `npm ci` استفاده کنید**: نصب‌های قطعی از فایل قفل، نه `npm install`
285~
286## مرحله 5: مدیریت Secrets
287~
288Secrets نوشته شده در کد علت شماره یک نقض‌ها در حوادث ناشی از توسعه‌دهندگان هستند.
289~
290### آنچه نباید انجام دهید
291~
292```typescript
293// NEVER do this
294const API_KEY = "sk-1234567890abcdef";
295const DB_PASSWORD = "supersecret123";
296~
297const client = new Client({
298  connectionString: `postgres://admin:${DB_PASSWORD}@db.example.com/prod`
299});
300```
301~
302### آنچه باید به جای آن انجام دهید
303~
304```typescript
305// Use environment variables
306const client = new Client({
307  connectionString: process.env.DATABASE_URL
308});
309~
310// Or use a secret manager
311import { SecretManagerServiceClient } from '@google-cloud/secret-manager';
312~
313const client = new SecretManagerServiceClient();
314const [version] = await client.accessSecretVersion({
315  name: 'projects/my-project/secrets/db-password/versions/latest',
316});
317const dbPassword = version.payload?.data?.toString();
318```
319~
320### سلسله مراتب مدیریت Secrets
321~
322```mermaid
323graph TD
324    A[Secret Manager\nAWS Secrets Manager\nGCP Secret Manager\nHashiCorp Vault] --> B[Best: Rotated, audited, centralized]
325    C[Environment Variables\nInjected at deploy time] --> D[Good: Not in code, but static]
326    E[.env files\nWith .gitignore] --> F[Acceptable: Local development only]
327    G[Hard-coded in source] --> H[NEVER: Instant breach risk]
328~
329    style A fill:#d4edda
330    style C fill:#fff3cd
331    style E fill:#ffeeba
332    style G fill:#f8d7da
333```
334~
335## OWASP Top 10: مرجع سریع
336~
337هر توسعه‌دهنده‌ای باید OWASP Top 10 را بداند. نسخه خلاصه:
338~
339| # | آسیب‌پذیری | چیست | پیشگیری |
340|---|--------------|-----------|------------|
341| 1 | **Broken Access Control** | دسترسی کاربران به منابعی که نباید | رد به طور پیش‌فرض، اعتبارسنجی در سمت سرور |
342| 2 | **Cryptographic Failures** | رمزنگاری ضعیف، داده متن ساده | استفاده از الگوریتم‌های قوی (AES-256, bcrypt)، TLS در همه جا |
343| 3 | **Injection** | SQL, NoSQL, OS command injection | Parameterized queries، اعتبارسنجی ورودی |
344| 4 | **Insecure Design** | معماری معیوب | Threat modeling، الگوهای طراحی امن |
345| 5 | **Security Misconfiguration** | اعتبارنامه‌های پیش‌فرض، cloud buckets باز | پیش‌فرض‌های تقویت شده، ممیزی خودکار پیکربندی |
346| 6 | **Vulnerable Components** | CVEهای شناخته شده در وابستگی‌ها | اسکن SCA، به‌روزرسانی منظم |
347| 7 | **Auth Failures** | رمزهای عبور ضعیف، نشست‌های شکسته | MFA، محدودیت نرخ، مدیریت نشست امن |
348| 8 | **Data Integrity Failures** | به‌روزرسانی‌های بدون امضا، CI/CD غیرقابل اعتماد | امضای کد، SBOM، یکپارچگی خط لوله |
349| 9 | **Logging Failures** | بدون رد ممیزی | ثبت ساختاریافته، هشدار در مورد ناهنجاری‌ها |
350| 10 | **SSRF** | Server-side request forgery | لیست مجاز URL‌های خروجی، اعتبارسنجی ورودی‌ها |
351~
352## جریان کار کامل GitHub Actions Security
353~
354یک جریان کار کامل و آماده production که همه موارد بالا را ترکیب می‌کند:
355~
356```yaml
357# .github/workflows/security.yml
358name: Security Pipeline
359on:
360  pull_request:
361    branches: [main]
362  push:
363    branches: [main]
364~
365permissions:
366  contents: read
367  security-events: write
368~
369jobs:
370  secrets-scan:
371    name: Secret Detection
372    runs-on: ubuntu-latest
373    steps:
374      - uses: actions/checkout@v4
375        with:
376          fetch-depth: 0
377      - uses: gitleaks/gitleaks-action@v2
378        env:
379          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
380~
381  sast:
382    name: Static Analysis (SAST)
383    runs-on: ubuntu-latest
384    steps:
385      - uses: actions/checkout@v4
386      - uses: semgrep/semgrep-action@v1
387        with:
388          config: p/owasp-top-ten p/typescript p/nodejs
389~
390  dependency-audit:
391    name: Dependency Scan (SCA)
392    runs-on: ubuntu-latest
393    steps:
394      - uses: actions/checkout@v4
395      - uses: actions/setup-node@v4
396        with:
397          node-version: 22
398      - run: npm ci
399      - run: npm audit --audit-level=high
400      - uses: snyk/actions/node@master
401        env:
402          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
403        with:
404          args: --severity-threshold=high
405        continue-on-error: true
406~
407  container-scan:
408    name: Container Scan
409    runs-on: ubuntu-latest
410    needs: [sast, dependency-audit]
411    steps:
412      - uses: actions/checkout@v4
413      - run: docker build -t app:${{ github.sha }} .
414      - uses: aquasecurity/trivy-action@master
415        with:
416          image-ref: app:${{ github.sha }}
417          severity: CRITICAL,HIGH
418          exit-code: '1'
419~
420  sbom:
421    name: SBOM Generation
422    runs-on: ubuntu-latest
423    needs: [container-scan]
424    steps:
425      - uses: actions/checkout@v4
426      - uses: anchore/sbom-action@v0
427        with:
428          format: spdx-json
429          output-file: sbom.spdx.json
430```
431~
432```mermaid
433graph TD
434    PR[Pull Request] --> S1[Secret Detection]
435    PR --> S2[SAST - Semgrep]
436    PR --> S3[SCA - Snyk + npm audit]
437    S2 --> S4[Container Scan - Trivy]
438    S3 --> S4
439    S4 --> S5[SBOM Generation]
440    S5 --> Deploy[Deploy]
441~
442    S1 -.- F1[Block if secrets found]
443    S2 -.- F2[Block on critical vulns]
444    S3 -.- F3[Block on high severity]
445    S4 -.- F4[Block on critical CVEs]
446```
447~
448## معیارهایی برای پیگیری
449~
450چگونه بفهمید برنامه DevSecOps شما کار می‌کند؟ این معیارها را پیگیری کنید:
451~
452- **Mean time to remediate (MTTR)**: چقدر سریع آسیب‌پذیری‌ها را پس از شناسایی رفع می‌کنید
453- **Vulnerability escape rate**: درصد آسیب‌پذیری‌هایی که به production می‌رسند
454- **False positive rate**: مثبت‌های کاذب بیش از حد منجر به خستگی هشدار و نادیده گرفتن هشدارها می‌شود
455- **Dependency freshness**: میانگین سن وابستگی‌های شما (قدیمی‌تر = احتمال بیشتر CVEهای شناخته شده)
456- **SBOM coverage**: درصد پروژه‌ها با SBOMهای به‌روز
457~
458## شروع کار: یک نقشه راه عملی
459~
460سعی نکنید همه چیز را یکجا پیاده‌سازی کنید. رویکرد مرحله‌ای بهتر عمل می‌کند:
461~
462```mermaid
463flowchart TD
464    A[Week 1-2: Foundations] --> B[Week 3-4: CI/CD Integration]
465    B --> C[Month 2: Container Security]
466    C --> D[Month 3+: Advanced]
467~
468    A --> A1[Add Gitleaks pre-commit hooks]
469    A --> A2[Enable npm audit in CI]
470    A --> A3[Add .gitignore for .env files]
471~
472    B --> B1[Add Semgrep to GitHub Actions]
473    B --> B2[Add Snyk dependency scanning]
474    B --> B3[Set up SARIF upload to GitHub]
475~
476    C --> C1[Add Trivy container scanning]
477    C --> C2[Harden Dockerfiles]
478    C --> C3[Generate SBOMs]
479~
480    D --> D1[Secret manager integration]
481    D --> D2[Runtime protection - DAST]
482    D --> D3[Policy as code - OPA]
483```
484~
485## نتیجه‌گیری
486~
487DevSecOps درباره اضافه کردن ابزارهای بیشتر به خط لوله نیست  -  درباره تبدیل امنیت به بخشی طبیعی از نحوه ساخت نرم‌افزار است. هدف مسدود کردن هر PR با هشدارهای امنیتی نیست بلکه دادن بازخورد سریع به توسعه‌دهندگان است تا بتوانند مشکلات را زمانی رفع کنند که کد هنوز در ذهنشان تازه است.
488~
489با اصول شروع کنید: pre-commit hooks برای secrets، dependency scanning در CI، و container scanning برای Docker images. سپس بر اساس نیازهای تیم خود تکرار کنید.
490~
491امنیت یک ویژگی نیست که یک بار ارسال می‌کنید. یک عمل است که در هر commit می‌سازید.
492~
493> **DevSecOps Starter Checklist:**
494>
495> - [x] Gitleaks pre-commit hooks نصب شده
496> - [x] فایل‌های .env و secret در .gitignore
497> - [x] Semgrep SAST در CI pipeline
498> - [x] Snyk یا npm audit برای اسکن وابستگی‌ها
499> - [x] Trivy برای اسکن تصاویر کانتینر
500> - [x] کاربر غیر root در Dockerfiles
501> - [x] Secrets در environment variables یا secret manager
502> - [x] تولید SBOM در هر انتشار
503> - [x] آگاهی OWASP Top 10 در سراسر تیم
504~