Entwickler-Sicherheitsschulung: Lehrplan und Ressourcen

Entwickler schreiben den Code, den Angreifer ausnutzen. Jede SQL-Injection, jede XSS-Schwachstelle, jeder Authentifizierungs-Bypass existiert, weil ein Entwickler den Code auf diese Weise geschrieben hat. Das ist keine Schuldzuweisung — das ist die Realität. Und die Lösung ist nicht, dass Sicherheitsteams jede Zeile Code überprüfen. Es sind Entwickler, die Sicherheit verstehen und sie von Anfang an einbauen.

Sicherheitsbewusste Entwickler vermeiden nicht nur Schwachstellen. Sie denken wie Angreifer. Sie hinterfragen Annahmen. Sie fragen „was könnte schiefgehen?" bevor sie liefern. Sie bauen Defense in Depth, keine Sicherheit als nachträglichen Gedanken.

Dieser Artikel bietet einen umfassenden Sicherheitsschulungs-Lehrplan für Entwickler: welche Themen abzudecken sind, Lernressourcen für jedes davon und strukturierte Lernpfade vom Junior bis zum Senior Level.

Dreiteilige Serie

Dies ist Teil 1 der Entwickler-Sicherheitsschulungs-Serie:

Lehrplan und Ressourcen (dieser Artikel) — was zu lehren ist
Assessment und Kompetenz-Mapping — wie man Kenntnisse bewertet
Implementierungsleitfaden — wie man das Programm einführt

Warum Entwickler-Sicherheitsschulung wichtig ist

Die Wirtschaftlichkeit ist klar: Das Beheben einer Schwachstelle in der Entwicklung kostet 6-mal weniger als das Beheben in der Produktion. Das Finden während des Designs kostet 15-mal weniger als nach dem Release. Entwickler-Sicherheitswissen ist die kosteneffektivste Sicherheitsinvestition, die Sie tätigen können.

Die meisten Schwachstellen sind vermeidbar. Die OWASP Top 10 hat sich in 20 Jahren kaum verändert. SQL-Injection, XSS, Broken Access Control — wir wissen, dass diese Schwachstellen existieren. Wir wissen, wie man sie verhindert. Dennoch tauchen sie immer wieder in neuem Code auf, weil Entwicklern nicht beigebracht wird, sie zu vermeiden.

Sicherheitsteams können nicht skalieren. Selbst wenn Sie Sicherheitsspezialisten haben, können sie nicht jeden Commit überprüfen. Das Verhältnis von Entwicklern zu Sicherheitsingenieuren liegt typischerweise bei 100:1 oder schlechter. Entwickler müssen die erste Verteidigungslinie sein.

Shift-Left erfordert Entwicklerwissen. DevSecOps bedeutet die Integration von Sicherheit in die Entwicklung. Aber Entwickler können SAST-Befunde nicht beheben, die sie nicht verstehen. Sie können keine Features threat-modeln, die sie bauen, ohne Sicherheitswissen.

Es ist ein Karriere-Differenziator. Entwickler mit Sicherheitskenntnissen sind sehr gefragt. Sicherheitswissen erhöht das Verdienstpotenzial und öffnet Wege zu spezialisierten Rollen (Application Security, Security Engineering).

Sicherheitskompetenz-Framework

Bevor Sie Entwickler schulen, definieren Sie, was „Sicherheitskompetenz" für Ihre Organisation bedeutet. Hier ist ein Framework:

Kompetenzstufen

Stufe	Name	Beschreibung	Erwartet von
L1	Bewusst	Versteht grundlegende Sicherheitskonzepte, erkennt häufige Schwachstellen	Allen Entwicklern
L2	Praktiker	Schreibt konsequent sicheren Code, kann den Code anderer auf Sicherheit reviewen	Senior-Entwicklern
L3	Experte	Entwirft sichere Systeme, betreut andere, leitet Sicherheitsinitiativen	Tech Leads, Architekten
L4	Champion	Fördert Sicherheitskultur, repräsentiert das Team in Sicherheitsdiskussionen	Security Champions

