1 
2En sarbarhet som upptaecks medan du skriver kod kostar en utvecklare minuter att atgaerda. Samma sarbarhet som foangas i produktion kostar en sprint. Och om en angripare hittar den foerst kostar det miljoner. Detta aer karnargumentet bakom **shift-left security**  -  att flytta saekerhetskontroller sa tidigt som moejligt i utvecklingscykeln.
3 
4DevSecOps tar denna ide och goer den till praktik: saekerhet aer inte en separat fas i slutet utan en kontinuerlig process som aer invaevd i varje steg av utvecklingen  -  fran den foersta kodraden till produktionsdistributionen.
5 
6## Kostnaden foer Sen Saekerhet
7 
8IBM:s Cost of a Data Breach Report har konsekvent visat att kostnaden foer att atgaerda saekerhetsbrister vaexer exponentiellt ju senare de upptaecks:
9 
10| Fas | Kostnad att atgaerda | Tid att atgaerda |
11|-----|----------------------|------------------|
12| **IDE / Lokal utveckling** | Minuter | Sekunder till minuter |
13| **Code Review / PR** | Timmar | Minuter till timmar |
14| **CI/CD Pipeline** | Dagar | Timmar till dagar |
15| **Staging / QA** | Veckor | Dagar |
16| **Produktion** | Manader | Veckor till manader |
17| **Efter introng** | Miljoner ($) | Manader till ar |
18 
19Slutsatsen aer tydlig: varje steg du flyttar saekerheten tidigare sparar en storleksordning i kostnad och tid.
20 
21## DevSecOps Pipeline
22 
23En mogen DevSecOps pipeline integrerar saekerhetskontroller i varje steg:
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 
43Lat oss ga igenom varje steg med konkreta verktyg och konfiguration.
44 
45## Steg 1: Saekerhet i IDE:n
46 
47Den snabbaste feedback-loopen. Fanga sarbarheter innan du ens sparar filen.
48 
49### Rekommenderade Verktyg
50 
51- **Semgrep**: laettviktig statisk analys med community-regler foer OWASP-sarbarheter
52- **Snyk IDE Extension**: realtidsskanning av sarbarheter i dependencies
53- **GitLens + GitLeaks**: upptaeck secrets i din editor
54- **ESLint Security Plugins**: `eslint-plugin-security` foer Node.js, `eslint-plugin-no-unsanitized` foer DOM XSS
55 
56### Exempel: ESLint Security-konfiguration
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## Steg 2: Pre-commit Hooks
77 
78Den andra foersvarslinjen. Koers automatiskt foere varje commit och blockerar farlig kod fran att na repositoryt.
79 
80### Gitleaks: Fanga Secrets innan de nar Git
81 
82Det vanligaste saekerhetsmisstaget i kodbaser aer att committa secrets  -  API keys, databasloesen, tokens. Nar en secret vaeal hamnar i git-historiken aer det extremt svart att ta bort den helt (aeven med force pushes kan forks och cachar behalla den).
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 
99Installera och aktivera:
100 
101```bash
102pip install pre-commit
103pre-commit install
104```
105 
106Nu skannar varje `git commit` automatiskt efter laeckta secrets och vanliga sarbarheter. Om nagot hittas blockeras committen.
107 
108### Anpassade Gitleaks-regler
109 
110Du kan laegga till anpassade moenster foer din organisations 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## Steg 3: CI/CD Pipeline Security
124 
125Haer goers det tunga arbetet. Din CI pipeline boer koera flera saekerhetskanningar vid varje pull request.
126 
127### SAST (Static Application Security Testing)
128 
129SAST-verktyg analyserar kaellkod utan att koera den och letar efter moenster som indikerar sarbarheter.
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 
161Semgreps ruleset `p/owasp-top-ten` fangar de vanligaste sarbarheterna: SQL injection, XSS, SSRF, path traversal, insecure deserialization och mer.
162 
163### SCA (Software Composition Analysis)
164 
165SCA skannar dina dependencies efter kaenda sarbarheter. Detta aer kritiskt  -  oever 80% av koden i moderna applikationer kommer fran 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### Container Security med Trivy
186 
187Om du bygger Docker images aer det vasentligt att skanna dem efter sarbarheter. **Trivy** aer den mest populaera open-source container-skannern.
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-generering
215 
216En **Software Bill of Materials (SBOM)** aer en komplett inventering av varje komponent i din applikation. Den kraevs alltmer av compliance-ramverk och statliga regleringar (den amerikanska Executive Order on Cybersecurity kraever SBOM foer federal programvara).
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## Steg 4: Saekra Docker Images
239 
240En produktions-Docker-image boer foelja principen om laegsta behoerigheter. Sa haer ser en haerdad Dockerfile ut:
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 
278Viktiga principer:
279 
2801. **Anvaend multi-stage builds**: builder-steget har dev-dependencies; runner-steget har bara produktionskod
2812. **Koer inte som root**: skapa en icke-root-anvaendare och byt till den
2823. **Anvaend Alpine images**: mindre attackyta (faerre paket installerade som standard)
2834. **Fixera image-versioner**: `node:22-alpine` istaellet foer `node:latest` foer att undvika supply chain-attacker
2845. **Anvaend `npm ci`**: deterministiska installationer fran lock-filen, inte `npm install`
285 
286## Steg 5: Secret Management
287 
288Haerdkodade secrets aer den vanligaste orsaken till introng vid utvecklarorsaktade incidenter.
289 
290### Vad du INTE ska goera
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### Vad du ska goera istaellet
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-hierarki
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: En Snabbreferens
336 
337Varje utvecklare boer kaenna till OWASP Top 10. Sammanfattad version:
338 
339| # | Sarbarhet | Vad det aer | Foerebyggande |
340|---|-----------|-------------|---------------|
341| 1 | **Broken Access Control** | Anvaendare som far atkomst till resurser de inte boer ha | Neka som standard, validera pa serversidan |
342| 2 | **Cryptographic Failures** | Svag kryptering, data i klartext | Anvaend starka algoritmer (AES-256, bcrypt), TLS oeverallt |
343| 3 | **Injection** | SQL, NoSQL, OS command injection | Parametriserade fragor, inmatningsvalidering |
344| 4 | **Insecure Design** | Bristfaellig arkitektur | Threat modeling, saekra designmoenster |
345| 5 | **Security Misconfiguration** | Standardinloggningar, oeppna cloud buckets | Haerdade standardvaerden, automatiserade konfigurationsgranskningar |
346| 6 | **Vulnerable Components** | Kaenda CVEs i dependencies | SCA scanning, regelmaessiga uppdateringar |
347| 7 | **Auth Failures** | Svaga loesenord, trasiga sessioner | MFA, rate limiting, saeker session management |
348| 8 | **Data Integrity Failures** | Osignerade uppdateringar, opaalitlig CI/CD | Code signing, SBOM, pipeline-integritet |
349| 9 | **Logging Failures** | Ingen revisionslogg | Strukturerad logging, larm vid avvikelser |
350| 10 | **SSRF** | Server-side request forgery | Allowlist foer utgaende URLs, validera inmatningar |
351 
352## Komplett GitHub Actions Security Workflow
353 
354Ett komplett, produktionsredo arbetsfoede som kombinerar allt ovan:
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## Maetetal att Foelja
449 
450Hur vet du att ditt DevSecOps-program fungerar? Foelja dessa maetetal:
451 
452- **Mean Time to Remediate (MTTR)**: hur snabbt du atgaerdar sarbarheter efter upptaeckt
453- **Vulnerability Escape Rate**: andelen sarbarheter som nar produktion
454- **False Positive Rate**: foer manga false positives leder till larmtroetthet och ignorerade varningar
455- **Dependency Freshness**: genomsnittsalder pa dina dependencies (aeldre = stoerre sannolikhet foer kaenda CVEs)
456- **SBOM Coverage**: andelen projekt med uppdaterade SBOMs
457 
458## Komma Igang: En Praktisk Faerdplan
459 
460Foersoek inte implementera allt pa en gang. En stegvis ansats fungerar baettre:
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## Slutsats
486 
487DevSecOps handlar inte om att laegga till fler verktyg i din pipeline  -  det handlar om att goera saekerhet till en naturlig del av hur du bygger programvara. Malet aer inte att blockera varje PR med saekerhetsvarningar utan att ge utvecklare snabb feedback sa att de kan atgaerda problem medan koden fortfarande aer faersk i minnet.
488 
489Boerja med grunderna: pre-commit hooks foer secrets, dependency scanning i CI och container scanning foer Docker images. Iterera sedan baserat pa vad ditt team behoever.
490 
491Saekerhet aer inte en funktion du levererar en gang. Det aer en praxis du bygger in i varje commit.
492 
493> **DevSecOps Starter Checklista:**
494>
495> - [x] Gitleaks pre-commit hooks installerade
496> - [x] .env och secret-filer i .gitignore
497> - [x] Semgrep SAST i CI pipeline
498> - [x] Snyk eller npm audit foer dependency scanning
499> - [x] Trivy foer container image scanning
500> - [x] Icke-root-anvaendare i Dockerfiles
501> - [x] Secrets i miljoevariablar eller secret manager
502> - [x] SBOM-generering vid varje release
503> - [x] OWASP Top 10-medvetenhet i hela teamet
504