Supply-Chain-Security als Karrierepfad: Warum Entwicklern mit Sicherheits-Skills die Zukunft gehört

Nachdem wir uns mit den Bedrohungen durch Supply-Chain-Angriffe und den verfügbaren Werkzeugen beschäftigt haben, bleibt eine zentrale Frage offen: Wer setzt diese Tools eigentlich ein? Wer maintained sie? Wer entwickelt neue? Und vor allem: Wer versteht beides – Code und Security?

Diese Fragen sind nicht abstrakt – sie betreffen jeden Entwickler, jedes Team, jedes Unternehmen. Auch mich. Denn bevor man Lösungen implementieren kann, muss man erst seine eigenen Probleme kennen. Welche Dependencies nutzen wir? Wo liegen unsere Schwachstellen? Welche Tools brauchen wir wirklich? Diese Selbstreflexion ist der erste Schritt.

Die technischen Lösungen existieren. Die Standards sind definiert. SLSA, Sigstore, OPA, Dependabot – alles da. Aber zwischen “Tool installieren” und “Organisation systematisch absichern” liegt eine Welt. Eine Welt, in der Menschen gebraucht werden, die nicht nur Sicherheitsrisiken erkennen, sondern auch Code schreiben können. Die nicht nur Policies definieren, sondern auch CI/CD-Pipelines bauen. Die Entwickler sind – mit einem tiefen Verständnis für Security.

Genau hier entsteht ein neues Berufsfeld. Eines, in dem die Nachfrage explodiert, die Gehälter überdurchschnittlich sind und die Aufgaben zwischen klassischer Entwicklung und Sicherheitsarchitektur liegen. Ein Feld, in dem sich spezialisieren lohnt – beruflich wie gesellschaftlich.

Das Spielfeld hat sich verändert

Die Zahlen sprechen eine klare Sprache:

Arbeitsmarkt 2025/2026:

DevSecOps-Gehalt: €165.000 durchschnittlich (Glassdoor 2026, umgerechnet)
Senior DevSecOps Engineer: €200.000 durchschnittlich
20% höher als klassische Information Security Analysts
Gehaltsrange: €130k (25. Perzentil) bis €270k (90. Perzentil)
Marktwachstum (CAGR): 24,1% zwischen 2021-2028

Die Nachfrage: Die Branche spricht von explodierender Nachfrage nach DevSecOps-Engineers, die sowohl entwickeln als auch absichern können. Das ist kein Hype. Das ist strukturelle Transformation.

Warum jetzt?

Angreifer automatisieren: KI-gestützte Exploits, selbst-replizierende Malware (siehe GlassWorm in Teil 1)
Regulierung verschärft sich: EU Cyber Resilience Act, NIS2, DORA
Supply Chain ist Business-Critical: Ein Breach kostet durchschnittlich €4,5M
Tools allein reichen nicht: Sie müssen konfiguriert, gewartet, weiterentwickelt werden

Die Lücke zwischen “Wir brauchen Sicherheit” und “Wir können sie umsetzen” wächst schneller als sie geschlossen wird.

Git Repos mit KI absichern: Von der Theorie zur Praxis

KI-Assistenten im Vergleich

Verschiedene KI-Tools bieten unterschiedliche Ansätze für Security-Workflows:

GitHub Copilot: Integriert in VS Code, Agent Skills, direkte GitHub Actions Integration
Claude (Anthropic): Projects mit zentraler Config, Custom Styles, MCP-Server für Tool-Integration
ChatGPT/GPT-4: Custom GPTs, Plugins, API-Integration

Jedes Tool hat seine Stärken. In diesem Artikel fokussieren wir auf GitHub Copilot und Claude, da beide projektübergreifende Konfigurationen ermöglichen.

GitHub Copilot Agent Skills: Security als Code

Neu seit Ende 2025: GitHub Copilot unterstützt Agent Skills – strukturierte, wiederverwendbare Anweisungen, die der KI beibringen, spezifische Security-Tasks auszuführen.

Was sind Skills?

Ordner mit Instruktionen, Skripten und Ressourcen
Geladen, wenn relevant für die aktuelle Aufgabe
Funktionieren über VS Code, CLI und GitHub Copilot Coding Agent

