Welche Rolle spielt der Mensch bei der Zukunft der sicheren Programmierung?

Angesichts der stetig wachsenden Zahl von Cyber-Bedrohungen müssen Unternehmen täglich Kompromisse zwischen Sicherheit, Praktikabilität und Geschwindigkeit eingehen – und setzen sich damit unnötigen Risiken aus. Es bedarf neuer Ansätze für sicheres Programmieren, weshalb Secure Code Warrior Evans Data Corp. damit beauftragt hat, eine Primärstudie zur Einstellung von Entwicklern gegenüber sicherem Programmieren, entsprechenden Praktiken und Security Operations durchzuführen (das Whitepaper können Sie hier herunterladen).

Der Bericht zeigt: Während das „alte“, reaktive Denken noch immer dominiert, wächst das Bewusstsein für die Notwendigkeit proaktiverer Lösungen, die Entwickler selbst zur ersten Verteidigungslinie machen.

Jede Untersuchung zur Einführung sicherer Programmierpraktiken muss mit einem Verständnis für die beteiligten Menschen, deren Wahrnehmung und ihre Umsetzungskapazitäten beginnen. Dies führt zum wichtigsten Teil des Puzzles: Wie können Entwickler befähigt werden, von Anfang an sicherer zu programmieren und qualitativ hochwertigen Code schneller und mit mehr Sicherheit bereitzustellen?

Sicheres Programmieren – wo stehen wir heute und was muss sich ändern? Laden Sie jetzt die Infografik „The Human Element“ herunter.

Aktuelle Perspektiven – reaktiv vs. proaktiv

Als Entwickler und Entwicklungsleiter nach den Aktivitäten gefragt wurden, die sie mit sicherem Programmieren assoziieren, waren dies die drei häufigsten Antworten:

• Einsatz von Scan-Tools für bereitgestellte Anwendungen.
• Manuelle Überprüfung von Code auf Schwachstellen.
• Die aktive und kontinuierliche Praxis, Software so zu schreiben, dass sie vor Schwachstellen geschützt ist.

Wie man sieht, konzentrieren sich zwei der drei häufigsten Antworten immer noch auf reaktive Ansätze – der erste ist abhängig von Tools (Scannern), der zweite vom Entwickler (also dem Menschen), der manuelle Prüfungen durchführt.

Gleichzeitig beruhen zwei der drei genannten Aktivitäten auf dem menschlichen Faktor. Dies deutet auf eine wachsende Wahrnehmung von Sicherheit als menschliches Thema hin. Doch von allen genannten Aktivitäten ist die Nummer 3 am aufschlussreichsten, da sie den menschlichen Faktor beim Schreiben von Software, die von vornherein vor Schwachstellen geschützt ist, in den Mittelpunkt stellt. Dies unterstreicht den Wandel hin zu „Shift Left“ – einem proaktiven und präventiven Ansatz, der Sicherheit von Beginn des Softwareentwicklungszyklus (SDLC) an in die Software integriert.

Wo passt Sicherheit in den SDLC?

Wenn Entwickler und Entwicklungsleiter gefragt werden, wo sich Praktiken für sicheren Code in den SDLC integrieren lassen, gehen die Meinungen auseinander. 55 % der Führungskräfte glauben, dass sicheres Programmieren in den gesamten Entwicklungsprozess integriert ist, verglichen mit nur 43 % der Entwickler. Dieser Unterschied könnte die verschiedenen Rollen der beiden Gruppen innerhalb des SDLC widerspiegeln. Das Management ist in der Regel weniger in die eigentliche Programmierarbeit involviert und hat eher einen übergeordneten Blick – während Entwickler sich stärker mit den technischen Details befassen.

Aus Sicht der allgemeinen Sicherheit und Codequalität ist jedoch alarmierend, dass nur 13 % der Entwickler und 10 % der Führungskräfte sagen, dass sichere Codierungspraktiken bereits in den Designphasen – also direkt zu Beginn des SDLC – integriert werden sollten. Dies ist eine riesige, ungenutzte Chance. Laut einer IBM-Studie ist es dreißigmal teurer, Schwachstellen in bereits veröffentlichtem Code zu beheben, als sie zu Beginn zu finden und zu beseitigen.1 Das ist ein starker Anreiz für eine neue, proaktive und menschzentrierte Verteidigung der Softwaresicherheit, die Entwickler befähigt, von Anfang an sicherer zu programmieren. Softwaresicherheit lässt sich nicht allein durch Tools lösen – sie muss den menschlichen Faktor berücksichtigen.

Ist der menschliche Faktor vorbereitet?

97 % der befragten Entwickler glauben, eine ausreichende Schulung in sicherem Programmieren erhalten zu haben, und 95 % stimmten zu, dass diese Schulung für ihre Karriere wertvoll war. Doch bevor wir diese Aussagen für bare Münze nehmen, müssen wir fragen: Warum sind Code-Schwachstellen immer noch so weit verbreitet? Ist der Anspruch der Entwickler auf Expertise in sicherem Code nur ein Fall von menschlichem Ego? Die Beweise deuten sicherlich in diese Richtung. In einem bescheideneren Eingeständnis geben mehr als 88 % der befragten Entwickler zu, dass sicheres Programmieren schwer zu erlernen ist, und 91 % der Entwicklungsleiter räumen ein, dass die Umsetzung sicherer Programmierpraktiken eine Herausforderung darstellt. Auf die Frage nach ihren größten persönlichen Bedenken bei der Implementierung von sicherem Code gaben 28 % der Entwickler an, dass der Lernprozess schwierig sei, während 24 % ihn als langweilig empfinden. Dies zeigt, dass die Entwicklerschulung verbessert werden muss.

Was braucht der menschliche Faktor?

Um den Faktor „Herausforderung“ zu überwinden, erfordert eine lohnende Sicherheitsschulung einen „Scaffolding“-Prozess, der den Entwickler dabei unterstützt, Fähigkeiten für sicheres Programmieren Schritt für Schritt aufzubauen. Für maximale Relevanz und sofortige Anwendbarkeit sollte diese Schulung in der spezifischen Sprache und dem Framework stattfinden, die sie täglich verwenden.

Um den Faktor „Langeweile“ zu überwinden, muss die Schulung für sicheren Code praxisnah vermittelt werden – dies ist nachweislich wesentlich motivierender für Entwickler als veraltete Unterrichtsmodelle oder „Video ansehen“-Formate. Dazu sollten Live-Simulationen gehören, die es Entwicklern ermöglichen, teils riskante Sicherheitsherausforderungen in einer sicheren Umgebung zu bewältigen. Ziel sollte es sein, Entwicklern beizubringen, wie sie Schwachstellen im Code während der Arbeit finden und beheben können, und sicheres Programmieren zu einem festen Bestandteil ihres Arbeitsalltags zu machen. Ein weiterer Schlüsselfaktor ist Linting und Coaching direkt in der IDE, das Entwicklern hilft, während des Programmierens kontinuierlich zu lernen und ihre Fähigkeiten zu erweitern, um Schwachstellen proaktiv zu verhindern und zu beseitigen.

Wenn Sie erfahren möchten, wie Sie Ihren Entwicklern diese neue Ebene an entwicklerzentrierten Tools und Schulungen bieten können, buchen Sie jetzt eine Demo.

Sie können auch Ihr Exemplar des Whitepapers Shifting from reaction to prevention: The changing face of application security herunterladen.

‍