DevSecOps: Sicherheit gehört in den Entwicklungsprozess

Das Problem mit "Security am Ende"

Das Szenario kennt wahrscheinlich jeder, der mal in einem Softwareprojekt gearbeitet hat: Das Team entwickelt monatelang ein Feature oder eine ganze Anwendung. Deadline rückt näher. Und dann, kurz vor dem Release, kommt das Security-Team und findet 50 Schwachstellen.

Was passiert dann? Panik. Hektische Meetings. Diskussionen darüber, welche Findings "kritisch" sind und welche man "akzeptieren" kann. Am Ende wird ein Teil gefixt, ein Teil akzeptiert, und alle sind genervt. Die Entwickler, weil sie kurz vor Release umbauen müssen. Das Security-Team, weil die Hälfte ihrer Findings ignoriert wird. Und das Management, weil sich das Release verschiebt.

Dieses Muster wiederholt sich in erstaunlich vielen Unternehmen. Und es funktioniert einfach nicht. Security als Torwächter am Ende der Pipeline – das erzeugt nur Frust auf beiden Seiten.

Je später Sie eine Schwachstelle finden, desto teurer wird es, sie zu fixen. Das ist keine Theorie – das sehe ich in jedem Projekt.

Was ist DevSecOps eigentlich?

DevSecOps ist im Kern eine einfache Idee: Security wird nicht am Ende draufgepackt, sondern von Anfang an in den Entwicklungsprozess eingebaut. Das Konzept dahinter heißt "Shift Left" – Security-Aktivitäten so früh wie möglich nach links in der Timeline verschieben.

Statt dass ein Security-Team am Ende alles prüft, passieren Sicherheitschecks automatisch bei jedem Commit, bei jedem Build, bei jedem Deployment. Nicht als Blocker, der alles aufhält, sondern als natürlicher Teil des Workflows.

Es geht nicht nur um Tools

Das ist der Punkt, der oft missverstanden wird. DevSecOps ist nicht "wir kaufen drei Security-Scanner und packen die in die Pipeline". Klar, Tools sind ein Teil davon. Aber der wichtigere Teil ist die Kultur dahinter.

Entwickler und Security-Leute müssen zusammenarbeiten statt gegeneinander. Wenn Security nur als Bremse wahrgenommen wird, hat man schon verloren. Das Ziel ist, dass Entwickler Security als Teil ihrer Arbeit verstehen – nicht als lästige Pflicht, die jemand anderes ihnen aufdrückt.

Und das bedeutet auch: Security-Leute müssen verstehen, wie Entwicklung funktioniert. Wer noch nie eine CI/CD-Pipeline gesehen hat, wird sich schwertun, sinnvolle Security-Gates zu definieren.

Die Bausteine von DevSecOps

Jetzt wird es konkret. Das sind die Bereiche, die Sie abdecken sollten – nicht alle auf einmal, aber langfristig.

SAST – Static Application Security Testing

SAST analysiert Ihren Quellcode, ohne ihn auszuführen. Quasi wie ein Code-Review, nur automatisiert. Das Tool schaut sich den Code an und sucht nach bekannten Schwachstellenmustern: SQL Injection, Cross-Site Scripting, unsichere Krypto-Funktionen, und so weiter.

Der Vorteil: Sie finden Probleme direkt im Code, bevor die App überhaupt gebaut wird. Der Nachteil: SAST-Tools produzieren gerne False Positives. Dazu später mehr.

Tools: SonarQube (Open Source, sehr verbreitet), Semgrep (flexibel, eigene Regeln schreiben), Checkmarx (Enterprise).

DAST – Dynamic Application Security Testing

DAST testet die laufende Anwendung von außen. Das Tool verhält sich wie ein Angreifer: Es schickt manipulierte Anfragen an die App und schaut, wie sie reagiert. Damit finden Sie Probleme, die im Code allein nicht sichtbar sind – zum Beispiel Fehlkonfigurationen oder Probleme in der Laufzeitumgebung.

DAST braucht eine laufende Instanz Ihrer Anwendung. In der Pipeline heißt das: erst deployen (z.B. in eine Staging-Umgebung), dann scannen.

Tools: OWASP ZAP (Open Source, Standard), Burp Suite (Profi-Tool, auch für manuelle Tests).

SCA – Software Composition Analysis