Security-Skills Beispiel:

# .github/copilot-skills/security-review/instructions.md

You are a security reviewer. When analyzing code changes:

1. Check for common vulnerabilities:
   - SQL injection (parameterized queries?)
   - XSS (output escaping?)
   - CSRF (token validation?)
   - Insecure deserialization
   - Path traversal

2. Validate dependencies:
   - Are new packages from trusted sources?
   - Any known CVEs?
   - License compatible?

3. Secret detection:
   - API keys, passwords in code?
   - Hardcoded credentials?
   - .env files properly gitignored?

4. Authentication/Authorization:
   - Proper access controls?
   - Session management secure?
   - Role checks in place?

Output: JSON with findings, severity, and suggested fixes.

Nutzung im Team:

# In PR-Review
@copilot /security-review

Die KI lädt das Skill, analysiert den PR und gibt strukturiertes Feedback.

Copilot Coding Agent: Proaktive Security-Validierung

Oktober 2025: GitHub Copilot Coding Agent validiert jetzt automatisch Code-Sicherheit und -Qualität.

Was passiert:

CodeQL-Analyse: Scannt generierten Code auf Vulnerabilities
Dependency-Check: Prüft neue Dependencies gegen GitHub Advisory Database
Secret Scanning: Erkennt versehentlich eingefügte Secrets
ESLint/Linter: Kombiniert LLM-Detections mit deterministischen Tools

Praktisch:

// Copilot generiert:
const query = `SELECT * FROM users WHERE id = ${userId}`;

// Copilot Coding Agent erkennt sofort:
// ⚠️ SQL Injection vulnerability detected
// Suggestion: Use parameterized queries
const query = `SELECT * FROM users WHERE id = ?`;

Das ist Shift Left in Reinform: Security-Checks bevor Code committed wird.

Custom Agents für spezifische Stacks

Neu 2025: Partner-built Custom Agents für GitHub Copilot.

Security-Fokussierte Agents:

JFrog Security Agent: Scannt Artifacts auf Vulnerabilities
StackHawk Security Onboarding: Automated Security Testing
Snyk Agent: Real-time Dependency Analysis

Integration:

# .github/copilot.yml
agents:
  - name: jfrog-security
    on: [pull_request]
  - name: stackhawk
    on: [push]
    branches: [main, staging]

Pre-Commit Hooks mit KI-Validation

Praktisches Beispiel: Lokale Security-Checks vor jedem Commit.

# .git/hooks/pre-commit
#!/usr/bin/env python3
import openai
import subprocess
import sys

def get_staged_diff():
    return subprocess.check_output(['git', 'diff', '--staged']).decode()

def ai_security_check(diff):
    client = openai.OpenAI()
    response = client.chat.completions.create(
        model="gpt-4",
        messages=[{
            "role": "system",
            "content": """You are a security expert. Analyze this git diff for:
            1. Hardcoded secrets (API keys, passwords)
            2. SQL injection vulnerabilities
            3. XSS vulnerabilities
            4. Insecure dependencies
            
            Return JSON: {"safe": bool, "issues": [{"severity": str, "line": int, "description": str}]}"""
        }, {
            "role": "user",
            "content": diff
        }]
    )
    
    return response.choices[0].message.content

if __name__ == "__main__":
    diff = get_staged_diff()
    
    if not diff:
        sys.exit(0)
    
    result = ai_security_check(diff)
    
    # Parse JSON und prüfe result["safe"]
    # Wenn unsafe: print issues, exit(1)
    # Wenn safe: exit(0)

Trade-offs:

✅ Sofortiges Feedback
✅ Verhindert versehentliche Secrets
❌ Kostet Zeit (API-Call)
❌ False Positives möglich

Lösung: Kombiniere mit lokalen Tools (TruffleHog, Gitleaks) für Secret Detection, nutze KI nur für komplexere Patterns.

Semgrep mit Custom Rules: Organisation-spezifische Sicherheit

Problem: Jede Organisation hat eigene Security-Patterns.

Lösung: Custom Semgrep Rules.

Beispiel: Interne Auth-Library muss genutzt werden

