Definition von sicherem Code

Die Entwickler, die die Software, Anwendungen und Programme erstellen, die das digitale Geschäft vorantreiben, sind zum Lebensnerv vieler Unternehmen geworden. Die meisten modernen Unternehmen könnten ohne wettbewerbsfähige Anwendungen und Programme oder ohne den rund um die Uhr verfügbaren Zugriff auf ihre Websites und andere Infrastrukturen nicht (profitabel) funktionieren.

Und doch sind genau diese Kontaktpunkte oft das Einfallstor, das Hacker und andere kriminelle Akteure nutzen, um Informationen zu stehlen, Angriffe zu starten und als Sprungbrett für weitere kriminelle Aktivitäten wie Betrug und Ransomware zu dienen. Der aktuelle Verizon Data Breach Investigations Report unterstreicht, dass die Bedrohungen für Unternehmen und Organisationen heute gefährlicher und kostspieliger sind als je zuvor.

Erfolgreiche Angriffe sind nach wie vor weit verbreitet, obwohl die Ausgaben für Cybersicherheit in den meisten Unternehmen stark gestiegen sind und Bewegungen wie DevSecOps die Sicherheit zunehmend auf die Entwickler verlagern, die heute das Rückgrat des Geschäfts bilden.

Entwickler verstehen die Bedeutung von Sicherheit und möchten überwiegend sicheren und qualitativ hochwertigen Code bereitstellen, doch Software-Schwachstellen werden weiterhin ausgenutzt.

Warum?

Zum zweiten Mal in Folge führte Secure Code Warrior im Dezember 2021 in Zusammenarbeit mit Evans Data Corp. die Umfrage „The state of developer-driven security, 2022“ durch. Wir haben 1.200 Entwickler weltweit befragt, um ihre Fähigkeiten, Wahrnehmungen und Verhaltensweisen in Bezug auf sichere Codierungspraktiken sowie deren Auswirkungen und wahrgenommene Relevanz im Softwareentwicklungslebenszyklus (SDLC) zu verstehen.

Die Umfrage ergab, dass es keine klare Definition oder ein einheitliches Verständnis dafür gibt, was sicheren Code ausmacht. Es zeigt sich eine große Diskrepanz zwischen dem, was Entwickler für sicheren Code halten, und dem, was sicherer Code tatsächlich ist.

Es überrascht nicht, dass die Erstellung von qualitativ hochwertigem Code für die Entwickler-Community oberste Priorität hat. Doch auf die spezifische Frage nach sicherem Code gaben nur 29 % an, dass die aktive Praxis, Code frei von Schwachstellen zu schreiben, priorisiert wird. Stattdessen assoziierten Entwickler weniger sichere und weitaus unzuverlässigere Praktiken mit der Erstellung von sicherem Code. So waren beispielsweise die Überprüfung von vorhandenem Code (37 %) und das Vertrauen auf extern bezogene Bibliotheken für sicheren Code (37 %) die am häufigsten genannten Praktiken, die Entwickler mit sicherer Codierung in Verbindung brachten. Die Wiederverwendung von Code, der bereits als sicher eingestuft wurde (32 %), war eine weitere beliebte Wahl. Die aktive Praxis, Code frei von Schwachstellen zu schreiben, landete mit 29 % auf dem 6. Platz der genannten Praktiken. Auf Nachfrage wurden Zeitmangel und das Fehlen eines kohärenten Ansatzes seitens des Managements als die größten Hindernisse für die Erstellung von sicherem Code genannt.

Das Vertrauen auf bestehenden Code ist einer der Faktoren, die das Risiko erhöhen, dass Software mit ausnutzbaren Schwachstellen ausgeliefert wird. Um qualitativ hochwertigen und gleichzeitig sicheren Code zu erstellen, müssen Entwickler diese Diskrepanz bei der Definition von sicherem Code überwinden.

Es zeigt sich eine große Diskrepanz zwischen dem, was Entwickler für sicheren Code halten, und dem, was sicherer Code tatsächlich ist.

Was können Unternehmen tun, um die Situation zu verbessern?