Ihre Anwendung besteht zu einem großen Teil aus Dependencies. npm-Pakete, Maven-Libraries, Python-Packages – Code, den jemand anderes geschrieben hat. SCA prüft diese Abhängigkeiten auf bekannte Schwachstellen.

Falls Sie denken "ist doch nicht so wichtig": Erinnern Sie sich an Log4Shell (CVE-2021-44228). Eine Schwachstelle in einer weit verbreiteten Java-Logging-Library hat Ende 2021 halb das Internet in Aufruhr versetzt. Wer seine Dependencies nicht im Blick hatte, wusste tagelang nicht, ob er betroffen war.

Tools: Snyk (gut integriert, auch für Container), Dependabot (direkt in GitHub eingebaut), OWASP Dependency-Check (Open Source, solide).

Container Security

Wenn Sie Docker nutzen – und das tun die meisten – müssen Sie auch Ihre Container-Images scannen. Ein Base-Image wie node:18 bringt ein ganzes Betriebssystem mit. Und das hat Schwachstellen. Regelmäßig.

Tools: Trivy (Open Source, schnell, von Aqua Security), Grype (von Anchore, ebenfalls Open Source).

Infrastructure as Code Security

Terraform, CloudFormation, Kubernetes-Manifeste – wenn Ihre Infrastruktur als Code definiert ist, kann man sie auch automatisch auf Fehlkonfigurationen prüfen. Offene S3-Buckets, Security Groups ohne Einschränkung, fehlende Verschlüsselung – solche Sachen.

Tools: Checkov (von Bridgecrew, unterstützt viele Formate), tfsec (speziell für Terraform, jetzt Teil von Trivy).

Secret Scanning

API-Keys, Datenbank-Passwörter, Private Keys – sowas hat im Code nichts verloren. Trotzdem passiert es ständig. Einmal committet, steht es in der Git-History. Für immer.

Secret-Scanner prüfen Ihren Code und Ihre Git-History auf solche Leaks. Das sollte bei jedem Commit passieren, idealerweise sogar als Pre-Commit-Hook, bevor der Code überhaupt im Repo landet.

Tools: GitLeaks (Open Source, schnell), truffleHog (findet auch Secrets in der Git-History).

DevSecOps in der CI/CD-Pipeline

Wie sieht das jetzt konkret in einer Pipeline aus? Hier ein typischer Ablauf:

Commit & Push – Secret Scanning (Pre-Commit oder im CI)
SAST – Statische Code-Analyse
SCA – Dependency-Check
Unit Tests – inkl. Security-relevanter Tests
Build – Anwendung und Container-Image bauen
Container Scan – Image auf Schwachstellen prüfen
Deploy to Staging
DAST – Laufende App testen
Deploy to Production

Wann breche ich den Build ab?

Das ist eine der wichtigsten Fragen. Und die Antwort ist: nicht bei jedem Finding.

Wenn Sie den Build bei jeder Low-Severity-Warnung abbrechen, wird Ihr Team Sie hassen. Und irgendwann fängt jemand an, die Security-Checks zu deaktivieren. Das wollen Sie nicht.

Stattdessen definieren Sie Quality Gates. Zum Beispiel:

Kritische und hohe Schwachstellen: Build bricht ab
Mittlere Schwachstellen: Warnung, aber Build läuft weiter
Niedrige Schwachstellen: Werden geloggt, Team schaut sie beim nächsten Sprint an
Secrets im Code: Immer sofort abbrechen, keine Ausnahme

Diese Schwellenwerte müssen zum Team passen. Am Anfang lieber lockerer, damit die Akzeptanz stimmt. Später können Sie die Schrauben anziehen.

Die typischen Hürden

DevSecOps klingt in der Theorie super. In der Praxis gibt es ein paar Stolpersteine, über die fast jedes Team stolpert.

"Das macht uns langsam"

Der häufigste Einwand. Und er stimmt – am Anfang. Security-Scans brauchen Zeit. Ein SAST-Scan bei einer großen Codebase kann mehrere Minuten dauern. DAST noch länger.

Aber: Wie viel Zeit kostet es, wenn kurz vor dem Release 50 Schwachstellen auftauchen? Oder wenn eine Schwachstelle es in die Produktion schafft und Sie nachts um drei einen Hotfix deployen müssen?

Der Trick ist, die Scans parallel laufen zu lassen, wo es geht. SAST und SCA können gleichzeitig laufen. Und nicht jeder Scan muss bei jedem Commit laufen – manche reichen einmal pro Tag oder bei Merge Requests.

