Eine Version dieses Artikels erschien in TechRepublic. Er wurde aktualisiert und hier syndiziert.

‍

Es war ein harter - aber notwendiger - Kampf, ein Umfeld zu schaffen, in dem die Ziele des Sicherheitsteams und der Entwickler aufeinander abgestimmt sind. Wir haben noch einen langen Weg vor uns, aber die Hindernisse, die der Synergie im Wege stehen, die notwendig ist, um die Tür zur gemeinsamen Verantwortung für die Softwaresicherheit zu öffnen, werden immer deutlicher. Kluge Unternehmen wollen ihre Strategie weiterentwickeln, um diese Fallstricke zu vermeiden, einen produktiven Weg nach vorne zu finden und DevSecOps in vollem Umfang zu nutzen, um das Potenzial der Menschen zu nutzen.

Womit ich nicht gerechnet habe, ist die Tatsache, dass die Wahrnehmung dessen, was eine sichere Codierung ausmacht, zur Debatte steht. Laut einer brandneuen Studie in Zusammenarbeit mit Evans Data wurde dieses Gefühl schwarz auf weiß dargestellt. Die Studie "State of Developer-Driven Security 2022 " befasst sich mit den wichtigsten Erkenntnissen und Erfahrungen von 1200 aktiven Entwicklern und beleuchtet ihre Einstellungen und Herausforderungen im Bereich der Sicherheit.

Eines der wichtigsten Ergebnisse war, dass nur 14 % der Entwickler der Sicherheit beim Programmieren Priorität einräumen. Dies zeigt zwar, dass es einen enormen Spielraum für Verbesserungen gibt, bestätigt aber auch, was wir bereits wussten: In der Welt der Entwickler steht die Entwicklung von Funktionen im Vordergrund, und sie sind nach wie vor nicht in der Lage, Sicherheit zu einem Teil ihrer DNA zu machen. In Verbindung mit den Daten zu den Definitionen der Entwickler, was sichere Programmierung für sie bedeutet, gibt dies jedoch Anlass zur Sorge.

Diese Wahrnehmungen beruhen auf den Erfahrungen, die Entwickler in ihrem Arbeitsalltag machen, und sie sprechen für das Umfeld vieler Unternehmen, in dem Entwickler einfach nicht im Mittelpunkt des Kampfes gegen häufige Schwachstellen stehen. Ihre Befähigung ist von entscheidender Bedeutung, aber in der Zwischenzeit müssen wir uns schnell über den Umfang der "sicheren Kodierung" verständigen und darüber, was wir von einem sicherheitskompetenten Entwickler erwarten sollten. 

Wir müssen die Sicherheit in der Welt der Entwickler entmystifizieren.

Cybersicherheit ist ein vielschichtiges, schwerfälliges Gebilde, und obwohl sichere Kodierung nur einen Teil der Gesamtlandschaft darstellt, ist sie ein komplexes Rädchen im System, das besondere Aufmerksamkeit erfordert.

Die Umfrage ergab, dass das Konzept der Arbeit mit sicherem Code für den Durchschnittsentwickler ziemlich isoliert ist, wobei sich der Anwendungsbereich oft auf eine einzige Kategorie beschränkt, im Gegensatz zu einer ganzheitlichen Sicht auf die Grundlagen und darüber hinaus. Die Entwickler gaben an, sich auf die Verwendung von vorhandenem (oder vorab genehmigtem) Code zu verlassen, anstatt neuen Code zu schreiben, der frei von Sicherheitslücken ist. Während das Sicherheitsbewusstsein in Bezug auf Komponenten von Drittanbietern (insbesondere Patching, und das Log4Shell-Debakel ist ein gutes Beispiel dafür): 30 % der Instanzen sind seit Dezember ungepatcht) sehr wichtig ist, ebenso wie das Testen von bestehendem Code, reichen diese Maßnahmen allein nicht aus, um ein funktionales Niveau der sicheren Kodierung zu erreichen. 

Schwachstellen auf Code-Ebene werden von Entwicklern eingeführt, die schlechte Codierungsmuster erlernt haben, und eine fehlende Betonung des Schreibens von sicherem Code in ihren KPIs (in Verbindung mit einer mangelhaften Sicherheitskultur) verstärkt dies nur als akzeptablen Standard. 

Sicherheitsverantwortliche können einen großen Beitrag zur Verbesserung des anfänglichen Bewusstseins und zur Ermittlung der dringendsten Wissenslücken leisten, indem sie zunächst dafür sorgen, dass die Entwicklungskohorte ein vollständiges Bild davon erhält, was sichere Kodierung mit sich bringt. Das Testen und Scannen von vorab genehmigtem Code ist eine Funktion, aber die Verringerung von Schwachstellen erfordert eine praktische Schulung in guten, sicheren Codierungsmustern, in den Sprachen und Frameworks, die aktiv verwendet werden.

Bei der Weiterbildung von Entwicklern ist der Kontext entscheidend, und sie müssen in die Sicherheitsziele des Unternehmens einbezogen werden.

Viele Unternehmen müssen ihre Sicherheitsprogramme aktualisieren.