Eine der wichtigsten Erkenntnisse der Umfrage war, dass die Entwickler-Community als Ganzes aus professionellen Menschen besteht, denen ihre Arbeit am Herzen liegt. Die Erstellung von qualitativ hochwertigem Code war für sie als Gruppe von überragender Bedeutung. Das Problem ist, dass die Unternehmen, für die sie arbeiten, in vielen Fällen nicht definiert haben, welche Best Practices für die Erstellung von sicherem Code erforderlich sind, und nicht genügend Ressourcen in die Schulung investiert oder ihre Entwickler nicht in die Lage versetzt haben, diese Ziele zu erreichen.

Tatsächlich gaben die meisten Entwickler an, dass ihre Unternehmen nicht einmal eine klare Definition dafür hätten, was sicheren Code ausmacht. Eines der besorgniserregendsten Beispiele hierfür war, dass 28 % der Umfrageteilnehmer angaben, ihr Unternehmen betrachte Code als sicher, wenn nach der Bereitstellung einer Anwendung oder eines Programms in einer Produktionsumgebung oder der Veröffentlichung für die Öffentlichkeit keine Sicherheitsverletzung gemeldet wurde.

Es versteht sich wahrscheinlich von selbst, aber in der heutigen komplexen Bedrohungslandschaft führt das bloße Hoffen auf gute Ergebnisse, ohne aktiv darauf hinzuarbeiten, wahrscheinlich zu vorhersehbaren Resultaten: noch mehr Sicherheitsverletzungen.

Glücklicherweise ist dies eine Situation, in der es relativ einfach ist, zumindest mit der Problemlösung zu beginnen und dann auf das Ziel von sicherem Code hinzuarbeiten. Der erste und wohl wichtigste Schritt besteht darin, dass Unternehmen definieren, was sie unter sicherem Code verstehen. Und alles, was außerhalb dieser Definition liegt, muss als nicht sicher eingestuft werden.

Sichere Codierung sollte als die Praxis definiert werden, bei der qualifizierte Entwickler von Beginn des SDLC an Code schreiben, der frei von Schwachstellen ist. Erst wenn diese Praxis definiert ist, kann die Entwickler-Community auf dieses Ziel hinarbeiten.

Sicheren Code zur Realität machen

Sobald die Definition von sicherem Code steht, müssen Unternehmen bereit sein, diese Bemühungen und die Entwickler, die das Ziel einer umfassenden Implementierung sicherer Codierungspraktiken umsetzen, zu unterstützen. Diese Unterstützung ist entscheidend. Ohne sie bleibt die Definition von sicherem Code in Ihrem Unternehmen zwar wichtig, aber letztlich ein zahnloser Tiger. Sichere Codierungspraktiken müssen vom Management unterstützt werden und die nötige Aufmerksamkeit, Befugnisse und Budgets erhalten, um erfolgreich zu sein.

Dies erfordert möglicherweise neue Benchmarks für Entwickler, die traditionell an ihrer Codiergeschwindigkeit gemessen wurden. Tatsächlich gaben 37 % der befragten Entwickler an, bekannte Schwachstellen in ihrem Code zu belassen, da enge Fristen keine Zeit ließen, diese zu beheben oder von Anfang an sauber zu programmieren. Zunächst kann dies bedeuten, Fristen zu verlängern, um Entwicklern mehr Zeit für sauberen Code zu geben. Dieser Zeitaufwand zu Beginn zahlt sich jedoch später aus, da weniger Überarbeitungen, Patches und Nachbesserungen nach der Bereitstellung nötig sind. Die Vermeidung von Sicherheitslücken nach dem Rollout kann hunderte Stunden Arbeit sowie Millionen an Umsatzeinbußen, Bußgeldern und Bereinigungskosten sparen.

Entwickler benötigen zudem praxisnahe Schulungen, insbesondere im Hinblick auf spezifische Schwachstellen, denen sie häufig begegnen, sowie Unterstützung beim Erkennen und Beheben von Sicherheitslücken. Dies gilt umso mehr, als 36 % der Befragten angaben, Schwachstellen zwar entfernen zu wollen, ihnen dazu jedoch die nötigen Fähigkeiten oder das Wissen fehlten.

37 % der befragten Entwickler gaben an, bekannte Schwachstellen in ihrem Code zu belassen, da enge Fristen keine Zeit ließen, diese zu beheben oder von Anfang an sauber zu programmieren.

Interessiert an mehr zu diesem Thema?

Whitepaper: Die Herausforderungen (und Chancen) zur Verbesserung der Softwaresicherheit.
Bericht: Umfrage zum Stand der entwicklergesteuerten Sicherheit, 2022.