Kompetenzbereiche

Bereich	L1: Bewusst	L2: Praktiker	L3: Experte
Sicheres Coding	Kennt OWASP Top 10	Verhindert Schwachstellen im eigenen Code	Reviewt Code anderer, erstellt Muster
Authentifizierung & Autorisierung	Versteht Konzepte	Implementiert korrekt	Entwirft Auth-Systeme
Datenschutz	Kennt Klassifizierung	Behandelt Daten sicher	Entwirft Datenschutzstrategien
Threat Modeling	Versteht Zweck	Nimmt an Sitzungen teil	Leitet Threat Modeling
Sicherheitstests	Führt bereitgestellte Tools aus	Schreibt Sicherheitstests	Erstellt Teststrategien
Vorfallreaktion	Meldet Probleme	Untersucht und behebt	Leitet Vorfallreaktion
Abhängigkeiten	Aktualisiert auf Anweisung	Überwacht und verwaltet	Erstellt Abhängigkeitsrichtlinien

Rollenbasierte Anforderungen

Rolle	Mindeststufe	Fokusbereiche
Junior-Entwickler	L1	Sichere Coding-Grundlagen, OWASP Top 10
Mid-Level-Entwickler	L1–L2	Sicheres Coding, grundlegende Sicherheitstests
Senior-Entwickler	L2	Alle Bereiche, Code-Review, Mentoring
Tech Lead	L2–L3	Architektur, Threat Modeling, Team-Praktiken
QA-Ingenieur	L1–L2	Sicherheitstests, Schwachstellenverifizierung
DevOps-Ingenieur	L2	Infrastruktursicherheit, CI/CD-Sicherheit
Security Champion	L3–L4	Alle Bereiche, kulturelle Führung

Kernlehrplan für Entwickler

1: Sicherheitsgrundlagen

Dauer: 2–4 Stunden
Zielgruppe: Alle Entwickler (L1)

Themen:

CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit)
Defense in Depth
Least-Privilege-Prinzip
Konzept der Angriffsfläche
Sicherheit vs. Komfort-Kompromisse
Bedrohungslandschaft für Webanwendungen

Lernziele:

Erklären, warum Sicherheit für Entwickler wichtig ist
Häufige Angriffsvektoren identifizieren
Grundlegende Sicherheitsterminologie verstehen
Erkennen, wann man Sicherheitshilfe anfordern sollte

Ressourcen:

Ressource	Typ	Kosten	Link
OWASP Web Security Testing Guide	Leitfaden	Kostenlos	owasp.org/www-project-web-security-testing-guide
PortSwigger Web Security Academy	Interaktiver Kurs	Kostenlos	portswigger.net/web-security
Hack The Box Academy	Praktische Labs	Kostenloser Tarif	academy.hackthebox.com
TryHackMe	Einsteiger-freundliche Labs	Kostenloser Tarif	tryhackme.com

2: OWASP Top 10 im Detail

Dauer: 4–8 Stunden
Zielgruppe: Alle Entwickler (L1–L2)

Die OWASP Top 10 repräsentiert die kritischsten Sicherheitsrisiken für Webanwendungen. Jeder Entwickler sollte diese Schwachstellen genau kennen.

OWASP Top 10 (2021):

