Security Champion in der Entwicklung und DevOps
In Modul 2 haben Sie Quick Wins umgesetzt — Passwortmanager, MFA, E-Mail-Sicherheit. Diese schützen den Perimeter. In Modul 3 geht es darum, das zu schützen, was Sie entwickeln.
Die meisten Sicherheitsschwachstellen entstehen im Code. SQL-Injection, XSS, fehlerhafte Authentifizierung, unsichere API-Endpunkte — das sind keine Konfigurationsfehler, sondern Entwicklungsfehler. Und sie kommen extrem häufig vor, weil Entwickler keine Sicherheitsausbildung erhalten, Sicherheitsteams die Entwicklung nicht verstehen und beide Gruppen selten miteinander kommunizieren.
Der Security Champion überbrückt diese Lücke. Sie sind Entwickler (oder DevOps-Ingenieur) und verstehen beide Welten. Sie können Code auf Sicherheitsprobleme prüfen, erklären, warum bestimmte Praktiken wichtig sind, und Sicherheitsprüfungen in den Entwicklungsprozess integrieren, ohne alles zu verlangsamen.
Dieses Kapitel definiert Ihre Rolle im Entwicklungsprozess: wo Sie stehen, was Sie tun und wie Sie effektiv mit Ihrem Team zusammenarbeiten.
Warum die Entwicklung einen Security Champion braucht
Das Problem der Trennung
Klassische Sicherheit funktioniert so:
- Entwickler bauen Features
- Das Sicherheitsteam prüft am Ende (oder gar nicht)
- Die Sicherheit findet Probleme
- Entwickler müssen zurückgehen und Dinge reparieren
- Alle sind frustriert
Das scheitert aus mehreren Gründen:
Timing: Wenn Sicherheitsprüfungen stattfinden, ist das Feature fertig. Korrekturen sind teuer. Deadlines werden verpasst. Der Druck, trotzdem zu liefern, steigt.
Wissen: Sicherheitsteams kennen die Codebasis nicht. Sie melden Probleme, ohne den Kontext zu verstehen. Entwickler verstehen Sicherheit nicht. Sie wischen Befunde als theoretisch beiseite.
Kommunikation: Sicherheit spricht in CVEs und OWASP-Kategorien. Entwickler sprechen in Funktionen und Pull Requests. Keine Seite übersetzt gut.
Skalierung: Ein Sicherheitsteam aus zwei Personen kann nicht den Code von 50 Entwicklern prüfen. Der größte Teil des Codes wird ohne jede Sicherheitsprüfung ausgeliefert.
Die Lösung mit dem Security Champion
Sie sind in das Entwicklungsteam eingebettet. Sie schreiben Code. Sie verstehen die Architektur. Sie wissen, welche Teile unter Zeitdruck entstanden sind und welche solide sind. Sie nehmen an Standups teil und sehen, was gebaut wird.
Das bedeutet:
- Sicherheitseingaben finden während des Designs statt, nicht danach
- Sie können erklären, warum etwas riskant ist, nicht nur dass es riskant ist
- Entwickler vertrauen Ihnen, weil Sie einer von ihnen sind
- Sie können nach tatsächlichem Risiko priorisieren, nicht nach theoretischen Bedenken
Sie ersetzen kein Sicherheitsteam. Sie erweitern die Sicherheit in die tägliche Entwicklungsarbeit.
Wo Sie im Entwicklungsprozess stehen
Das Shift-Left-Modell
„Shift Left" bedeutet, Sicherheit früher in den Entwicklungsprozess zu verlagern. Je früher (weiter links), desto günstiger und einfacher sind Korrekturen.
Traditional:
Design → Develop → Test → Deploy → Security Review → Fix
↑
(expensive fixes)
Shift-left:
Design → Develop → Test → Deploy
↓ ↓ ↓ ↓
Security Security SAST Security
input review DAST config
↑
(cheap fixes)
Ihre Berührungspunkte im SDLC
1. Planung und Design
Hier haben Sie den größten Einfluss mit dem geringsten Aufwand.
- Nehmen Sie an Feature-Planungsmeetings teil
- Überprüfen Sie technische Designs auf Sicherheitsauswirkungen
- Identifizieren Sie, welche ASVS-Anforderungen für neue Features gelten
- Markieren Sie Features, die ein Threat Modeling benötigen
- Fügen Sie Sicherheits-Akzeptanzkriterien zu Tickets hinzu
Was Sie tun:
- „Dieses Feature verwaltet Datei-Uploads von Benutzern — wir brauchen die V12-Anforderungen"
- „Wenn wir Kreditkarten speichern, müssen wir den PCI-Scope besprechen"
- „Diese API wird öffentlich sein, planen wir Rate Limiting und Authentifizierung"
2. Entwicklung
Seien Sie erreichbar, ohne zum Flaschenhals zu werden.
- Beantworten Sie Sicherheitsfragen von Entwicklern
- Überprüfen Sie sicherheitsrelevante Code-Änderungen
- Arbeiten Sie gemeinsam an komplexen Sicherheitsimplementierungen
- Pflegen Sie Richtlinien für sicheres Programmieren
- Erstellen Sie eine Bibliothek mit sicheren Code-Mustern
Was Sie tun:
- „Hier ist die Implementierung von CSRF-Tokens in unserem Framework"
- „Ich prüfe den Authentifizierungsablauf, bevor Sie mergen"
- „Lassen Sie mich zeigen, wie der bestehende Code Eingabevalidierung behandelt"
3. Code-Review
Nicht jeder PR braucht Ihre Prüfung. Konzentrieren Sie sich auf Hochrisikobereiche.
- Authentifizierung und Sitzungsverwaltung
- Autorisierung und Zugriffskontrolle
- Dateivalidierung und Ausgabekodierung
- Kryptografische Operationen
- Konfigurationsänderungen (besonders Secrets)
- Neue Abhängigkeiten
Was Sie tun:
- Fügen Sie sich als erforderlichen Reviewer für authentifizierungsbezogene Pfade hinzu
- Erstellen Sie eine Checkliste für sicherheitsrelevante Code-Reviews
- Überprüfen Sie PRs, die sensible Bereiche berühren
- Geben Sie Feedback, das aufklärt, nicht nur blockiert
4. Testing
Integrieren Sie Sicherheit in bestehende Testprozesse.
- Schreiben Sie Sicherheitstestfälle
- Konfigurieren und pflegen Sie SAST/DAST-Tools
- Überprüfen Sie Tool-Ergebnisse und sortieren Sie Falsch-Positive aus
- Verifizieren Sie, dass Sicherheitsanforderungen getestet werden
Was Sie tun:
- „Lassen Sie uns einen Test hinzufügen, der verifiziert, dass Benutzer nicht auf Daten anderer Benutzer zugreifen können"
- „Ich richte Semgrep ein, um bei jedem PR zu laufen"
- „Dieser SAST-Befund ist ein Falsch-Positiv — hier ist der Grund"
5. Deployment
Sicherheit hört nicht auf, wenn der Code ausgeliefert wird.
- Überprüfen Sie Deployment-Konfigurationen
- Verifizieren Sie Sicherheits-Header und TLS
- Prüfen Sie auf exponierte Secrets oder Debug-Endpunkte
- Überwachen Sie sicherheitsrelevante Fehler
Was Sie tun:
- „Stellen wir sicher, dass Staging dieselbe Sicherheitskonfiguration wie die Produktion hat"
- „Ich verifiziere, dass der CSP-Header nach dem Deployment korrekt gesetzt ist"
- „Diese Fehlerprotokolle zeigen Authentifizierungsfehler — lassen Sie mich das untersuchen"
Zusammenarbeit mit Entwicklern
Vertrauen aufbauen
Entwickler haben Sicherheit schlecht umgesetzt gesehen. Sie erwarten, dass Sie ihre Arbeit mit theoretischen Bedenken blockieren. Beweisen Sie das Gegenteil.
Hilfreich sein, nicht nur kritisch:
- Sagen Sie nicht einfach „Das ist unsicher"
- Sagen Sie „Das ist anfällig für X, weil Y, so beheben Sie es"
- Noch besser: „Hier ist ein PR, der es behebt"
Einschränkungen verstehen:
- Deadlines sind real
- Technische Schulden existieren
- Nicht alles kann sofort behoben werden
Prioritäten setzen:
- Kritische Probleme: Release blockieren
- Mittlere Probleme: im nächsten Sprint beheben
- Geringe Probleme: für später vormerken
Das Warum erklären:
- Sagen Sie nicht „weil OWASP es so sagt"
- Sagen Sie „hier ist, was ein Angreifer tun könnte, hier ist ein echtes Beispiel"
Erreichbar sein:
- Fragen schnell beantworten
- Gemeinsam an Sicherheitsimplementierungen arbeiten
- Menschen nicht auf Sie warten lassen
Sicherheitsprobleme kommunizieren
Schlechte Kommunikation:
„Dieser Code ist anfällig für SQL-Injection. OWASP A03. Beheben Sie es."
Das sagt Entwicklern nichts Nützliches. Es klingt, als würden Sie Kästchen abhaken.
Gute Kommunikation:
„Die Benutzereingabe in Zeile 45 wird direkt in die SQL-Abfrage eingefügt. Ein Angreifer könnte
'; DROP TABLE users; --eingeben und die Benutzertabelle löschen. So verhindern parametrisierte Abfragen das. Soll ich zeigen, wie unser ORM das sicher behandelt?"
Das erklärt das Risiko, zeigt die Auswirkungen und bietet Hilfe an.
Sicherheits-Sprechstunden
Richten Sie eine regelmäßige Zeit ein, in der Entwickler Sicherheitsfragen stellen können:
- 30–60 Minuten, jede Woche zur gleichen Zeit
- Drop-in-Format — kein Termin erforderlich
- Fragen können zur aktuellen Arbeit oder allgemeiner Neugier gehören
- Keine Frage ist zu einfach
Das schafft eine entspannte Möglichkeit, Sicherheit zu besprechen, ohne formale Prüfprozesse.
Security Champions in jedem Team (Skalierung)
In größeren Organisationen können Sie weitere Security Champions in jedem Team ausbilden:
Das Hub-and-Spoke-Modell:
┌──────────┐
│ You │
│ (Lead SC)│
└────┬─────┘
│
┌───────────┼───────────┐
│ │ │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│ SC in │ │ SC in │ │ SC in │
│ Team A│ │ Team B│ │ Team C│
└───────┘ └───────┘ └───────┘
Jedes Team hat jemanden, der:
- Alltägliche Sicherheitsfragen bearbeitet
- Code-Reviews im ersten Durchlauf durchführt
- Komplexe Probleme an Sie eskaliert
- Am monatlichen Security-Champion-Sync teilnimmt
Das skaliert Sicherheit über mehrere Teams hinweg, ohne dediziertes Sicherheitspersonal einstellen zu müssen.
Zusammenarbeit mit DevOps
DevOps kontrolliert die Pipeline und die Infrastruktur. Sie sind kritische Partner.
Was DevOps wichtig ist
- Zuverlässigkeit: Wird diese Sicherheitsänderung die Produktion beeinträchtigen?
- Geschwindigkeit: Wird das Deployments verlangsamen?
- Einfachheit: Ist das ein weiteres Tool, das gepflegt werden muss?
- Sichtbarkeit: Können wir sehen, was passiert?
Rahmen Sie Sicherheit in diesen Begriffen.
Häufige Kooperationsbereiche
CI/CD-Sicherheitsscans:
Sie möchten Sicherheitsprüfungen in der Pipeline. DevOps kontrolliert die Pipeline.
Ihr Ansatz:
- Beginnen Sie mit nicht-blockierenden Scans (nur Bericht)
- Beweisen Sie, dass das Tool funktioniert und die Falsch-Positiv-Rate niedrig ist
- Diskutieren Sie dann das Blockieren bei kritischen Befunden
- Bieten Sie an, Befunde zu triagieren und Rauschen zu reduzieren
Beispieldialog:
„Ich möchte Trivy hinzufügen, um unsere Docker-Images zu scannen. Es läuft in etwa 30 Sekunden. Können wir es zuerst als Reporting-Schritt hinzufügen? Ich werde die Ergebnisse einige Wochen überprüfen und dann können wir entscheiden, ob wir bei kritischen CVEs blockieren."
Secrets-Verwaltung:
Sie möchten Secrets aus dem Code. DevOps verwaltet die Infrastruktur.
Ihr Ansatz:
- Verstehen Sie die aktuelle Secret-Handhabung
- Schlagen Sie Lösungen vor, die in ihren Workflow passen
- Helfen Sie bei der Migration
Beispieldialog:
„Mir ist aufgefallen, dass wir einige API-Schlüssel in Environment-Dateien haben. Ich mache mir Sorgen um Rotation und Zugriffskontrolle. Sie nutzen bereits AWS — was wäre, wenn wir diese in den Secrets Manager verschieben? Ich kann helfen, den Anwendungscode zu aktualisieren, damit er von dort bezieht."
Infrastruktursicherheit:
Sie möchten eine sichere Cloud-Konfiguration. DevOps baut und pflegt sie.
Ihr Ansatz:
- Nicht prüfen und ihnen dann Befunde aufzwingen
- Anbieten, Sicherheitsscans gemeinsam durchzuführen
- Befunde nach tatsächlichem Risiko priorisieren
- Beim Beheben helfen, nicht nur beim Finden
Beispieldialog:
„Ich habe Prowler gegen unser AWS-Konto ausgeführt und ein paar Dinge gefunden. Die meisten sind in Ordnung, aber es gibt zwei S3-Buckets, die möglicherweise zu offen sind. Können wir uns das gemeinsam ansehen? Ich möchte sichergehen, dass ich das beabsichtigte Zugriffsmuster verstehe."
Eine Sicherheits-DevOps-Beziehung aufbauen
Ihre Tools erlernen:
- Die CI/CD-Pipeline verstehen
- Die Infrastruktur kennen (AWS/GCP/Azure)
- Grundlegendes Terraform/Kubernetes lernen
An ihren Meetings teilnehmen:
- Incident-Reviews
- Infrastrukturplanung
- Tool-Evaluierungen
Nützliche Informationen teilen:
- Neue Schwachstellen in Tools, die sie nutzen
- Sicherheitsfunktionen in Plattformen, die sie verwalten
- Branchenvorfälle, die für ihre Arbeit relevant sind
Die Brücke zur Entwicklung sein:
- Entwickleranforderungen in Infrastrukturanforderungen übersetzen
- Erklären, warum bestimmte Konfigurationen für die Anwendungssicherheit wichtig sind
Ihr wöchentlicher Rhythmus
So könnte die Entwicklungsarbeit eines Security Champions aussehen:
Täglich
- Ausgaben von Sicherheits-Tools prüfen (SAST, Dependency-Scans)
- Für schnelle Fragen erreichbar sein
- Sicherheitsrelevante PRs überprüfen
- Sicherheitsbezogene Protokolle/Alarme überwachen
Wöchentlich
- An 1–2 Planungsmeetings für neue Features teilnehmen
- Sicherheits-Sprechstunden (30–60 Min.)
- Neue Abhängigkeiten prüfen, die zu Projekten hinzugefügt wurden
- Neue Sicherheitsbefunde triagieren
Monatlich
- Abdeckung der Sicherheitsanforderungen überprüfen
- Richtlinien für sicheres Programmieren aktualisieren
- Sicherheits-Sync mit DevOps
- Schulungssitzung oder Brown-Bag-Lunch
Quartalsweise
- Vollständige Überprüfung der Sicherheitsanforderungs-Baseline
- Bedrohungsmodelle für wichtige Features aktualisieren
- Sicherheits-Tooling überprüfen und aktualisieren
- Sicherheitsmetriken an die Führung berichten
Tools, die Sie verwenden werden
Entwicklungssicherheits-Tools
| Tool | Zweck | Wann |
|---|---|---|
| Semgrep | SAST (statische Analyse) | Bei jedem PR |
| Snyk | Dependency-Scanning | Bei jedem Build |
| Gitleaks | Secret-Erkennung | Bei jedem Commit |
| Trivy | Container-Scanning | Bei jedem Image-Build |
| OWASP ZAP | DAST (dynamisches Testing) | Bei Staging-Deployments |
| Checkov | IaC-Scanning | Bei jeder Terraform-Änderung |
Kommunikation und Tracking
| Tool | Zweck |
|---|---|
| Slack/Teams-Kanäle | Schnelle Fragen, Alarme |
| Jira/Linear | Verfolgung von Sicherheitsanforderungen |
| Confluence/Notion | Sicherheitsrichtlinien, Runbooks |
| GitHub/GitLab | Code-Review, PR-Kommentare |
Ihr Sicherheits-Dashboard
Richten Sie Sichtbarkeit in den Sicherheitsstatus ein:
## Security Champion Dashboard
### This week
- [ ] PRs reviewed: X
- [ ] Security questions answered: X
- [ ] Planning meetings attended: X
- [ ] Tool findings triaged: X
### Metrics
- Open critical security issues: X
- Average time to resolve critical: X days
- SAST findings this month: X (Y false positives)
- Dependencies with known vulns: X
### Upcoming
- Feature X design review: [Date]
- Security office hours: [Day/Time]
- DevOps security sync: [Date]
Häufige Herausforderungen
„Wir haben keine Zeit für Sicherheit"
Das passiert, wenn Sicherheit als Zusatzaufwand wahrgenommen wird.
Ihre Antwort:
- Sicherheit früher einbetten, damit es keine Last-Minute-Arbeit ist
- Automatisieren, was möglich ist (SAST, Dependency-Scans)
- Auf wirkungsstarke, aufwandsarme Gewinne konzentrieren
- Zeigen, wie spät gefundene Sicherheitsprobleme mehr Zeit kosten
„Sie verlangsamen uns"
Das passiert, wenn Sicherheit Releases blockiert.
Ihre Antwort:
- Nicht-kritische Befunde nicht-blockierend machen
- Schnell in Ihren Reviews sein
- Korrekturvorschläge machen, nicht nur Befunde liefern
- Blockieren für wirklich kritische Probleme reservieren
„Das ist kein echtes Risiko"
Das passiert, wenn Entwickler Befunde ablehnen.
Ihre Antwort:
- Reale Beispiele von Ausnutzung zeigen
- Angreifer-Methodik erklären
- Die Schwachstelle wenn möglich demonstrieren
- Akzeptieren, dass Sie manchmal überstimmt werden — dokumentieren und weitermachen
„Wir haben bereits ein Sicherheitsteam"
Das passiert in Unternehmen mit dediziertem Sicherheitspersonal.
Ihre Antwort:
- Sie erweitern ihre Reichweite, ersetzen sie nicht
- Sie kümmern sich um den Alltag, sie kümmern sich um Spezialarbeiten
- Sie sind der Übersetzer zwischen Sicherheit und Entwicklung
- Sie können sich auf Incident Response, Pentests, Architektur konzentrieren
Ihren Einfluss messen
Verfolgen Sie diese Metriken, um Ihren Wert zu demonstrieren:
Prozessmetriken:
- Abdeckung der Sicherheitsanforderungen für neue Features
- Zeit vom Sicherheitsbefund bis zur Behebung
- Prozentsatz der PRs mit Sicherheitsprüfung
- Entwicklerbeteiligung an Sicherheitsschulungen
Ergebnismetriken:
- Schwachstellen in der Entwicklung vs. Produktion gefunden
- Sicherheitsbezogene Produktionsvorfälle
- Befunde aus externen Pentests (weniger ist besser)
- Antwortzeit bei Sicherheitsfragebögen von Kunden
Engagement-Metriken:
- In Sicherheits-Sprechstunden gestellte Fragen
- Entwickler, die freiwillig Sicherheitstests hinzufügen
- Sicherheit, die in Planungsmeetings ohne Sie besprochen wird
Selbstcheck
Bevor Sie sich in die Grundlagen des sicheren Programmierens vertiefen, vergewissern Sie sich, dass Sie Ihre Rolle verstehen:
Team-Integration
- Sie nehmen an Feature-Planungsmeetings teil
- Entwickler wissen, Sie bei sicherheitsrelevanten PRs einzubeziehen
- Sie haben Zugang zur Codebasis und CI/CD
- DevOps kennt Sie und Ihre Rolle
Kommunikation
- Sicherheits-Sprechstunden geplant
- Slack/Teams-Kanal für Sicherheitsfragen
- Sie haben sich dem Entwicklungsteam vorgestellt
- Sie haben einen regelmäßigen Sync mit DevOps
Tools
- Sie haben Zugang zum Ausführen von Sicherheitsscans
- Sie können CI/CD-Pipeline-Ergebnisse einsehen
- Sie haben Zugang zu sicherheitsrelevanten Protokollen
- Dashboard oder Tracking für Sicherheitsmetriken
Prozess
- Sicherheitsanforderungen werden irgendwo verfolgt
- Der PR-Review-Prozess umfasst sicherheitsrelevante Pfade
- Neue Features erhalten Sicherheitseingaben während der Planung
- Sicherheitsbefunde haben einen klaren Behebungs-Workflow
Haken Sie mindestens 10 der 12 Punkte ab, bevor Sie zu den Grundlagen des sicheren Programmierens übergehen.
Was als nächstes kommt
Sie verstehen Ihre Rolle in der Entwicklung und DevOps. Die nächsten Kapitel behandeln die technischen Fähigkeiten, die Sie benötigen:
- Grundlagen des sicheren Programmierens — die Schwachstellen, nach denen Sie suchen, und wie Sie sie verhindern
- Verwaltung von Sicherheitsanforderungen — wie Sie Sicherheitsanforderungen definieren und verfolgen
- Secrets-Verwaltung — Zugangsdaten aus dem Code fernhalten
- CI/CD-Sicherheit — Sicherheit in die Pipeline integrieren
- Container- und Cloud-Sicherheit — Infrastruktur absichern
Fangen wir mit dem Code selbst an.