Wie definieren Entwickler „sichere Programmierung“?

Eine Version dieses Artikels erschien bei TechRepublic. Er wurde aktualisiert und hier erneut veröffentlicht.

‍

Es war ein mühsamer – 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 notwendigen Synergie für eine geteilte Verantwortung bei der Softwaresicherheit im Weg stehen, werden immer deutlicher. Intelligente Unternehmen wollen ihre Strategie weiterentwickeln, um diese Fallstricke zu vermeiden, einen produktiven Weg nach vorne zu finden und das volle, auf den Menschen ausgerichtete Potenzial von DevSecOps zu nutzen.

Was ich nicht erwartet hatte, ist, dass die Auffassung darüber, was sicheres Programmieren eigentlich ausmacht, umstritten ist. Laut brandneuer Forschung in Zusammenarbeit mit Evans Data wurde diese Stimmung schwarz auf weiß belegt. Die Umfrage „State of Developer-Driven Security 2022“ befasst sich mit den wichtigsten Erkenntnissen und Erfahrungen von 1.200 aktiven Entwicklern und beleuchtet deren Einstellungen und Herausforderungen im Bereich der Sicherheit.

Eines der wichtigsten Ergebnisse war, dass nur 14 % der Entwickler Sicherheit beim Programmieren als Priorität betrachten. Auch wenn dies zeigt, dass es noch enormen Verbesserungsbedarf gibt, bestätigt es, was wir bereits wussten: Die Entwicklung von Funktionen steht in der Welt der Entwickler an erster Stelle, und sie sind nach wie vor schlecht darauf vorbereitet, Sicherheit zu einem festen Bestandteil ihrer Arbeit zu machen. In Verbindung mit den Daten darüber, wie Entwickler sicheres Programmieren definieren, gibt dies jedoch Anlass zur Sorge.

Diese Wahrnehmungen sind auf die tägliche Erfahrung der Entwickler zurückzuführen und spiegeln das Umfeld vieler Unternehmen wider, in dem Entwickler im Kampf gegen häufige Schwachstellen schlichtweg nicht im Mittelpunkt stehen. Ihre Befähigung ist entscheidend, aber in der Zwischenzeit müssen wir uns schnell auf eine gemeinsame Definition von „sicherem Programmieren“ einigen und darauf, was wir von einem sicherheitsbewussten Entwickler erwarten sollten.

Wir müssen das Thema Sicherheit in der Welt der Entwickler entmystifizieren.

Cybersicherheit ist selbst in den besten Zeiten ein vielschichtiges, unhandliches Biest, und obwohl sicheres Programmieren nur einen Teil der gesamten Landschaft darstellt, ist es ein komplexes Rädchen im System, das spezialisierte Aufmerksamkeit erfordert.

Die Umfrage ergab, dass das Konzept der Arbeit mit sicherem Code für den durchschnittlichen Entwickler recht isoliert betrachtet wird, wobei sich der Fokus oft auf eine einzige Kategorie beschränkt, anstatt einen ganzheitlichen Blick auf die Grundlagen und darüber hinaus zu werfen. Entwickler gaben an, sich eher auf die Verwendung von bestehendem (oder vorab genehmigtem) Code zu verlassen, anstatt neuen Code zu schreiben, der frei von Schwachstellen ist. Während das Sicherheitsbewusstsein für Komponenten von Drittanbietern (insbesondere beim Patchen – das Log4Shell-Debakel ist ein gutes Beispiel: 30 % der Instanzen sind seit Dezember ungepatcht) sehr wichtig ist, ebenso wie das Testen von vorhandenem Code, reichen diese Maßnahmen allein nicht aus, um ein funktionales Niveau an sicherem Programmieren zu erreichen.

Schwachstellen auf Code-Ebene werden von Entwicklern eingeführt, die sich schlechte Programmiermuster angeeignet haben. Ein mangelnder Fokus auf das Schreiben von sicherem Code in ihren KPIs (gepaart mit einer schwachen Sicherheitskultur) festigt dies nur als akzeptablen Standard.

Sicherheitsverantwortliche können viel dazu beitragen, das anfängliche Bewusstsein zu verbessern und die dringendsten Wissenslücken zu identifizieren, indem sie zunächst sicherstellen, dass den Entwicklern das Gesamtbild dessen vermittelt wird, was sicheres Programmieren beinhaltet. Das Testen und Scannen von vorab genehmigtem Code ist eine Funktion, aber die Reduzierung von Schwachstellen erfordert praktische Schulungen in guten, sicheren Programmiermustern in den Sprachen und Frameworks, die aktiv verwendet werden.

Kontext ist bei der Weiterbildung von Entwicklern entscheidend, und sie müssen bei den Sicherheitszielen des Unternehmens mit ins Boot geholt werden.

Viele Unternehmen müssen ihre Sicherheitsprogramme modernisieren.

