1~
2کوڈ لکھتے وقت پائی جانے والی vulnerability کو ٹھیک کرنے میں ایک developer کو چند منٹ لگتے ہیں۔ وہی vulnerability اگر production میں پکڑی جائے تو ایک پورا sprint خرچ ہو جاتا ہے۔ اور اگر کوئی attacker اسے پہلے تلاش کر لے تو اس کی قیمت لاکھوں کروڑوں ہو سکتی ہے۔ یہی **shift-left security** کی بنیادی دلیل ہے  -  security checks کو development lifecycle میں جتنا جلد ممکن ہو آگے لانا۔
3~
4DevSecOps اس خیال کو ایک practice میں بدلتا ہے: security آخر میں کوئی الگ مرحلہ نہیں ہے بلکہ یہ development کے ہر مرحلے میں بنی ہوئی ایک مسلسل عمل ہے، کوڈ کی پہلی سطر سے لے کر production deployment تک۔
5~
6## دیر سے Security کی لاگت
7~
8IBM کی Cost of a Data Breach Report نے مسلسل دکھایا ہے کہ security issues کو ٹھیک کرنے کی لاگت جتنی دیر سے پکڑی جائیں اتنی تیزی سے بڑھتی ہے:
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نتیجہ واضح ہے: security کو جتنا پہلے لائیں، لاگت اور وقت میں اتنی ہی بچت ہوتی ہے۔
20~
21## DevSecOps Pipeline
22~
23ایک بالغ DevSecOps pipeline ہر مرحلے میں security checks کو ضم کرتی ہے:
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آئیے ہر مرحلے کو ٹھوس tools اور configuration کے ساتھ سمجھتے ہیں۔
44~
45## مرحلہ 1: IDE میں Security
46~
47سب سے تیز feedback loop۔ فائل save کرنے سے پہلے ہی vulnerabilities کو پکڑیں۔
48~
49### تجویز کردہ Tools
50~
51- **Semgrep**: OWASP vulnerabilities کے لیے community rules کے ساتھ ہلکا static analysis
52- **Snyk IDE Extension**: real-time dependency vulnerability scanning
53- **GitLens + GitLeaks**: اپنے editor میں secrets detect کریں
54- **ESLint Security Plugins**: Node.js کے لیے `eslint-plugin-security`، DOM XSS کے لیے `eslint-plugin-no-unsanitized`
55~
56### مثال: ESLint Security Configuration
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 سے پہلے خود بخود چلتی ہے، خطرناک کوڈ کو repository میں داخل ہونے سے روکتی ہے۔
79~
80### Gitleaks: Git میں پہنچنے سے پہلے Secrets پکڑیں
81~
82Codebases میں سب سے عام security غلطی secrets commit کرنا ہے  -  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~
99Install اور activate کریں:
100~
101```bash
102pip install pre-commit
103pre-commit install
104```
105~
106اب ہر `git commit` خود بخود leaked secrets اور عام vulnerabilities کے لیے scan کرتا ہے۔ اگر کچھ ملتا ہے تو commit block ہو جاتا ہے۔
107~
108### Custom Gitleaks Rules
109~
110آپ اپنی organization کے secrets کے لیے custom patterns شامل کر سکتے ہیں:
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 Security
124~
125یہاں بھاری کام ہوتا ہے۔ آپ کی CI pipeline کو ہر pull request پر متعدد security scans چلانے چاہئیں۔
126~
127### SAST (Static Application Security Testing)
128~
129SAST tools source code کو بغیر execute کیے analyze کرتے ہیں، ایسے patterns تلاش کرتے ہیں جو vulnerabilities کی نشاندہی کرتے ہیں۔
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~
161Semgrep کا `p/owasp-top-ten` ruleset سب سے عام vulnerabilities پکڑتا ہے: SQL injection, XSS, SSRF, path traversal, insecure deserialization، اور مزید۔
162~
163### SCA (Software Composition Analysis)
164~
165SCA آپ کی dependencies کو معروف vulnerabilities کے لیے scan کرتا ہے۔ یہ بہت اہم ہے  -  جدید application code کا 80% سے زیادہ open-source dependencies سے آتا ہے۔
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 کے ساتھ Container Security
186~
187اگر آپ Docker images build کرتے ہیں تو انہیں vulnerabilities کے لیے scan کرنا ضروری ہے۔ **Trivy** سب سے مقبول open-source container scanner ہے۔
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 Generation
215~
216**Software Bill of Materials (SBOM)** آپ کی application میں ہر component کی مکمل فہرست ہے۔ Compliance frameworks اور سرکاری ضوابط کی جانب سے اس کی مانگ بڑھ رہی ہے (US Executive Order on Cybersecurity federal software کے لیے 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: Secure Docker Images
239~
240ایک production Docker image کو least privilege کے اصول کی پیروی کرنی چاہیے۔ ایک hardened 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اہم practices:
279~
2801. **Multi-stage builds استعمال کریں**: builder stage میں dev dependencies ہوتی ہیں؛ runner stage میں صرف production code ہوتا ہے
2812. **Root کے طور پر نہ چلائیں**: ایک non-root user بنائیں اور اس میں switch کریں
2823. **Alpine images استعمال کریں**: چھوٹا attack surface (default میں کم packages installed)
2834. **Image versions pin کریں**: supply chain attacks سے بچنے کے لیے `node:latest` کے بجائے `node:22-alpine`
2845. **`npm ci` استعمال کریں**: lock file سے deterministic installs، `npm install` نہیں
285~
286## مرحلہ 5: Secret Management
287~
288Hard-coded secrets developer-caused incidents میں breaches کی نمبر ایک وجہ ہیں۔
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### Secret Management Hierarchy
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ہر developer کو OWASP Top 10 جاننا چاہیے۔ مختصر ورژن:
338~
339| # | Vulnerability | یہ کیا ہے | روک تھام |
340|---|--------------|-----------|------------|
341| 1 | **Broken Access Control** | Users ایسے resources تک رسائی حاصل کرتے ہیں جو انہیں نہیں کرنی چاہیے | Default میں deny کریں، server side پر validate کریں |
342| 2 | **Cryptographic Failures** | کمزور encryption, plaintext data | مضبوط algorithms استعمال کریں (AES-256, bcrypt)، ہر جگہ TLS |
343| 3 | **Injection** | SQL, NoSQL, OS command injection | Parameterized queries, input validation |
344| 4 | **Insecure Design** | ناقص architecture | Threat modeling, secure design patterns |
345| 5 | **Security Misconfiguration** | Default credentials, کھلے cloud buckets | Hardened defaults, automated config audits |
346| 6 | **Vulnerable Components** | Dependencies میں معروف CVEs | SCA scanning, باقاعدہ updates |
347| 7 | **Auth Failures** | کمزور passwords, ٹوٹے ہوئے sessions | MFA, rate limiting, secure session management |
348| 8 | **Data Integrity Failures** | Unsigned updates, غیر معتبر CI/CD | Code signing, SBOM, pipeline integrity |
349| 9 | **Logging Failures** | کوئی audit trail نہیں | Structured logging, anomalies پر alerting |
350| 10 | **SSRF** | Server-side request forgery | Outbound URLs allowlist کریں، inputs validate کریں |
351~
352## مکمل GitHub Actions Security Workflow
353~
354ایک مکمل، production-ready workflow جو اوپر کی تمام چیزوں کو جوڑتا ہے:
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## Track کرنے کے Metrics
449~
450آپ کو کیسے پتا چلے گا کہ آپ کا DevSecOps program کام کر رہا ہے؟ ان metrics کو track کریں:
451~
452- **Mean time to remediate (MTTR)**: detection کے بعد آپ کتنی تیزی سے vulnerabilities ٹھیک کرتے ہیں
453- **Vulnerability escape rate**: production تک پہنچنے والی vulnerabilities کا فیصد
454- **False positive rate**: بہت زیادہ false positives alert fatigue اور نظرانداز warnings کی طرف لے جاتے ہیں
455- **Dependency freshness**: آپ کی dependencies کی اوسط عمر (پرانی = معروف CVEs ہونے کا زیادہ امکان)
456- **SBOM coverage**: up-to-date SBOMs والے projects کا فیصد
457~
458## شروع کرنا: ایک عملی Roadmap
459~
460سب کچھ ایک ساتھ implement کرنے کی کوشش نہ کریں۔ مرحلہ وار طریقہ بہتر کام کرتا ہے:
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 آپ کی pipeline میں مزید tools شامل کرنے کے بارے میں نہیں ہے  -  یہ security کو software بنانے کے طریقے کا ایک فطری حصہ بنانے کے بارے میں ہے۔ مقصد ہر PR کو security warnings سے block کرنا نہیں ہے بلکہ developers کو تیز feedback دینا ہے تاکہ وہ issues کو اس وقت ٹھیک کر سکیں جب code ابھی ان کے ذہن میں تازہ ہو۔
488~
489بنیادی چیزوں سے شروع کریں: secrets کے لیے pre-commit hooks، CI میں dependency scanning، اور Docker images کے لیے container scanning۔ پھر اپنی team کی ضروریات کے مطابق iterate کریں۔
490~
491Security ایک ایسی feature نہیں ہے جو آپ ایک بار ship کرتے ہیں۔ یہ ایک practice ہے جو آپ ہر commit میں تعمیر کرتے ہیں۔
492~
493> **DevSecOps Starter Checklist:**
494>
495> - [x] Gitleaks pre-commit hooks installed
496> - [x] .env اور secret files .gitignore میں
497> - [x] CI pipeline میں Semgrep SAST
498> - [x] Dependency scanning کے لیے Snyk یا npm audit
499> - [x] Container image scanning کے لیے Trivy
500> - [x] Dockerfiles میں non-root user
501> - [x] Environment variables یا secret manager میں secrets
502> - [x] ہر release پر SBOM generation
503> - [x] پوری team میں OWASP Top 10 آگاہی
504~