#	Schwachstelle	Was es ist	Prävention
A01	Broken Access Control	Nutzer können auf nicht autorisierte Ressourcen zugreifen	Autorisierung bei jeder Anfrage prüfen
A02	Cryptographic Failures	Sensible Daten durch schwache Kryptografie offengelegt	Starke Verschlüsselung, ordentliches Schlüsselmanagement
A03	Injection	Nicht vertrauenswürdige Daten als Code ausgeführt	Parametrisierte Queries, Eingabevalidierung
A04	Insecure Design	Fehler in Architektur/Design	Threat Modeling, sichere Design-Muster
A05	Security Misconfiguration	Standard-Konfigurationen, unnötige Features	Hardening, minimale Berechtigungen
A06	Vulnerable Components	Komponenten mit bekannten Schwachstellen verwenden	SCA-Scanning, Updates
A07	Auth Failures	Gebrochene Authentifizierungsmechanismen	MFA, sicheres Session-Management
A08	Software & Data Integrity Failures	Nicht vertrauenswürdigen Quellen vertrauen	Signaturen verifizieren, Integritätsprüfungen
A09	Security Logging Failures	Unzureichende Protokollierung zur Erkennung	Umfassende Sicherheitsprotokollierung
A10	SSRF	Server macht Anfragen an vom Angreifer kontrollierte Ziele	URLs validieren und bereinigen

Praktische Übungen:

Plattform	Beschreibung	Link
OWASP WebGoat	Absichtlich unsichere App zum Lernen	github.com/WebGoat/WebGoat
OWASP Juice Shop	Moderne verwundbare App	owasp.org/www-project-juice-shop
DVWA	Damn Vulnerable Web Application	github.com/digininja/DVWA
HackTheBox	Verwundbare Maschinen	hackthebox.com
PentesterLab	Geführte Übungen	pentesterlab.com

3: Sicheres Coding nach Programmiersprache

Dauer: 4–6 Stunden pro Sprache
Zielgruppe: Entwickler (L1–L2)

Sicherheitspraktiken unterscheiden sich je nach Sprache und Framework. Bieten Sie sprachspezifische Schulungen für Ihren Stack an.

JavaScript/TypeScript

Schlüsselbereiche:

XSS-Prävention (Output-Encoding, CSP)
Prototype Pollution
npm-Abhängigkeitssicherheit
Sichere Authentifizierung mit JWTs
Server-seitige Anfrage-Validierung
Sicheres JSON-Parsing

Ressourcen:

Ressource	Typ	Link
OWASP Node.js Security Cheat Sheet	Leitfaden	cheatsheetseries.owasp.org
Node.js Security Best Practices	Leitfaden	nodejs.org/en/docs/guides/security
Snyk JavaScript Security	Blog/Lernen	snyk.io/learn/javascript-security
Secure Coding in Node.js	Kurs	pluralsight.com

Beispiel: XSS-Prävention

// BAD: Direct HTML insertion
element.innerHTML = userInput;  // XSS vulnerability

// GOOD: Text content (auto-escapes)
element.textContent = userInput;

// GOOD: DOMPurify for rich content
import DOMPurify from 'dompurify';
element.innerHTML = DOMPurify.sanitize(userInput);

// GOOD: Template literals with encoding
const safe = encodeHTML(userInput);
element.innerHTML = `<div>${safe}</div>`;

Python

Schlüsselbereiche:

SQL-Injection mit ORMs
Command-Injection (subprocess)
Pickle-Deserialisierung
SSTI (Server-Side Template Injection)
Path Traversal
Sichere Passwort-Hashing

Ressourcen:

Ressource	Typ	Link
OWASP Python Security	Leitfaden	cheatsheetseries.owasp.org
Bandit	SAST-Tool	bandit.readthedocs.io
Real Python Security	Tutorials	realpython.com/tutorials/security
Python Security Best Practices	Kurs	pluralsight.com

Beispiel: SQL-Injection-Prävention

# BAD: String formatting (SQL injection)
query = f"SELECT * FROM users WHERE id = {user_id}"
cursor.execute(query)

# GOOD: Parameterized queries
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

# GOOD: ORM usage (SQLAlchemy)
user = session.query(User).filter(User.id == user_id).first()

# GOOD: Django ORM
user = User.objects.get(id=user_id)

Java

Schlüsselbereiche:

SQL-Injection (JDBC, JPA)
XML External Entity (XXE)
Deserialisierungs-Schwachstellen
Spring-Security-Konfiguration
Sichere Protokollierung
Kryptografie mit JCA

Ressourcen:

Ressource	Typ	Link
OWASP Java Security	Leitfaden	cheatsheetseries.owasp.org
Spring Security Reference	Dokumentation	docs.spring.io/spring-security
Find Security Bugs	SAST-Tool	find-sec-bugs.github.io
Secure Coding Guidelines for Java	Oracle-Leitfaden	oracle.com

Go

Schlüsselbereiche:

Eingabevalidierung
SQL-Injection mit database/sql
Path Traversal
Race Conditions
Sichere HTTP-Client-Konfiguration
Kryptografie mit crypto-Paket

Ressourcen:

Ressource	Typ	Link
OWASP Go Security	Leitfaden	cheatsheetseries.owasp.org
Secure Go	Buch	github.com/OWASP/Go-SCP
gosec	SAST-Tool	github.com/securego/gosec

PHP

Schlüsselbereiche:

SQL-Injection (PDO, mysqli)
XSS-Prävention
Datei-Upload-Schwachstellen
Session-Sicherheit
include/require-Schwachstellen
Passwort-Hashing mit password_hash()

Ressourcen:

Ressource	Typ	Link
OWASP PHP Security	Leitfaden	cheatsheetseries.owasp.org
PHP: The Right Way - Security	Leitfaden	phptherightway.com/#security
Psalm	Statischer Analysator	psalm.dev

C# / .NET

Schlüsselbereiche:

SQL-Injection mit Entity Framework
XSS in Razor-Views
Antiforgery-Tokens (CSRF)
Sichere Deserialisierung
Kryptografie mit .NET-APIs
Authentifizierung mit ASP.NET Identity

Ressourcen:

Ressource	Typ	Link
OWASP .NET Security	Leitfaden	cheatsheetseries.owasp.org
ASP.NET Core Security	Dokumentation	docs.microsoft.com/en-us/aspnet/core/security
Security Code Scan	SAST-Tool	security-code-scan.github.io

4: Authentifizierung und Autorisierung

Dauer: 4–6 Stunden
Zielgruppe: Entwickler (L2)

Themen:

Authentifizierung vs. Autorisierung
Session-Management
JWT-Best-Practices und -Fallstricke
OAuth 2.0 und OpenID Connect
Passwort-Speicherung (bcrypt, Argon2)
MFA-Implementierung
API-Authentifizierungsmuster
RBAC und ABAC

Häufige Fehler, die gelehrt werden sollten:

// BAD: JWT in localStorage (XSS can steal it)
localStorage.setItem('token', jwt);

// BETTER: HttpOnly cookie (not accessible via JavaScript)
// Set via response header:
// Set-Cookie: token=jwt; HttpOnly; Secure; SameSite=Strict

// BAD: Checking JWT signature but not expiration
const decoded = jwt.verify(token, secret);
// Token could be expired!

// GOOD: Verify all claims
const decoded = jwt.verify(token, secret, {
  algorithms: ['HS256'],
  maxAge: '1h',
  issuer: 'your-app'
});

Ressourcen:

Ressource	Typ	Link
OWASP Authentication Cheat Sheet	Leitfaden	cheatsheetseries.owasp.org
OAuth 2.0 Simplified	Buch	oauth.com
Auth0 Blog	Artikel	auth0.com/blog
JWT.io	Lernen	jwt.io/introduction

5: Sicherheitstests für Entwickler

Dauer: 4–6 Stunden
Zielgruppe: Entwickler und QA (L2)

Entwickler sollten Sicherheitstests schreiben, nicht nur auf Sicherheitsteams vertrauen.

Arten von Sicherheitstests:

Typ	Was er testet	Wann einsetzen	Tools
Unit-Tests für Sicherheit	Individuelle Sicherheitsfunktionen	Bei jedem Commit	Jest, pytest, JUnit
Integrations-Sicherheitstests	Auth-Flows, Zugriffskontrolle	Bei jedem PR	Supertest, requests
SAST	Quellcode-Muster	CI/CD	Semgrep, CodeQL, Bandit
DAST	Laufende Anwendung	Staging	OWASP ZAP, Nuclei
Abhängigkeits-Scanning	Bekannte CVEs in Bibliotheken	Bei jedem Build	Snyk, Dependabot
Fuzz-Testing	Randfälle, Abstürze	Regelmäßig	AFL, libFuzzer

