Top 8 DevSecOps-Best Practices – sicher entwickeln
26. September 2022
0 Min. LesezeitVorbei sind die Zeiten, in denen Sicherheitstests erst am Ende des Entwicklungszyklus durchgeführt und Best Practices für Sicherheit umgesetzt wurden. Die Grundprinzipien von DevSecOps sind längst keine bloße Empfehlung mehr – für die meisten modernen Entwicklungsteams gehören sie zum Standard.
Dafür gibt es gute Gründe. Unternehmen profitieren in vielerlei Hinsicht davon, Sicherheit nach links zu verlagern. So arbeiten zuvor abgeschottete Teams besser zusammen, die Zahl der Schwachstellen sinkt und die Qualität des Produkts für die Endnutzer steigt.
Wie setzen Sie DevSecOps um?
Bei DevOps vs. DevSecOps geht es bei Ersterem darum, die Zusammenarbeit und die gemeinsame Verantwortung zwischen Entwicklung und IT-Betrieb zu verbessern. Die DevSecOps-Kultur geht noch einen Schritt weiter und ergänzt eine Sicherheitskomponente. Das bedeutet, dass Entwicklungs- und Betriebsteams dafür verantwortlich sind, in jeder Phase des Entwicklungsprozesses Sicherheitstools und -praktiken einzusetzen. Außerdem bedeutet es, dass bewährte DevOps-Prinzipien auch für die Sicherheit gelten.
All das erfordert einen kulturellen und organisatorischen Wandel sowie developer-first DevSecOps-Tools, mit denen Teams Schwachstellen erkennen und beheben können. Wenn Sie DevSecOps noch nicht eingeführt haben, erfahren Sie hier, wie Sie DevSecOps in 4 Schritten implementieren.
8 Best Practices für DevSecOps
Viele Unternehmen wissen zwar, wie wichtig Best Practices für DevSecOps sind, doch manche haben Schwierigkeiten, sie umzusetzen. Ihr Unternehmen muss überlegen, wie sich Sicherheit sinnvoll in den gesamten SDLC integrieren lässt und mit den bestehenden Arbeitsweisen von Entwicklern und IT-Betrieb zusammenarbeitet – statt ihnen im Weg zu stehen.
Hier sind acht grundlegende DevSecOps-Prinzipien, mit denen Ihre Teams Sicherheit in jede Entwicklungsphase integrieren können:
1. Sicherheit mit Fokus auf Entwickler
Entwickler benötigen DevSecOps-Technologie, die sich in ihre bestehenden Prozesse integrieren lässt und ihnen Handlungsspielraum gibt. Dafür muss Sicherheit so weit wie möglich in Entwicklungsabläufen automatisiert werden.
Snyk Open Source begegnet dieser Herausforderung, indem es anfällige Abhängigkeiten erkennt, während Code in einer IDE oder CLI geschrieben wird, Pull Requests vor dem Merge scannt, automatisierte Tests in die CI/CD integriert und laufende Umgebungen regelmäßig automatisch testet.
2. Genauigkeit – Teammitgliedern die relevantesten und wichtigsten Informationen bereitstellen
Da Sicherheits-, Entwicklungs- und Betriebsteams unterschiedliche Prioritäten haben, müssen Unternehmen zusätzliche Anstrengungen unternehmen, damit jedes Team nur die für es relevanten Informationen erhält. Hier sind einige Möglichkeiten:
Informationsflüsse nach Rollen ausrichten
Berichte auf Genauigkeit, Umsetzbarkeit und Dringlichkeit optimieren
Das Signal-Rausch-Verhältnis verbessern
Falschmeldungen reduzieren
So können Teams die für sie wichtigsten Informationen nutzen, ohne sich erst durch Warnmeldungen und Mitteilungen arbeiten zu müssen.
3. Umsetzbarkeit – Sicherheitskontext bereitstellen
Sicherheitswarnungen sind zwar hilfreich, doch Teams ohne Sicherheitsexpertise benötigen klare Anweisungen zum Umgang damit. Dazu gehört, den Kontext bereitzustellen – also zu erklären, wie und warum eine Schwachstelle entsteht und wie sie sich in der IDE oder CLI beheben lässt.
Wichtig ist auch, Entwicklern eine Form der Sicherheitsschulung anzubieten, damit sie wirklich verstehen, wie sie sicher programmieren und Schwachstellen beheben können.
4. Verantwortlichkeit – Wer ist für die Sicherheit zuständig?
Jemand muss für die Sicherheit verantwortlich sein, sonst wird sie nicht umgesetzt. Richten Sie dazu ein Security-Champions-Programm ein und benennen Sie in jedem Team eine Ansprechperson, die für Sicherheit zuständig ist.
Fördern Sie außerdem die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams über den gesamten Technologie-Stack hinweg. Klare Zuständigkeiten sind unerlässlich und müssen teamübergreifend vereinbart werden. Es geht darum, zu wissen, welche Teams für die einzelnen Entwicklungsbereiche verantwortlich sind – und wer für deren Absicherung zuständig ist.
5. Ein DevSecOps-Reifegradmodell erarbeiten
Wohin entwickeln sich Ihre Teams, während sie die DevSecOps-Best Practices Ihres Unternehmens umsetzen und weiterentwickeln? Und wie sieht Ihr Geschäftsfahrplan für den Erfolg im Bereich Sicherheit aus?
Es ist wichtig, zu Beginn Ihrer Bemühungen einen Plan aufzustellen. Einsteiger können branchenübliche Reifegradmodelle wie OpenSAMM nutzen, um Sicherheitsleitplanken einzuführen und Prozesse für die Reaktion auf Vorfälle zu standardisieren. Ihr Unternehmen sollte außerdem regelmäßig seinen Sicherheitsreifegrad bewerten. So können Sie die nächsten Schritte planen und Erfolge erkennen.
6. Eine Kultur der kontinuierlichen Verbesserung etablieren
Zu den Prinzipien der kontinuierlichen Verbesserung zählen, Veränderungsmöglichkeiten zu erkennen, Prozesse zu messen und zu systematisieren sowie Abweichungen, Fehler und Durchlaufzeiten zu reduzieren.
Im DevSecOps-Kontext bedeutet das kontinuierliche Sicherheitstests, die Verbesserung von Arbeitsabläufen und weniger Ressourcenverschwendung. Außerdem priorisiert Ihr Team die wichtigsten Probleme, die zuerst behoben werden müssen, und entwickelt sein Sicherheitsprogramm kontinuierlich weiter – auf Basis neuer Bedrohungen und veränderter Unternehmensprioritäten.
7. Erfolg messen
Arbeiten Sie mit den relevanten Stakeholdern zusammen, um festzulegen, welche KPIs Sie zur Messung der Sicherheit verwenden. Nutzen Sie anschließend diese einheitlichen Kennzahlen, während Sie die Sicherheit verbessern. Messbare KPIs könnten zum Beispiel sein:
Die Anzahl schwerwiegender Schwachstellen in Ihren Anwendungen
Die Anzahl behobener Schwachstellen (d. h. wie viele Probleme während des Produktionsbetriebs behoben wurden)
Die mittlere Zeit bis zur Erkennung (MTTD)
8. Offene Kommunikation
In London weisen die öffentlichen Verkehrsbetriebe mit einem kurzen Slogan darauf hin, wie verdächtiges Verhalten in Zügen gemeldet werden kann: „Sehen, melden, handeln.“ Ähnlich müssen Schwachstellen offen und unkompliziert behoben werden.
Das ist jedoch nur mit guter Kommunikation möglich. Teammitglieder sollten Sicherheitsprobleme „sehen, melden und beheben“ können, ohne dafür bestraft zu werden, dass sie sie entdeckt haben. Fördern Sie eine offene Kommunikation innerhalb der Teams und zwischen ihnen und belohnen Sie Teammitglieder, die Probleme finden.
DevSecOps-Reife mit Snyk
Wir bei Snyk bieten Sicherheitstools, mit denen Entwickler diese Best Practices umsetzen können. Unsere Lösungen stellen Entwickler in den Mittelpunkt und lassen sich einfach in bestehende CI/CD-Pipelines integrieren. Außerdem ermöglichen sie Entwicklern, gezielte Maßnahmen zur Behebung zu ergreifen – mit Ergebnissen, die sich exportieren und zur Erfolgsmessung nutzen lassen.
Wir bieten Sicherheit für Open-Source-Komponenten, Cloud, Container, IaC und proprietären, intern entwickelten Code. Darüber hinaus können Nutzer mit unseren DevSecOps-Tools unterschiedliche Warnmeldungen für verschiedene Teams einrichten, eingehende Warnmeldungen automatisch Nutzergruppen zuweisen und sie in Benachrichtigungsplattformen sowie benutzerdefinierte Warnmeldungen integrieren. Mit Snyk lassen sich außerdem ganz einfach eigene Sicherheitsrichtlinien festlegen, die im gesamten SDLC durchgesetzt werden.
Die Lösungen von Snyk lassen sich einfach in Ihren Entwicklungsprozess integrieren und bieten kontinuierliche Scans entlang Ihrer Software-Pipeline sowie schnelle Behebungen mit nur einem Klick. Vereinbaren Sie eine Demo, um mehr über unsere developer-first DevSecOps-Tools zu erfahren.