# .semgrep/rules/enforce-internal-auth.yml
rules:
  - id: enforce-internal-auth
    pattern: |
      import jwt
    message: "Use internal auth library instead of direct JWT"
    severity: ERROR
    languages: [python]
    metadata:
      category: security
      fix: "from internal.auth import authenticate"

CI/CD Integration:

# .github/workflows/semgrep.yml
name: Semgrep Security Scan
on: [pull_request]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: .semgrep/

Vorteil: Organisationswissen als Code. Neue Entwickler können gar nicht erst unsicheren Code schreiben.

Der kontinuierliche Prüfprozess: Shift Left in der Praxis

Von “Security am Ende” zu “Security ab Tag 1”

Alt (Waterfall Security):

Development → Testing → Security Review → Production
                            ↑
                       Blocker gefunden
                       Zurück zu Development

Neu (Shift Left):

Security Requirements → Secure Design → Secure Coding → Automated Tests → Production
    ↓                       ↓               ↓                 ↓
Policy as Code      Threat Modeling    IDE Checks      SLSA Provenance

Konkret:

Tag 0: Threat Model erstellen (was schützen wir?)
Tag 1: Security Requirements in User Stories
Development: IDE zeigt Security-Issues während des Schreibens
Pre-Commit: Lokale Hooks blocken Secrets
PR: Automated Security Review (Copilot, Semgrep, CodeQL)
Merge: SLSA Provenance wird generiert
Deployment: Signierte Artifacts, Runtime Monitoring

Kontinuierliche Validierung: Der Security-Kalender

Täglich:

Dependency Scans (Renovate/Dependabot)
Secret Scanning (GitGuardian, TruffleHog)
SAST auf Main Branch (CodeQL, Semgrep)

Wöchentlich:

Security Dashboard Review (offene Alerts)
Dependency Update PRs reviewen
Neue CVEs für genutzte Packages prüfen

Monatlich:

Policy Review (sind OPA-Rules noch aktuell?)
Threat Model Update (neue Features = neue Threats?)
Security Metrics Review (MTTR für Security Issues?)

Quartalsweise:

Incident Response Drill (Tabletop Exercise)
Penetration Test (intern oder extern)
Security Training für Team
Tool-Evaluierung (gibt es bessere Alternativen?)

Jährlich:

Compliance Audit (SOC 2, ISO 27001)
Security Strategy Review
Budget Planning für Tools und Personal

KI als Assistenz, nicht als Ersatz

Wo KI hilft:

Pattern Recognition: “Diese Dependency hat ein ungewöhnliches Verhalten”
Anomalie-Detection: “Dieser PR ändert 500 Dateien – verdächtig?”
Code-Review: “Dieser SQL-Query ist injizierbar”
Threat Intelligence: “Dieses Package wurde vor 3 Tagen kompromittiert”

Wo Menschen entscheiden:

Kontext: Ist diese Dependency trotz alter Version OK, weil stabil?
Risk Acceptance: Nehmen wir dieses Risiko bewusst in Kauf?
Incident Response: Wie kommunizieren wir einen Breach?
Ethik: Dürfen wir dieses Tool überhaupt nutzen?

Das Dual-Use-Problem: KI als Waffe und Schild

Die paradoxe Realität: KI-Systeme, die entwickelt wurden, um Angriffe zu verhindern, besitzen exakt dieselben Fähigkeiten, die für Angriffe benötigt werden. Ein Code-Analyse-Tool, das Schwachstellen findet, kann genauso gut von Angreifern genutzt werden, um Exploits zu entwickeln.

Drei kritische Dimensionen:

1. Ethische Guardrails in KI-Systemen

GitHub Copilot, ChatGPT & Co haben eingebaute Sicherheitsmechanismen
Sie weigern sich, explizite Malware zu generieren
Aber: Diese Guardrails sind trainiert, nicht absolut
Cleveres Prompt Engineering kann sie umgehen

2. Lokale Modelle ohne Einschränkungen

Open-Source-LLMs (Llama, Mistral, Phi) laufen lokal
Keine eingebauten ethischen Beschränkungen
Angreifer können sie fine-tunen für Exploit-Entwicklung
Dieselben Tools, die Verteidiger nutzen