Sicherheitstests schreiben:

// Authentication tests
describe('Authentication', () => {
  test('should reject invalid credentials', async () => {
    const res = await request(app)
      .post('/api/login')
      .send({ username: 'user', password: 'wrong' });
    expect(res.status).toBe(401);
  });

  test('should not leak user existence via timing', async () => {
    const start1 = Date.now();
    await request(app).post('/api/login').send({ username: 'exists', password: 'wrong' });
    const time1 = Date.now() - start1;

    const start2 = Date.now();
    await request(app).post('/api/login').send({ username: 'nonexistent', password: 'wrong' });
    const time2 = Date.now() - start2;

    // Response times should be similar
    expect(Math.abs(time1 - time2)).toBeLessThan(50);
  });
});

// Authorization tests
describe('Authorization', () => {
  test('should deny access to other users resources', async () => {
    const user1Token = await login('user1', 'password1');
    const res = await request(app)
      .get('/api/users/user2/data')
      .set('Authorization', `Bearer ${user1Token}`);
    expect(res.status).toBe(403);
  });
});

// Input validation tests
describe('Input Validation', () => {
  test('should reject SQL injection attempts', async () => {
    const res = await request(app)
      .get('/api/users')
      .query({ id: "1' OR '1'='1" });
    expect(res.status).toBe(400);
  });

  test('should reject XSS in user input', async () => {
    const res = await request(app)
      .post('/api/comments')
      .send({ text: '<script>alert("xss")</script>' });
    // Either reject or sanitize
    expect(res.body.text).not.toContain('<script>');
  });
});

Ressourcen:

Ressource	Typ	Link
OWASP Testing Guide	Umfassender Leitfaden	owasp.org/www-project-web-security-testing-guide
BDD Security	Framework	github.com/iriusrisk/bdd-security
OWASP ZAP	DAST-Tool	zaproxy.org
Nuclei	Template-basierter Scanner	nuclei.projectdiscovery.io

6: Threat Modeling

Dauer: 2–4 Stunden
Zielgruppe: Senior-Entwickler, Tech Leads (L2–L3)

Threat Modeling identifiziert Sicherheitsprobleme während des Designs, bevor Code geschrieben wird.

STRIDE-Modell:

Bedrohung	Beschreibung	Beispiel	Mitigation
Spoofing	Als jemand anderes ausgeben	Gestohlene Anmeldedaten	Starke Authentifizierung, MFA
Tampering	Daten modifizieren	Preise im Warenkorb ändern	Integritätsprüfungen, Signaturen
Repudiation	Aktionen verleugnen	„Ich habe diesen Kauf nicht getätigt"	Audit-Protokollierung
Information Disclosure	Datenoffenlegung	Datenbank-Dump	Verschlüsselung, Zugriffskontrolle
Denial of Service	System unverfügbar machen	DDoS-Angriff	Rate Limiting, Skalierung
Elevation of Privilege	Unautorisierten Zugang erlangen	Admin-Zugang ohne Admin zu sein	Least Privilege, RBAC

Einfacher Threat-Modeling-Prozess:

Was bauen wir? Ein Datenflussdiagramm zeichnen. Komponenten, Datenspeicher und Vertrauensgrenzen identifizieren.
Was kann schiefgehen? STRIDE auf jede Komponente anwenden. Angriffsszenarien brainstormen.
Was werden wir dagegen tun? Bedrohungen priorisieren (Wahrscheinlichkeit × Auswirkung). Mitigationen definieren. Sicherheitsanforderungen erstellen.
Haben wir gute Arbeit geleistet? Modellvollständigkeit überprüfen. Verifizieren, dass Mitigationen implementiert sind. Das Modell aktualisieren, wenn sich das Design ändert.

