1 
2En sarbarhed der opdages mens du skriver kode, koster en udvikler minutter at rette. Den samme sarbarhed fanget i produktion koster en sprint. Og hvis en angriber finder den foerst, koster det millioner. Dette er kerneargumentet bag **shift-left security**  -  at flytte sikkerhedstjek sa tidligt som muligt i udviklingslivscyklussen.
3 
4DevSecOps tager denne ide og goer den til praksis: sikkerhed er ikke en separat fase i slutningen, men en kontinuerlig proces vaevet ind i hvert trin af udviklingen  -  fra den foerste kodelinje til produktionsudrulningen.
5 
6## Omkostningerne ved Sen Sikkerhed
7 
8IBM's Cost of a Data Breach Report har konsekvent vist, at omkostningerne ved at rette sikkerhedsproblemer vokser eksponentielt, jo senere de opdages:
9 
10| Fase | Omkostning at rette | Tid at rette |
11|------|---------------------|--------------|
12| **IDE / Lokal udvikling** | Minutter | Sekunder til minutter |
13| **Code Review / PR** | Timer | Minutter til timer |
14| **CI/CD Pipeline** | Dage | Timer til dage |
15| **Staging / QA** | Uger | Dage |
16| **Produktion** | Maneder | Uger til maneder |
17| **Efter et brud** | Millioner ($) | Maneder til ar |
18 
19Konklusionen er klar: hvert trin du rykker sikkerheden tidligere, sparer en stoerrelseorden i omkostninger og tid.
20 
21## DevSecOps Pipeline
22 
23En moden DevSecOps pipeline integrerer sikkerhedstjek i hvert trin:
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 
43Lad os gennemga hvert trin med konkrete vaerktojer og konfiguration.
44 
45## Trin 1: Sikkerhed i IDE'en
46 
47Den hurtigste feedback-loop. Fang sarbarheder foer du overhovedet gemmer filen.
48 
49### Anbefalede Vaerktojer
50 
51- **Semgrep**: letvaegtigt statisk analyse med community-regler for OWASP-sarbarheder
52- **Snyk IDE Extension**: realtidsskanning af sarbarheder i dependencies
53- **GitLens + GitLeaks**: opdag secrets i din editor
54- **ESLint Security Plugins**: `eslint-plugin-security` for Node.js, `eslint-plugin-no-unsanitized` for DOM XSS
55 
56### Eksempel: 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## Trin 2: Pre-commit Hooks
77 
78Den anden forsvarslinje. Koerer automatisk foer hver commit og blokerer farlig kode fra at na repositoryet.
79 
80### Gitleaks: Fang Secrets foer de nar Git
81 
82Den mest almindelige sikkerhedsfejl i kodebaser er at committe secrets  -  API keys, databaseadgangskoder, tokens. Nar en secret havner i git-historikken, er det ekstremt svaert at fjerne den helt (selv med force pushes kan forks og caches beholde 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 
99Installer og aktiver:
100 
101```bash
102pip install pre-commit
103pre-commit install
104```
105 
106Nu scanner hver `git commit` automatisk for laekkede secrets og almindelige sarbarheder. Hvis noget findes, blokeres committet.
107 
108### Tilpassede Gitleaks-regler
109 
110Du kan tilfoeje tilpassede moenstre for 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## Trin 3: CI/CD Pipeline Security
124 
125Her sker det tunge arbejde. Din CI pipeline boer koere flere sikkerhedsscanninger ved hvert pull request.
126 
127### SAST (Static Application Security Testing)
128 
129SAST-vaerktojer analyserer kildekode uden at koere den og leder efter moenstre der indikerer sarbarheder.
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` fanger de mest almindelige sarbarheder: SQL injection, XSS, SSRF, path traversal, insecure deserialization og mere.
162 
163### SCA (Software Composition Analysis)
164 
165SCA scanner dine dependencies for kendte sarbarheder. Dette er kritisk  -  over 80% af koden i moderne applikationer kommer fra 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 
187Hvis du bygger Docker images, er det essentielt at scanne dem for sarbarheder. **Trivy** er den mest populaere 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-generering
215 
216En **Software Bill of Materials (SBOM)** er en komplet fortegnelse over hver komponent i din applikation. Den kraeves i stigende grad af compliance-rammer og statslige reguleringer (den amerikanske Executive Order on Cybersecurity paalaegger SBOM for foedealt software).
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## Trin 4: Sikre Docker Images
239 
240Et produktions-Docker-image boer foelge princippet om mindste rettigheder. Sadan ser en haerdet Dockerfile ud:
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 
278Vigtige principper:
279 
2801. **Brug multi-stage builds**: builder-fasen har dev-dependencies; runner-fasen har kun produktionskode
2812. **Koer ikke som root**: opret en ikke-root bruger og skift til den
2823. **Brug Alpine images**: mindre angrebsflade (faerre pakker installeret som standard)
2834. **Fastlags image-versioner**: `node:22-alpine` i stedet for `node:latest` for at undga supply chain-angreb
2845. **Brug `npm ci`**: deterministiske installationer fra lock-filen, ikke `npm install`
285 
286## Trin 5: Secret Management
287 
288Hardkodede secrets er den foerste arsag til sikkerhedsbrud ved udviklerforsagede haaendelser.
289 
290### Hvad du IKKE skal goere
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### Hvad du skal goere i stedet
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 Hurtig Reference
336 
337Enhver udvikler boer kende OWASP Top 10. Kort version:
338 
339| # | Sarbarhed | Hvad det er | Forebyggelse |
340|---|-----------|------------|--------------|
341| 1 | **Broken Access Control** | Brugere der far adgang til ressourcer de ikke burde | Afvis som standard, valider pa serversiden |
342| 2 | **Cryptographic Failures** | Svag kryptering, data i klartekst | Brug staerke algoritmer (AES-256, bcrypt), TLS overalt |
343| 3 | **Injection** | SQL, NoSQL, OS command injection | Parametriserede foresoergelser, inputvalidering |
344| 4 | **Insecure Design** | Mangelfuld arkitektur | Threat modeling, sikre designmoenstre |
345| 5 | **Security Misconfiguration** | Standardloginoplysninger, abne cloud buckets | Haerdede standardvaerdier, automatiserede konfigurationsrevisioner |
346| 6 | **Vulnerable Components** | Kendte CVEs i dependencies | SCA scanning, regelmaessige opdateringer |
347| 7 | **Auth Failures** | Svage adgangskoder, defekte sessioner | MFA, rate limiting, sikker session management |
348| 8 | **Data Integrity Failures** | Usignerede opdateringer, utrovaerdig CI/CD | Code signing, SBOM, pipeline-integritet |
349| 9 | **Logging Failures** | Ingen revisionslog | Struktureret logging, alarmering ved afvigelser |
350| 10 | **SSRF** | Server-side request forgery | Allowlist for udgaende URLs, valider input |
351 
352## Komplet GitHub Actions Security Workflow
353 
354Et komplet, produktionsklart workflow der kombinerer alt ovenstaende:
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## Metrikker at Foelge
449 
450Hvordan ved du, om dit DevSecOps-program virker? Foelg disse metrikker:
451 
452- **Mean Time to Remediate (MTTR)**: hvor hurtigt du retter sarbarheder efter detektion
453- **Vulnerability Escape Rate**: procentdelen af sarbarheder der nar produktion
454- **False Positive Rate**: for mange false positives foerer til alarmtraethed og ignorerede advarsler
455- **Dependency Freshness**: gennemsnitsalder pa dine dependencies (aeldre = stoerre sandsynlighed for kendte CVEs)
456- **SBOM Coverage**: procentdelen af projekter med opdaterede SBOMs
457 
458## Kom Godt I Gang: En Praktisk Koereplan
459 
460Forsoeg ikke at implementere alt pa en gang. En trinvis tilgang fungerer bedre:
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## Konklusion
486 
487DevSecOps handler ikke om at tilfoeje flere vaerktojer til din pipeline  -  det handler om at goere sikkerhed til en naturlig del af, hvordan du bygger software. Malet er ikke at blokere hver PR med sikkerhedsadvarsler, men at give udviklere hurtig feedback, sa de kan rette problemer mens koden stadig er frisk i hukommelsen.
488 
489Start med det grundlaeggende: pre-commit hooks for secrets, dependency scanning i CI og container scanning for Docker images. Iterer derefter baseret pa, hvad dit team har brug for.
490 
491Sikkerhed er ikke en funktion du leverer en gang. Det er en praksis du bygger ind i hvert commit.
492 
493> **DevSecOps Starter Tjekliste:**
494>
495> - [x] Gitleaks pre-commit hooks installeret
496> - [x] .env og secret-filer i .gitignore
497> - [x] Semgrep SAST i CI pipeline
498> - [x] Snyk eller npm audit til dependency scanning
499> - [x] Trivy til container image scanning
500> - [x] Ikke-root bruger i Dockerfiles
501> - [x] Secrets i miljoevariable eller secret manager
502> - [x] SBOM-generering ved hver release
503> - [x] OWASP Top 10-bevidsthed i hele teamet
504