3. Staatliche Akteure

Haben Zugang zu unbeschränkten Rechenressourcen
Können eigene Modelle trainieren ohne ethische Constraints
Nutzen KI für Zero-Day-Discovery
APT-Gruppen automatisieren bereits Reconnaissance und Exploitation

Das Dilemma: Wenn wir KI einsetzen, um Supply-Chain-Angriffe zu verhindern, trainieren wir gleichzeitig Systeme, die – in den falschen Händen – diese Angriffe perfektionieren können. Ein KI-Modell, das gelernt hat, Malware-Patterns in npm-Paketen zu erkennen, hat implizit auch gelernt, wie Malware aussehen muss, um erfolgreich zu sein.

Die notwendige Antwort:

Transparenz statt Security through Obscurity: Defense-Mechanismen offen dokumentieren
Continuous Validation: Regelmäßig prüfen, ob eigene KI-Tools missbraucht werden können
Red Teaming: Eigene KI-Systeme aktiv zu knacken versuchen
Ethik als Entwickler-Skill: Nicht nur “Was kann ich bauen?”, sondern “Was sollte ich bauen?”

Entwickler, die KI-Security-Tools entwickeln, tragen eine besondere Verantwortung. Sie müssen nicht nur verstehen, wie Angriffe funktionieren, sondern auch die ethischen Implikationen ihrer Werkzeuge reflektieren.

Das neue Berufsbild: Supply Chain Security Engineer

Das Skillset: Drei Welten vereint

1. Development (40%)

Git, GitHub Actions, GitLab CI
Container (Docker, Kubernetes)
IaC (Terraform, CloudFormation)
Mindestens eine Programmiersprache gut (Python, Go)
CI/CD Pipelines bauen und debuggen

2. Security (40%)

OWASP Top 10, CVE-System
Threat Modeling (STRIDE, PASTA)
Incident Response
Cryptography (nicht Mathe, aber Anwendung)
Compliance (DSGVO, NIS2, SOC 2)

3. Automation & KI (20%)

OPA/Rego für Policy as Code
Python für Custom Tooling
GitHub Actions Entwicklung
Prompt Engineering für KI-Tools
Optional: ML für Anomalie-Detection

Soft Skills:

Kommunikation: Security-Risiken für nicht-technische Stakeholder erklären
Empathie: Entwickler enablen, nicht blockieren
Pragmatismus: Perfekte Sicherheit gibt es nicht, Risiken managen
Lernbereitschaft: Angreifer entwickeln sich weiter, du auch

Spezialisierungspfade: Wo willst du hin?

1. Policy Engineering

Focus: Automatisierte Compliance, OPA/Rego-Expertise
Tools: Open Policy Agent, Kyverno, Cloud Custodian
Outcome: Policy as Code für gesamte Organisation
Gehalt: €140-180k

Beispiel-Projekt: Alle Kubernetes-Deployments müssen SLSA Level 2 haben, automatisch durchgesetzt via Admission Controller.

2. Tool Development

Focus: Custom Security Tooling, GitHub Actions, Integrations
Tools: Go, Python, GitHub API, REST APIs
Outcome: Eigene Tools für spezifische Org-Probleme
Gehalt: €150-200k

Beispiel-Projekt: Custom GitHub Action, die automatisch SBOMs generiert und in Artifact Registry hochlädt.

3. Threat Intelligence & Hunting

Focus: Malware Analysis, Supply Chain Threat Hunting
Tools: Reverse Engineering, Sandboxing, Threat Feeds
Outcome: Proaktive Erkennung von Angriffen
Gehalt: €160-220k

Beispiel-Projekt: Automatisches System, das neue PyPI/npm-Pakete auf Malware scannt, bevor sie intern genutzt werden dürfen.

4. AI Security Engineering

Focus: KI-gestützte Code-Reviews, ML für Anomalie-Detection
Tools: OpenAI API, LangChain, Custom ML Models
Outcome: KI-Systeme, die Security-Probleme vorhersagen
Gehalt: €165-255k