Ressourcen:

Ressource	Typ	Link
OWASP Threat Modeling	Leitfaden	owasp.org/www-community/Threat_Modeling
Microsoft Threat Modeling Tool	Tool	microsoft.com/en-us/securityengineering/sdl/threatmodeling
Threat Modeling: Designing for Security	Buch	Adam Shostack
OWASP Threat Dragon	Open-Source-Tool	owasp.org/www-project-threat-dragon

Sicherheitsschulung für QA-Ingenieure

QA-Ingenieure sind Kraft-Multiplikatoren für Sicherheit. Sie denken bereits über Randfälle und das Kaputtmachen von Dingen nach — Sicherheitstests sind eine natürliche Erweiterung.

Sicherheitstest-Lehrplan für QA

Modul	Themen	Dauer
Grundlagen der Sicherheitstests	Schwachstellentypen, OWASP Top 10, Test-Mindset	4 Stunden
Manuelle Sicherheitstests	Burp-Suite-Grundlagen, Anfragen abfangen, Auth testen	8 Stunden
Automatisierte Sicherheitstests	OWASP ZAP, Nuclei, CI-Integration	4 Stunden
API-Sicherheitstests	API-Schwachstellen, Postman-Sicherheitstests, Fuzzing	4 Stunden
Schwachstellen melden	Gute Bug-Reports schreiben, Schweregradeinschätzung	2 Stunden

Tools für QA-Sicherheitstests

Tool	Zweck	Lernkurve	Link
Burp Suite Community	Web-Proxy, manuelle Tests	Mittel	portswigger.net/burp
OWASP ZAP	Web-Scanner, kostenlose Burp-Alternative	Mittel	zaproxy.org
Postman	API-Tests mit Sicherheitstests	Gering	postman.com
Nuclei	Template-basiertes Scanning	Gering	nuclei.projectdiscovery.io
Browser-DevTools	Anfragen-Inspektion, Cookie-Analyse	Gering	Eingebaut

QA-Sicherheitstest-Checkliste

## QA Security Testing Checklist

### Authentication
- [ ] Test with invalid credentials
- [ ] Test account lockout after failed attempts
- [ ] Test password reset flow for account enumeration
- [ ] Test session timeout
- [ ] Test concurrent session handling
- [ ] Test remember me functionality

### Authorization
- [ ] Test accessing other users' data (IDOR)
- [ ] Test role-based access (can user access admin?)
- [ ] Test function-level access control
- [ ] Test after logout (can cached pages be accessed?)

### Input validation
- [ ] Test with SQL injection payloads
- [ ] Test with XSS payloads
- [ ] Test with special characters
- [ ] Test with very long inputs
- [ ] Test with empty/null inputs
- [ ] Test with unexpected data types

### Business logic
- [ ] Test race conditions (submit twice quickly)
- [ ] Test workflow bypass (skip steps)
- [ ] Test negative values (negative quantity, negative price)
- [ ] Test integer overflow

### Files
- [ ] Test uploading executable files
- [ ] Test uploading oversized files
- [ ] Test path traversal in filenames
- [ ] Test accessing files without authorization

### API specific
- [ ] Test with missing authentication
- [ ] Test with tampered tokens
- [ ] Test rate limiting
- [ ] Test for mass assignment
- [ ] Test for excessive data exposure

Burp-Suite-Grundlagen für QA

Setup: Proxy konfigurieren (127.0.0.1:8080), Burp-CA-Zertifikat im Browser installieren, Anwendung durchsuchen — Burp erfasst den gesamten Traffic.

Wichtige Tabs:

Proxy → HTTP history — alle Anfragen sehen
Repeater — einzelne Anfragen ändern und erneut senden
Intruder — automatisiertes Payload-Testen
Scanner — automatisiertes Schwachstellen-Scanning (nur Pro)

Häufige Tests: user_id in URL ändern (IDOR) · JSON-Body ändern (Autorisierung) · Auth-Header entfernen (Auth-Anforderungen) · Payloads injizieren (Eingabevalidierung)