False Positives nerven

SAST-Tools sind berüchtigt dafür. Sie bekommen 200 Findings, und die Hälfte davon ist Quatsch. Das ist frustrierend und führt dazu, dass Leute die Ergebnisse irgendwann ignorieren.

Was hilft:

Tool richtig konfigurieren – die Default-Regeln sind selten optimal
Regeln anpassen und eigene schreiben (Semgrep ist dafür ideal)
False Positives aktiv markieren, damit sie nicht wieder auftauchen
Nicht alle Regeln auf einmal aktivieren – lieber wenige, die stimmen

Entwickler haben keine Lust auf Security

Kann ich verstehen. Die meisten Entwickler wollen Features bauen, nicht Security-Findings fixen. Und wenn Security nur als zusätzliche Arbeit wahrgenommen wird, klappt es nicht.

Wie Sie Entwickler abholen:

Zeigen Sie ihnen, warum es wichtig ist – echte Beispiele, keine abstrakten Risiken
Machen Sie es ihnen einfach – Findings direkt in der IDE oder im Pull Request anzeigen
Keine Schuldzuweisungen – "Wer hat das committet?" ist der falsche Ansatz
Security-Wissen aufbauen – kurze, praktische Schulungen statt tagelanges Compliance-Training

Zu viele Tools auf einmal

Ich sehe das regelmäßig: Ein Unternehmen beschließt "wir machen jetzt DevSecOps" und kauft sofort fünf verschiedene Tools. Das Ergebnis: Niemand versteht die Tools, die Pipeline ist langsam, und es gibt so viele Findings, dass keiner mehr den Überblick hat.

Weniger ist mehr. Fangen Sie mit einem Tool an. Wenn das läuft und das Team damit klarkommt, nehmen Sie das nächste dazu.

Praktische Tipps zum Einstieg

Wenn Sie DevSecOps in Ihrem Team einführen wollen, hier mein Rat aus der Praxis:

Klein anfangen

Ein Tool. Eine Pipeline-Stufe. Nicht den kompletten Stack auf einmal. Sie wollen Quick Wins, die dem Team zeigen: "Das bringt was, und es tut nicht weh."

Dependency Scanning ist der einfachste Start

SCA ist aus meiner Erfahrung der beste Einstieg. Warum?

Schnell eingerichtet (Dependabot in GitHub ist ein Klick)
Wenig False Positives – eine bekannte CVE ist eine bekannte CVE
Der Wert ist sofort sichtbar – Sie sehen direkt, welche Libraries Probleme haben
Es ändert nichts am Workflow der Entwickler

Entwickler schulen, nicht nur Tools kaufen

Tools finden Schwachstellen. Aber sie fixen sie nicht. Dafür brauchen Sie Entwickler, die verstehen, was eine SQL Injection ist und warum Prepared Statements die Lösung sind. Investieren Sie in Schulungen. Nicht einmal im Jahr ein Compliance-Webinar, sondern regelmäßige, praktische Sessions.

Secure Coding Workshops, bei denen Entwickler echte Schwachstellen finden und fixen – das bringt mehr als jede Folienpräsentation.

Security Champions benennen

In jedem Entwicklungsteam sollte es mindestens eine Person geben, die sich besonders für Security interessiert. Diese "Security Champions" sind die Brücke zwischen dem Security-Team und den Entwicklern. Sie kennen den Code, verstehen die Architektur und können Security-Findings einordnen.

Das muss keine Vollzeitstelle sein. Oft reicht es, wenn sich jemand 10-20% seiner Zeit um Security-Themen kümmert und als Ansprechpartner im Team fungiert.

Fazit

DevSecOps ist kein Produkt, das Sie kaufen. Es ist eine Art, Software zu entwickeln. Security wird Teil des täglichen Workflows statt ein Gate am Ende. Das braucht Zeit, das braucht Kulturwandel, und es braucht Geduld.

Aber es lohnt sich. Teams, die Security früh integrieren, haben am Ende weniger Stress, weniger Schwachstellen in Produktion und – ja – auch weniger Kosten. Nicht weil Security billiger wird, sondern weil nachträgliches Fixen teurer ist.

Fangen Sie klein an. Ein Tool, ein Prozess, ein Team. Und dann bauen Sie es aus. Das ist der Weg, der in der Praxis funktioniert.