Beispiel-Projekt: Fine-Tuned Model, das organisation-spezifische Security-Patterns erkennt, die öffentliche Tools übersehen.

Der Karrierepfad: Von Junior bis Principal

Junior DevSecOps Engineer (0-2 Jahre)

Aufgaben: Tools nutzen, Policies umsetzen, Alerts triagieren
Gehalt: €50-70k
Learning: OWASP, GitHub Actions, Basic Scripting

DevSecOps Engineer (2-5 Jahre)

Aufgaben: Tools anpassen, Policies entwickeln, Incident Response
Gehalt: €70-100k
Learning: OPA/Rego, Threat Modeling, CI/CD Expertise

Senior DevSecOps Engineer (5-8 Jahre)

Aufgaben: Architektur, Tool-Evaluierung, Mentoring
Gehalt: €100-130k
Learning: Leadership, Strategic Thinking, Business Impact

Principal Security Engineer (8+ Jahre)

Aufgaben: Organisation-weite Security-Strategie, Custom Tool Development
Gehalt: €130-180k
Learning: Executive Communication, Multi-Team Coordination

Head of Supply Chain Security (10+ Jahre)

Aufgaben: Team-Aufbau, Budget, Unternehmens-Strategie, C-Level Reporting
Gehalt: €150k+
Learning: People Management, Business Strategy, Risk Management

Die Kosten-Rechnung: Investition vs. Schaden

Was kostet Absicherung? (pro Jahr)

Personal:

1x Junior DevSecOps Engineer: €60.000
1x DevSecOps Engineer: €85.000

Tools (für 20 Entwickler):

GitHub Advanced Security: €12.000 (€50/Dev/Monat)
Snyk Team: €6.000 (€25/Dev/Monat)
Socket.dev: €0 (Free Tier)
Renovate: €0 (Open Source)

Training:

DevSecOps Zertifizierung (GIAC, OSCP): €5.000

Gesamt: ~€93.000 pro Jahr

Was kostet ein Breach?

Direkte Kosten:

Durchschnittlicher Supply-Chain-Breach: €4,5 Millionen
Fortune-500 nach Major Breach (15 Monate): €18-75 Milliarden
Downtime (Industrial): €115.000 pro Stunde

Indirekte Kosten:

Reputationsschaden (Customer Churn)
Regulatorische Strafen (DSGVO: bis zu €20M oder 4% Umsatz)
NIS2-Strafen: bis zu €10M
Incident Response (externes Team): €200-500k
Legal Fees: €500k-2M

Break-Even-Rechnung:

Investition: €93.000/Jahr
Verhindert: 1 Breach alle 48 Jahre

Realität 2025:
- 45% der Unternehmen hatten 2025 einen Supply-Chain-Angriff
- Supply-Chain-Angriffe: +93% (2024→2025)

Break-Even: Nach 20 Tagen.

Wenn Ihre Investment einen einzigen Angriff pro Jahr verhindert, sparen Sie das 48-fache.

Open Source: Die Basis von allem

Das Dilemma

Die Realität:

90% aller Unternehmen nutzen Open Source
Unter 1% tragen aktiv bei (Code, Geld, Reviews)
84% der Codebases enthalten mindestens eine bekannte Vulnerability (Synopsys 2025)

Das Problem:

Maintainer sind überlastet
Viele kritische Projekte haben 1-2 Vollzeit-Maintainer
Security-Audits kosten Zeit, die niemand hat
Funding ist inkonsistent

OpenSSF Alpha-Omega: Collective Defense

Was ist Alpha-Omega?

Ein OpenSSF-Projekt (gegründet 2022), finanziert von Microsoft, Google, Amazon und Citi, mit der Mission, die kritischste Open-Source-Software der Welt abzusichern.

Zwei Komponenten:

Alpha: Arbeitet direkt mit Maintainern der kritischsten Projekte

Identifiziert Vulnerabilities
Hilft bei Fixes
Verbessert Security-Posture

Omega: Analysiert 10.000+ weit verbreitete OSS-Projekte

Automatisierte Security-Analyse
Scoring
Remediation Guidance an Maintainer-Communities

Finanzierung 2023:

10 Grants an 8 Organisationen
Gesamt: €2,6 Millionen
Durchschnitt: €320.000 pro Grant

Geförderte Projekte:

Rust Foundation
Python Software Foundation
Eclipse Foundation
Homebrew
Node.js
curl
OpenSSL

2025 Plans: Fortführung und Expansion des Modells.

Die Verantwortung: Wer nutzt, sollte beitragen

Drei Wege beizutragen:

1. Code & Reviews

Security Patches schreiben
Code Reviews für Security-relevante PRs
Dependency Updates testen

2. Funding

GitHub Sponsors
OpenCollective
Tidelift
Direct Sponsorship

3. Security Audits

Professionelle Security Audits finanzieren
Ergebnisse mit Maintainern teilen
Fixes sponsorn

Beispiel:
curl wird von Milliarden Geräten genutzt. Hauptmaintainer: Daniel Stenberg, seit 1998. GitHub Sponsors: ~€3.700/Monat (Stand 2024). Das ist lächerlich wenig für kritische Infrastruktur.

Die Chance: Security ist Open Source

Die Tools, die wir in Teil 2 beschrieben haben, sind Open Source:

Socket.dev: github.com/SocketDev
Sigstore: github.com/sigstore
SLSA: Offener Standard
Open Policy Agent: github.com/open-policy-agent
Semgrep: github.com/semgrep

Das bedeutet:

Jeder kann lernen, wie Angriffe funktionieren (Malware-Samples sind öffentlich)
Jeder kann Tools verbessern (Pull Requests willkommen)
Community > Individual Security

Security through Obscurity funktioniert nicht.
Offenheit schafft Resilienz. Transparenz schafft Vertrauen.

Konkret:

Wenn Socket.dev eine neue Malware-Kategorie erkennt → öffentlich dokumentiert
Wenn Sigstore einen Bug findet → öffentlich gefixt, CVE published
Wenn SLSA Level 4 definiert wird → Community-Input

Das ist das Gegenteil von “Vendor Lock-In” – es ist Collective Defense.

Die Zukunft: Automatisierung trifft Spezialisierung

Was kommt (2026-2030)

1. KI-gestützte Vulnerability Discovery

Heute: Tools scannen bekannte Patterns (SAST, DAST)
Morgen: KI findet Zero-Days automatisch
Beispiel: Fuzzing mit LLM-Guidance entdeckt neue Exploit-Klassen

2. Self-Healing Systems

Heute: Vulnerability Alert → Manueller Fix → PR → Review → Merge
Morgen: Alert → Automated Fix → Automated Test → Auto-Merge (bei niedrigem Risk)
Beispiel: Dependabot merged Security-Patches automatisch nach erfolgreichen Tests

3. Proactive Threat Hunting

Heute: React auf bekannte Threats (CVE-Datenbanken)
Morgen: KI erkennt verdächtige Patterns, bevor CVE existiert
Beispiel: “Dieses neue npm-Paket verhält sich wie Malware, obwohl noch kein CVE”

4. Quantum-Safe Cryptography

Heute: RSA, ECC
Morgen: Post-Quantum-Algorithmen (NIST-standardisiert 2024)
Beispiel: Sigstore migriert zu Quantum-Safe Signing

5. Provenance everywhere

Heute: SLSA für kritische Services
Morgen: SLSA für jedes Artifact (verpflichtend via Regulation)
Beispiel: Jedes Docker Image hat signierte Provenance, sonst wird es nicht deployed

Was bleibt: Der Entwickler

Auch 2030 braucht es Menschen für:

1. Kontext-Verständnis
Ist dieses veraltete Package OK, weil es stabil ist und niemand mehr maintained?

2. Ethische Entscheidungen
Dürfen wir dieses Tool nutzen, obwohl es Nutzerdaten sammelt?

3. Incident Response unter Stress
Wir wurden gehackt. Was sagen wir der Presse? Wann informieren wir Kunden?

4. Business-Risk-Abwägung
Dieser Patch bricht Backwards Compatibility. Deployen wir trotzdem?

5. Strategische Planung
Worin investieren wir die nächsten 3 Jahre: Tooling oder Personal?

Die Offensive der Verteidigung