Die explosionsartige Entwicklung softwaregesteuerter Technologien hat in den letzten zehn Jahren zu einer rasanten Zunahme von Cybersecurity-Vorfällen geführt. Wir alle versuchen, mit den Bedrohungsakteuren Schritt zu halten, die rund um die Uhr daran arbeiten, Schwachstellen in wertvollen Systemen aufzudecken. 

Die DevSecOps-Methode basiert auf der Idee, dass jeder für die Sicherheit mitverantwortlich ist - auch die Entwickler - und dass sie von Beginn des SDLC an eine wichtige Rolle spielt. Das Problem ist, dass vor allem große Unternehmen noch sehr weit davon entfernt sind, DevSecOps als Standard zu implementieren. Im Jahr 2017 zeigte eine Studie des Project Management Institute, dass 51 % der Unternehmen bei der Softwareentwicklung immer noch nach dem Wasserfallmodell vorgehen. Diese Studie ist jetzt fünf Jahre alt, aber da wir wissen, wie schleichend Veränderungen in großen Unternehmen sein können, ist es unwahrscheinlich, dass es einen scharfen Übergang zu den neuesten sicherheitsorientierten Methoden gegeben hat. Für Sicherheitsexperten, die versuchen, mit einer umfassenden Strategie zum Schutz vor Cyber-Bedrohungen alle Bereiche abzudecken, können diese alten Prozesse zu einem schwierigen Unterfangen werden, und es ist eine Herausforderung, Entwickler und ihre Bedürfnisse in diese Landschaft einzupassen. 

Dies darf jedoch nicht als Ausrede dienen. Die Sicherheitsprofis im Unternehmen können die Entwickler in einer verbesserten Strategie nutzen; sie müssen sich nur mit ihren Bedürfnissen vertraut machen und sie als Teil ihres defensiven Spiels betrachten. Sie müssen umfassend geschult werden, und jede Verantwortung für die Sicherheit muss im Hinblick auf ihren Tech-Stack und ihre Arbeitsabläufe umgesetzt werden. 

Sichere Kodierung = der "zu schwere" Korb?

Die Studie von Evans Data brachte ans Licht, dass 86 % der Entwickler es schwierig finden, sichere Programmierung zu praktizieren, wobei 92 % der Entwicklungsmanager auch zugaben, dass ihre Teams mehr Schulungen zu Sicherheits-Frameworks benötigten. Beunruhigend ist, dass 48 % der Befragten zugaben, dass sie wissentlich Schwachstellen in ihrem Code hinterlassen. 

Dies ergibt ein sehr besorgniserregendes Bild. Es hat den Anschein, dass die Entwickler im Allgemeinen nicht häufig und angemessen geschult werden und auch nicht ausreichend mit guten Sicherheitspraktiken und -hygiene in Berührung kommen. Wenn man zwischen den Zeilen liest, wird der Kern des Problems noch deutlicher: Es hat für Entwickler einfach keine Priorität, die Sicherheit bei ihrer Arbeit zu berücksichtigen. Das und die Schulungen, die sie erhalten, stärken weder ihr Selbstvertrauen noch ihre praktischen Fähigkeiten, noch helfen sie ihnen, die Auswirkungen ihrer Entscheidung, anfälligen Code zu veröffentlichen, zu verstehen. 

Der Ransomware-Angriff auf die Colonial Pipeline war einer der folgenschwersten Sicherheitsvorfälle in der Versorgungskette im vergangenen Jahr und löste die Befürchtung aus, dass die Hälfte der Gasversorgung an der Ostküste der Vereinigten Staaten auf unbestimmte Zeit unterbrochen werden würde. Glücklicherweise konnte die Versorgung schnell wiederhergestellt werden, allerdings nicht ohne erhebliche Befürchtungen in der Bevölkerung. Es war einer dieser Schmelztiegel-Momente, in denen die Öffentlichkeit mit der Aussicht konfrontiert wurde, dass ein Cybervorfall ernsthafte Auswirkungen auf ein Element der physischen Welt haben könnte, das nicht unbedingt als softwaregesteuert oder als Risiko für einen Cyberangriff angesehen wird. Und all dieses Chaos wurde durch zwei alte, nicht gepatchte Sicherheitslücken ermöglicht, von denen eine die heimtückische, aber weithin bekannte SQL-Injection war. Wenn die Entwickler wüssten, was wirklich auf dem Spiel steht, wenn sie sich für anfälligen Code entscheiden, würden sie schnell erkennen, dass es kein Szenario gibt, in dem dies ein akzeptables Geschäftsrisiko darstellt.

Die Funktion "P-P-T" ist nicht Sache des Entwicklers.

Das berühmte "goldene Dreieck" aus Menschen, Prozessen und Werkzeugen ist ohne eine sorgfältig durchdachte Strategie nicht zu erreichen, und die Entwickler sind nicht in der Lage, sich in einen funktionierenden Sicherheitsprozess einzufügen, ohne ihre Bedürfnisse und Herausforderungen zu berücksichtigen.

Es bedarf eines erheblichen kulturellen Wandels, um die entwicklergesteuerte Sicherheit zu verbessern, und dies beginnt mit Ausbildungswegen, die sowohl den Ingenieuren als auch dem Sicherheitsteam zu mehr Klarheit verhelfen.