Angesichts der explosionsartigen Zunahme softwaregestützter Technologien, die den rasanten Anstieg von Cybersicherheitsvorfällen im letzten Jahrzehnt begünstigt hat, versuchen wir alle, mit den Angreifern Schritt zu halten, die rund um die Uhr daran arbeiten, Exploits in wertvollen Systemen aufzudecken.

Die DevSecOps-Methodik basiert auf der Idee, dass jeder die Verantwortung für Sicherheit teilt – auch die Entwickler – und dass dies von Beginn des Softwareentwicklungszyklus (SDLC) an eine zentrale Überlegung ist. Das Problem ist, dass sie, insbesondere in großen Unternehmen, sehr weit davon entfernt sein können, DevSecOps als Standard zu implementieren. Im Jahr 2017 zeigte eine Studie des Project Management Institute, dass 51 % der Unternehmen für ihre Softwareentwicklung noch das Wasserfallmodell verwendeten. Diese Studie ist nun fünf Jahre alt, aber wenn man bedenkt, wie schleichend Veränderungen in großen Unternehmen verlaufen können, ist es unwahrscheinlich, dass es einen abrupten Übergang zu den neuesten sicherheitsorientierten Methoden gegeben hat. Diese veralteten Prozesse können für Sicherheitsexperten, die versuchen, alle Eventualitäten mit einer umfassenden Strategie zum Schutz vor Cyberbedrohungen abzudecken, einen mühsamen Kampf bedeuten, und die nachträgliche Integration von Entwicklern und ihren Bedürfnissen in diese Landschaft ist eine Herausforderung.

Wir können dies jedoch nicht als Ausrede benutzen. Die Sicherheitsexperten im Unternehmen können Entwickler in eine verbesserte Strategie einbinden; sie müssen sich nur mit deren Bedürfnissen vertraut machen und sie als Teil ihrer Verteidigungsstrategie betrachten. Sie benötigen umfassende Schulungen, und jede Verantwortung für die Sicherheit muss unter Berücksichtigung ihres Tech-Stacks und ihrer Arbeitsabläufe implementiert werden.

Sicheres Programmieren = die „zu schwierig“-Schublade?

Die Untersuchung von Evans Data hat ans Licht gebracht, dass 86 % der Entwickler sichere Programmierung als Herausforderung empfinden, während 92 % der Entwicklungsleiter einräumen, dass ihre Teams mehr Schulungen zu Sicherheits-Frameworks benötigen. Besorgniserregend ist, dass 48 % der Befragten zugaben, wissentlich Schwachstellen in ihrem Code zu belassen.

Dies zeichnet ein sehr bedenkliches Bild. Es scheint, als erhielten Entwickler im Allgemeinen weder regelmäßige, angemessene Schulungen noch ausreichend Einblicke in bewährte Sicherheitspraktiken. Zwischen den Zeilen wird der Kern des Problems deutlich: Sicherheit hat für Entwickler bei ihrer Arbeit schlicht keine Priorität. Zudem stärken die erhaltenen Schulungen weder ihr Selbstvertrauen noch ihre praktischen Fähigkeiten und verdeutlichen ihnen nicht die Konsequenzen, die das Ausliefern anfälligen Codes nach sich zieht.

Der Ransomware-Angriff auf Colonial Pipeline war einer der folgenschwersten Vorfälle in der Lieferkettensicherheit des letzten Jahres und schürte die Angst, dass die Hälfte der Gasversorgung an der US-Ostküste auf unbestimmte Zeit unterbrochen werden könnte. Glücklicherweise war das System schnell wieder einsatzbereit, doch der Vorfall löste in der Branche erhebliche Besorgnis aus. Es war ein Schlüsselmoment, in dem die Öffentlichkeit erkannte, dass Cybervorfälle reale Auswirkungen auf Bereiche haben können, die man nicht unbedingt als softwaregesteuert oder gefährdet betrachtet. Das gesamte Chaos wurde durch zwei alte, ungepatchte Schwachstellen ermöglicht, darunter die tückische, aber weithin bekannte SQL-Injection. Wüssten Entwickler, was bei anfälligem Code wirklich auf dem Spiel steht, würden sie schnell erkennen, dass dies kein akzeptables Geschäftsrisiko darstellt.

Funktionale „M-P-W“ liegt nicht in der Hand der Entwickler.

Das berühmte „goldene Dreieck“ aus Menschen, Prozessen und Werkzeugen lässt sich nur mit einer durchdachten Strategie erreichen. Entwickler können sich nicht in einen funktionierenden Sicherheitsprozess integrieren, wenn ihre Bedürfnisse und Herausforderungen dabei nicht berücksichtigt werden.

Ein erheblicher kultureller Wandel ist erforderlich, um eine entwicklergesteuerte Sicherheit zu etablieren. Dies beginnt mit Bildungsangeboten, die sowohl Ingenieuren als auch dem Sicherheitsteam zu mehr Klarheit verhelfen.