Supply-Chain-Security ist nicht defensiv. Es ist proaktiv.

Drei Ebenen:

1. Reactive (Gestern):

Warten auf CVE → Patch → Deploy
Incident passiert → Respond
Compliance-Audit einmal pro Jahr

2. Proactive (Heute):

Continuous Scanning (täglich)
Shift Left (Security in Development)
Policy as Code (automatische Enforcement)

3. Predictive (Morgen):

KI erkennt Threats bevor sie CVEs sind
Self-Healing Systems patchen automatisch
Threat Models aktualisieren sich selbst basierend auf Code-Änderungen

Wer heute in (2) investiert, ist morgen bereit für (3).

Für Entwickler: Lerne Security. Es lohnt sich.

Start klein:

Mach ein OWASP-Top-10-Tutorial (2 Stunden)
Aktiviere Dependabot in einem Projekt (30 Sekunden)
Schreib einen Pre-Commit-Hook für Secret Detection (1 Stunde)
Review einen Security-PR in einem Open-Source-Projekt (variiert)
Nimm an einem CTF teil (Capture The Flag, z.B. PicoCTF)

Danach:

GitHub Actions Security Hardening Guide lesen
OPA Playground ausprobieren
SLSA-Provenance für ein eigenes Projekt generieren
Einen Security-Blogpost schreiben (zeigt Verständnis)

Gehalt-Boost: Von €110k (Software Engineer) zu €165k (DevSecOps Engineer) = +50%

Karriere-Optionen:

Breiter (mehr Verantwortung in aktuellem Unternehmen)
Tiefer (Spezialisierung, Consulting)
Höher (Principal Engineer, Head of Security)

Für Unternehmen: Investiert in DevSecOps. Es schützt euch.

Drei Schritte:

1. Hire or Train

Option A: DevSecOps Engineer einstellen
Option B: Entwickler mit Security-Interest weiterbilden (billiger, besser für Culture)

2. Tools einführen

Start: Dependabot, Secret Scanning, Branch Protection (kostenlos)
Mittel: Renovate, Socket.dev, Semgrep
Enterprise: GHAS, Snyk, Custom Tooling

3. Prozess etablieren

Security Requirements in Definition of Done
Pre-Commit Hooks für alle Repos
Monatliche Security Reviews
Quartalsweise Drills

ROI-Garantie: Ein verhindeter Breach zahlt die Investment für 48 Jahre.

Für die Community: Sichert Open Source gemeinsam

Drei Aktionen:

1. Sponsort Maintainer

GitHub Sponsors aktivieren (dauert 5 Minuten)
Monatlich €10-50 an kritische Dependencies
Transparent kommunizieren (zeigt Commitment)

2. Contributed Code oder Reviews

Security Patches schreiben
Dependency Updates testen
Security-relevante PRs reviewen

3. Finanziert Audits

Professionelle Security Audits kosten €18-45k
Für kritische Dependencies unbezahlbar
Unternehmen können das finanzieren

Beispiel: Node.js nutzt eure Firma? Node.js hat ein OpenCollective: opencollective.com/nodejs. €90/Monat von 100 Firmen = €9k/Monat für Security-Arbeit. Das ist Collective Defense in der Praxis.

Ausblick: Im vierten Teil dieser Serie zeigen wir konkret, wie Claude Projects mit zentralen Security-Configs über alle Repositories hinweg genutzt werden können – inklusive MCP-Server-Integration für automatisierte Security-Checks und projektübergreifenden Custom Styles für konsistente Code-Reviews.

Eine kritische Perspektive: Als Entwickler, der gerne Software erstellt und KI noch als Support seiner Arbeit versteht, ist das größte Problem nicht die fehlende Technologie – es ist die Erkenntnis, dass Open Source nicht mehr per se “sicher” ist. Die Automatisierung, die wir erreicht haben, verschiebt das Problem nur. Sie macht es nicht grundlegend günstiger, sondern verlagert Kosten von einem Bereich (manuelle Arbeit) in einen anderen (Tools, Validierung, Monitoring).