Umfassende Lernpfade

Junior-Entwickler-Pfad (0–2 Jahre)

Monate 1–3: Grundlagen

Kurs zu Sicherheitsgrundlagen
OWASP-Top-10-Schulung
Sprachspezifische sichere Coding-Grundlagen
Assessment: Sicherheitsquiz (80 % bestehen)

Monate 4–6: Praktische Fähigkeiten

PortSwigger Web Security Academy (Grundlagen) abschließen
Auf WebGoat üben
Erste Sicherheits-Unit-Tests schreiben
Assessment: 3 Schwachstellen in Test-App finden

Monate 7–12: Integration

Sicheres Coding im täglichen Arbeitsablauf anwenden
An Sicherheits-Code-Reviews teilnehmen
An CTF-Event teilnehmen
Assessment: Sicherer Code-Review-Übung

Ziel am Jahresende: L1-Kompetenz in allen Bereichen

Mid-Level-Entwickler-Pfad (2–5 Jahre)

Quartal 1:

Fortgeschrittene OWASP-Schulung
Authentifizierung und Autorisierung im Detail
Assessment: Mittleres Sicherheitsquiz

Quartal 2:

Sicherheitstests mit Burp Suite
API-Sicherheit
Assessment: Schwachstellen mit Burp finden

Quartal 3:

Einführung in Threat Modeling
An Threat-Modeling-Sitzung teilnehmen
Assessment: Threat Model für ein kleines Feature leiten

Quartal 4:

Junior-Entwickler betreuen
Zur Sicherheitsdokumentation beitragen
Assessment: Code-Review mit Sicherheitsfokus

Ziel am Jahresende: L2-Kompetenz, bereit für Security-Champion-Rolle

Senior-Entwickler-/Tech-Lead-Pfad

Fokusbereiche:

Architektur-Sicherheit
Threat-Modeling-Sitzungen leiten
Sicherheitsanforderungen für neue Projekte
Andere betreuen
Sicherheitsvorfallreaktion

Aktivitäten:

Threat-Modeling-Kurs abschließen
3+ Threat-Modeling-Sitzungen leiten
Sicherheitsarchitektur für neue Projekte reviewen
Internen Tech-Talk zu Sicherheitsthema präsentieren
An Vorfallreaktions-Übung teilnehmen

Ziel: L3-Kompetenz, Security Champion oder Zusammenarbeit mit Sicherheitsteam

Selbstcheck-Fragen

Was sind die vier Stufen im Sicherheitskompetenz-Framework?
Welche OWASP-Top-10-Schwachstelle beinhaltet die Ausführung nicht vertrauenswürdiger Daten als Code?
Warum ist eine parametrisierte Query sicherer als String-Interpolation für SQL?
Was ist der Unterschied zwischen SAST und DAST?
Wofür steht STRIDE?
Warum sollten QA-Ingenieure Sicherheitstests lernen?

Links und Ressourcen

Kurse und Schulungen

Ressource	Typ	Kosten	Link
PortSwigger Web Security Academy	Interaktiv	Kostenlos	portswigger.net/web-security
OWASP WebGoat	Praktisch	Kostenlos	owasp.org/www-project-webgoat
Hack The Box Academy	Labs	Kostenloser Tarif	academy.hackthebox.com
TryHackMe	Einsteiger-Labs	Kostenloser Tarif	tryhackme.com
PentesterLab	Übungen	20 $/Monat	pentesterlab.com
SANS Secure Coding	Zertifizierung	Kostenpflichtig	sans.org

Cheat-Sheets und Leitfäden

OWASP Cheat Sheet Series — Umfassende Leitfäden für sicheres Coding
OWASP Testing Guide — Sicherheitstest-Methodik
CWE Top 25 — Gefährlichste Software-Schwächen

SAST-Tools nach Sprache

