Secure Development im Entwicklungsprozess verankern

Secure Development Schulungen wie das Cyber LAB E-Learning für Entwickler schaffen die richtige Basis. Nach der Schulung verstehen Product Manager, Application Owner, Software-Architekten und Entwickler, warum Secure Development elementar wichtig ist und welche Komponenten dafür benötigt werden.

Der Erfolg ist enorm und die Bereitschaft, in Sicherheit zu investieren, steigt signifikant. Allerdings muss diese Begeisterung anschließend entsprechend kanalisiert werden.

Folgendes Vorgehen hat sich bei unseren Kunden als erfolgsversprechend erwiesen:

Alle relevanten Personen absolvieren das Cyber LAB E-Learning für Entwickler. Damit haben alle den gleichen Kenntnisstand über den Secure Software Development Lifecycle und den Nutzen.

Anschließend setzen sich das Entwicklungsteam und weitere Stakeholder im Rahmen einer Retrospektive zusammen. Diese sind innerhalb agiler Frameworks wie SCRUM fester Bestandteil des Entwicklungszyklus, aber auch Teams, die nicht agil arbeiten, können von einer Retrospektive oder einem ähnlichen Austauschformat profitieren.

Während einer Retrospektive sollten die Erkenntnisse aus der Schulung frei diskutiert werden:

• Was läuft bisher aus Secure Development – Sicht gut und sollte beibehalten werden?
• Was läuft noch nicht so gut oder ist noch gar nicht vorhanden?
• Welche Maßnahmen müssen ergriffen werden, um die Lücken Schrittweise zu schließen?

Diese wichtigen Erkenntnisse dürfen anschließend nicht in Confluence oder auf einem Whiteboard versauern, sondern sollten als konkrete Work Items mit Verantwortlichkeiten im DevOps hinterlegt werden. Wir empfehlen, die Rolle eines „Secure Development Champs“ zu etablieren. Diese Person trackt den Security Backlog und orchestriert die verschiedenen Aufgaben. Sie kann bzw. sollte zyklusweise (beispielsweise halbjährlich oder jährlich) rollieren, damit im Laufe der Zeit verschiedene Personen im Team die „Security Brille“ aufsetzen.

Falls die Product Manager ebenfalls das Cyber LAB E-Learning für Entwickler absolviert haben, werden sie diesem Vorschlag positiv gegenüberstehen, weil sie die unbedingte Notwendigkeit und den Nutzen verstehen. Falls nicht, kann das ein sehr zäher Prozess werden, denn Security konkurriert mit deren Primärzielen „neue Features“ und „Geschwindigkeit“.

Es ist also sehr wichtig, alle Stakeholder im Development-Prozess zu überzeugen, insbesondere auch das „Business“. Ein gemeinsames Verständnis schafft einen guten Mittelweg zwischen Business- und Security-Anforderungen. Eine Secure Coding Schulung kann das unmöglich leisten, sie hat ein völlig anderes Ziel.

Zurück zu unserem Praxisbeispiel: das Team hat in der Retrospektive festgestellt, dass im Rahmen der Software-Releases keine oder zu wenig Code Reviews durchgeführt werden. Der Product Manager ist sich glücklicherweise auch bewusst, dass für zukünftige Releases 5% mehr Zeit eingeplant werden muss, um die Reviews umzusetzen.

Nun geht es darum, die Code Reviews in die bestehenden Prozesse zu verankern. Der Security Champ könnte nun Tools für eine statische Code Analyse selbst evaluieren oder in Auftrag geben. Damit kann ein Teil der Reviews automatisiert und das Team entlastet werden. Ab einer bestimmten Risikostufe der Software werden zusätzlich manuelle Code Reviews durchgeführt. Im finalen Prozess soll zukünftig keine Software mehr produktiv gesetzt werden, ohne eine Risikoabschätzung und die entsprechenden Code Review durchgeführt zu haben.

Allein dieses Beispiel zeigt, dass die Integration von Security in den Development Prozess kein Sprint, sondern ein Marathon ist. Die Themen sind zu vielschichtig und zu komplex, als das sich das nebenbei erledigen lässt. „Implementing SSDLC“ (Secure Software Development Life Cycle) hat das Zeug zu einem Epic mit vielen User Stories, Work Items und Storypoints. Die Priorität muss gemeinsam mit dem Business geplant werden. Manche Themen wir statische Codeanalysen, Dependency Tracker oder Secure Coding Schulungen sind fast schon „Quick Wins“ und reduzieren signifikant typische Schwachstellen in Software. Andere können Monate oder Jahre in Anspruch nehmen. Aber der Weg lohnt sich: jeder Schritt in Richtung Secure Development reduziert auch schrittweise die Risiken.

Secure Development ist mittlerweile ein „must have“, sowohl auf Grund gesetzlicher Vorschriften als auch der Bedrohungslage. Aber niemand wartet auf Security und freut sich, weder im Business noch in der Entwicklung. Deshalb ist es elementar, dass alle Beteiligten verstehen, dass Secure Development kein „Compliance Quatsch“ ist, sondern ein elementares Konzept, das zur Grundeinstellung jedes Beteiligten werden sollte. Secure Development Schulungen wie das Cyber Security LAB E-Learning für Entwickler können einen großen Beitrag für dieses Verständnis schaffen. Im Anschluss sollte die damit erzeugte positive Energie in konkrete Projekte und Work Items übersetzt werden und mit dem Business gemeinsam priorisiert werden.