Was VMs und Docker als Sicherheit durch Isolation dargestellt haben, muss für Code-Qualität und -Sicherheit weitergedacht werden. Isolation allein reicht nicht. Die unbequeme Wahrheit: Für wirkliche Sicherheit wird man bezahlen müssen – in Form von Zeit (Reviews, Audits), Geld (Tools, Experten) oder beidem. Die Illusion, dass Open Source “gratis und sicher” ist, bröckelt. Open Source ist gratis verfügbar, aber sicher machen muss es jemand – und diese Arbeit kostet.

Die Frage ist nicht, ob wir investieren, sondern wie viel wir bereit sind zu zahlen, bevor der nächste große Breach die Entscheidung für uns trifft.

Weiterführende Links

Karriere & Gehalt:

Tools & Skills:

Open Source Security:

Weitere Artikel dieser Serie: Die Serie-Navigation wird automatisch angezeigt.

Quellen

Was Supply-Chain-Security konkret bedeutet – jenseits Buzzwords

Der Begriff klingt nach Spezialdisziplin, ist aber für jeden Entwickler im Open-Source-Ökosystem alltagsrelevant. Drei Beispielszenarien aus den letzten 24 Monaten:

xz-utils-Backdoor (CVE-2024-3094, März 2024): Ein Open-Source-Maintainer hatte über zwei Jahre Vertrauen aufgebaut und dann eine Backdoor in das weitverbreitete Komprimierungs-Tool xz-utils eingeschleust. Nahezu jede Linux-Distribution wäre betroffen gewesen. Entdeckt durch Zufall (Performance-Anomalie). Lehre: Tiefe von Dependencies prüfen, nicht nur das direkte Paket.
Lottie-Player NPM-Compromise (Oktober 2024): Phishing-Angriff auf einen Maintainer führte zu kompromittierten Versionen einer Animation-Library, die in Hunderten Frontend-Projekten genutzt wird. Versionen 2.0.5, 2.0.6, 2.0.7 betroffen. Lehre: Lockfile-Verifikation und Dependency-Pinning sind keine Theorie.
Polyfill.io-Übernahme (Juni 2024): Eine seit Jahren genutzte JavaScript-Bibliothek wurde an einen neuen Eigentümer verkauft, der dann Malware-Skripte über das CDN ausspielte. Mehr als 100.000 Websites betroffen. Lehre: CDN-basierte Skripte sind nie wirklich “fertig integriert” — sie müssen kontinuierlich beobachtet werden.

Konkrete Skill-Roadmap mit Zeitaufwand

Wer aus klassischer Entwicklung in Supply-Chain-Security einsteigen will:

Phase 1 (1–3 Monate): Grundlagen — SBOM (Software Bill of Materials), Dependency-Auditing-Tools (npm audit, pip-audit, Snyk, Trivy), Lockfile-Hygiene, signierte Commits.
Phase 2 (3–6 Monate): Spezialisierung — Sigstore/Cosign für Container-Signing, SLSA-Framework (Supply-chain Levels for Software Artifacts), Reproducible Builds, OIDC-Federation in CI/CD.
Phase 3 (6–12 Monate): Praktische Anwendung — eigene Open-Source-Beiträge zu OpenSSF, Mitarbeit an Sicherheitsaudits, Conference-Talks oder Blog-Posts zu konkreten Vorfällen.

Gehaltsmäßig liegen Security-affine Entwicklerrollen laut StepStone und Glassdoor 2024 ca. 15–25 % über klassischen Backend-Entwickler-Rollen — bei vergleichbarer Erfahrung.

Wo der Karrierepfad nicht passt

Bei Aversion gegen kontinuierliches Lernen: Supply-Chain-Security entwickelt sich ständig weiter. Wer “fertig lernen” möchte, ist hier falsch.
Bei reiner Tool-Orientierung: Security ist nicht Tool-Konfiguration, sondern Risikobewertung. Wer nur “Snyk einrichten” lernt, ohne die Bedrohungslandschaft zu verstehen, bringt wenig Mehrwert.
Bei Wunsch nach klaren Routinen: Sicherheit ist reaktiv und unvorhersehbar. Wer planbare Tasks bevorzugt, ist in klassischer Backend-Arbeit glücklicher.