Sprache	Tool	Link
Multi-Sprache	Semgrep	semgrep.dev
Multi-Sprache	CodeQL	codeql.github.com
Python	Bandit	bandit.readthedocs.io
JavaScript	ESLint-Sicherheits-Plugins	github.com/eslint-community/eslint-plugin-security
Java	Find Security Bugs	find-sec-bugs.github.io
Go	gosec	github.com/securego/gosec
C#	Security Code Scan	security-code-scan.github.io

Verwundbare Anwendungen zum Üben

CTF-Plattformen

CTFd — Eigenen CTF hosten
PicoCTF — Einsteiger-freundlich
CTFtime — CTF-Event-Kalender

Fazit

Ein Lehrplan, der nicht zu dem passt, was Ihre Entwickler tatsächlich bauen, ist verschwendete Mühe. Beginnen Sie mit dem, was Sie kennen — Ihren Stack, Ihre Schwachstellen, Ihre Vorfälle — und bauen Sie von dort aus auf.

Das Ziel ist nicht, jeden Entwickler zu einem Sicherheitsexperten zu machen. Es geht darum, sie kompetent genug zu machen, dass sie nicht zweimal dieselben Kategorien von Bugs einführen.

Was kommt als nächstes

Weiter: Assessment und Kompetenz-Mapping — wie man bewertet, wo Ihre Entwickler stehen, bevor Sie mit der Schulung beginnen.

Warum Entwickler-Sicherheitsschulung wichtig ist​

Sicherheitskompetenz-Framework​

Kompetenzstufen​

Kompetenzbereiche​

Rollenbasierte Anforderungen​

Kernlehrplan für Entwickler​

1: Sicherheitsgrundlagen​

2: OWASP Top 10 im Detail​

3: Sicheres Coding nach Programmiersprache​

JavaScript/TypeScript​

Python​

Java​

Go​

PHP​

C# / .NET​

4: Authentifizierung und Autorisierung​

5: Sicherheitstests für Entwickler​

6: Threat Modeling​

Sicherheitsschulung für QA-Ingenieure​

Sicherheitstest-Lehrplan für QA​

Tools für QA-Sicherheitstests​

QA-Sicherheitstest-Checkliste​

Burp-Suite-Grundlagen für QA​

Umfassende Lernpfade​

Junior-Entwickler-Pfad (0–2 Jahre)​

Mid-Level-Entwickler-Pfad (2–5 Jahre)​

Senior-Entwickler-/Tech-Lead-Pfad​

Selbstcheck-Fragen​

Links und Ressourcen​

Kurse und Schulungen​

Cheat-Sheets und Leitfäden​

SAST-Tools nach Sprache​

Verwundbare Anwendungen zum Üben​

CTF-Plattformen​

Fazit​

Was kommt als nächstes​

Warum Entwickler-Sicherheitsschulung wichtig ist

Sicherheitskompetenz-Framework

Kompetenzstufen

Kompetenzbereiche

Rollenbasierte Anforderungen

Kernlehrplan für Entwickler

1: Sicherheitsgrundlagen

2: OWASP Top 10 im Detail

3: Sicheres Coding nach Programmiersprache

JavaScript/TypeScript

Python

Java

Go

PHP

C# / .NET

4: Authentifizierung und Autorisierung

5: Sicherheitstests für Entwickler

6: Threat Modeling

Sicherheitsschulung für QA-Ingenieure

Sicherheitstest-Lehrplan für QA

Tools für QA-Sicherheitstests

QA-Sicherheitstest-Checkliste

Burp-Suite-Grundlagen für QA

Umfassende Lernpfade

Junior-Entwickler-Pfad (0–2 Jahre)

Mid-Level-Entwickler-Pfad (2–5 Jahre)

Senior-Entwickler-/Tech-Lead-Pfad

Selbstcheck-Fragen

Links und Ressourcen

Kurse und Schulungen

Cheat-Sheets und Leitfäden

SAST-Tools nach Sprache

Verwundbare Anwendungen zum Üben

CTF-Plattformen

Fazit

Was kommt als nächstes