Die AppSecure.nrw Software Security Studie - Eine Umfrage unter Entwickler*innen, Product Ownern und Führungskräften
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Die AppSecure.nrw Software Security Studie Eine Umfrage unter Entwickler*innen, Product Ownern und Führungskräften
Inhaltsverzeichnis
Vorwort.................................................................................................................................................................................. 3
1 Methodik ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ 5
2 Beruflicher Hintergrund der Teilnehmer*innen��������������������������������������������������������������������������������������������������������������� 6
3 Entwicklungsprozess und Betrieb������������������������������������������������������������������������������������������������������������������������������������� 9
4 Werkzeuge��������������������������������������������������������������������������������������������������������������������������������������������������������������������������16
5 Security-Kompetenz...........................................................................................................................................................21
6 Kompetenzausbau..............................................................................................................................................................29
7 Sensibilisierung aller Beteiligten.....................................................................................................................................34
8 Fazit und Auswirkungen....................................................................................................................................................38
9 Empfehlungen zur Verbesserung des Status Quo...........................................................................................................39
Ansprechpartner und Kontakt...........................................................................................................................................41
VORWORT
erkannt, dass die PO zu wenige oder keine Security-An-
Es tut sich was, es gewinnt an Wichtigkeit, forderungen an das zu entwickelnde Produkt stellen
wird aber sicherlich nicht von allen mit Kuss- und FK nur selten Maßnahmen zum Ausbau der Secu-
hand angenommen, weil Security immer noch rity-Kompetenz durchführen. Somit besteht für viele
bremsend wirkt. [...] Ich glaube es würde keiner Unternehmen die Gefahr, dass ihre Produkte nicht vor
sagen Security ist egal, ganz sicher nicht! Aber böswilligen Angriffen geschützt sind. Erfreulicherweise
es ist anstrengend, sich mit dem Thema zu be- sind sich viele Entwickler*innen, FK und PO ihren aktu-
schäftigen. – Interviewteilnehmer*in ellen Problemen und Herausforderungen bewusst und
bereit, die heutige Situation zu verbessern. Aufgrund
der Ergebnisse unterstützen wir im weiteren Projekt-
Security gewinnt in allen Branchen immer mehr an verlauf von AppSecure.nrw dieses Vorhaben durch die
Bedeutung, da die entwickelten Systeme zunehmend Definition eines Reifegradmodells für agile Teams, die
schützenswerte Daten verarbeiten und kritische Dienste Erstellung von Weiterbildungen für Entwickler*innen,
bereitstellen. Daher ist es nicht verwunderlich, dass das FK und PO sowie die Weiterentwicklung von bestehen-
World Economic Forum in seinem Global Risk Report den freien Werkzeugen.
2020 das Thema Security als das größte technologische
Risiko für die Weltbevölkerung einstuft. Dies wirft die Im Folgenden stellen wir Ihnen unsere Studienergebnis-
Frage auf, inwieweit deutsche Unternehmen das The- se im Detail vor. Nach der Erläuterung unserer Methodik
ma Security bei der Entwicklung und dem Betrieb ihrer und dem beruflichen Hintergrund der Studienteilneh-
Softwareprodukte adressieren und was aktuelle Her- mer*innen werden die zentralen Ergebnisse unserer
ausforderungen sind. Zur Beantwortung dieser Fragen Studie anhand von fünf Themen dargestellt: Zunächst
haben wir in unserem Forschungsprojekt AppSecure. fokussieren wir den Entwicklungsprozess, welchen wir
nrw (www.appsecure.nrw) im Jahr 2019 eine umfang- in die Bereiche Anforderungsmanagement, Entwurf,
reiche Studie durchgeführt. Dabei haben wir nicht nur Implementierung & Tests sowie den Betrieb unterteilt
die Entwickler*innen der Software, sondern auch deren haben. Anschließend berichten wir über unsere Er-
Führungskräfte (FK) und Product Owner (PO) befragt, kenntnisse zum Werkzeugeinsatz. Danach thematisie-
um ein ganzheitliches Bild zu erhalten. ren wir die Security-Kompetenz aller Beteiligten sowie
die heutigen Maßnahmen zum Kompetenzausbau. Im
Das Ergebnis unserer Studie ist, dass für Unternehmen letzten Thema analysieren wir die Sensibilisierung für
die Gewährleistung von Security in ihren Produkten Security. Am Ende des Dokuments finden Sie das Fazit
eine vielschichtige Herausforderung ist und Hand- und eine Skizzierung von dessen Auswirkungen sowie
lungsbedarf besteht. Primär fehlt es den Entwickler*in- unsere sich hieraus ableitenden Empfehlungen.
nen, FK und PO an der Sensibilisierung für das Thema
Angriffssicherheit, an Security-Kompetenz sowie an Wir wünschen Ihnen eine anregende Lektüre. Sollten
Methoden zur sicheren Softwareentwicklung und hier- Sie Fragen zur Studie oder unseren Empfehlungen ha-
für passenden Werkzeugen. Darüber hinaus haben wir ben, sprechen Sie uns gerne an.
3
4
1
METHODIK
Im Rahmen der Studienerstellung wurden sowohl qua- wahl benötigte eine durchschnittliche Bearbeitungszeit
litative als auch quantitative Forschungsmethoden ein- von 25 Minuten zur Beantwortung aller Fragen. Bezüg-
gesetzt. Aus insgesamt 21 Forschungsfragen wurden lich unserer Ergebnispräsentation sei noch ergänzt,
eine Online-Umfrage und zwei Interview-Leitfäden dass wir alle Prozentzahlen auf ganze Zahlen gerundet
entwickelt. Diese wurden intern und anschließend mit haben. Daher sind alle Abweichungen der Summe von
den AppSecure.nrw Projektpartnern AXA Konzern AG, 100 Prozent rundungsbedingt.
Connext Communication GmbH und adesso mobile
solutions GmbH ausführlich bzgl. Verständlichkeit und Vier der insgesamt 17 interviewten Personen sind Teil
Eindeutigkeit verbessert. Verantwortlich für die Ent- des Projektteams von AppSecure.nrw. Die restlichen 13
wicklung, Durchführung und Auswertung der Befragun- Personen hatten keinen Bezug zum Projekt. Die Inter-
gen ist das Fraunhofer IEM. viewleitfäden für Führungskräfte (FK) und Product Ow-
ner (PO) bestanden aus jeweils 17 Fragen. Hatte ein
Die 40 Fragen umfassende Online-Umfrage wurde Interviewpartner beide Rollen inne, wurden die Fragen
anonym durchgeführt und durch Fraunhofer IEM und aus beiden Leitfäden gestellt. Basierend auf den Leit-
dessen Geschäftspartner, den Projektpartnern von Ap- fäden wurden in den Interviews offene Fragen gestellt,
pSecure.nrw, den Technologie-Netzwerken it’s OWL und um möglichst viele Zwischentöne zu erfassen. Auch
innozent OWL, Heise Medien und der Bitkom beworben. Nachfragen und Ausschweifungen wurden bewusst zu-
Insgesamt haben 350 Personen an der Umfrage teil- gelassen. Ein Interview dauerte im Schnitt etwa 45 Mi-
genommen. Die Antworten von Teilnehmenden aus der nuten. Bzgl. der Auswertung sei noch erwähnt, dass sich
Schweiz und Österreich mussten wir leider herausneh- in den Interviews große Überschneidungen zwischen
men, da diese in zu geringer Anzahl teilgenommen hat- den Rollen FK und PO gezeigt haben. Daher haben wir
ten, um eine aussagekräftige Auswertung dieser Länder in unserer Auswertung oftmals beide Rollen gemein-
vorzunehmen. Darüber hinaus haben wir alle Personen sam analysiert – falls es Unterschiede gab, haben wir
herausgefiltert, die die Umfrage nicht vollständig aus- diese jedoch stets kenntlich gemacht. Alle Zitate, die
gefüllt haben bzw. deren Bearbeitungszeit kein Lesen wir in diesem Dokument darstellen, stammen aus die-
der Fragen zulässt. Insgesamt verblieben somit die Ant- sen Interviews.
worten von 256 Personen aus Deutschland. Diese Aus-
5
2
BERUFLICHER HINTERGRUND
DER TEILNEHMER*INNEN
2.1 Entwickler*innen
Die Online-Umfrage wurde von insgesamt 256 Ent- (36%) oder im direkten Kundenauftrag entwickelt (28%).
wickler*innen aus Deutschland vollständig ausgefüllt. 15% der Entwickler*innen werden zudem zu anderen Un-
61% der Befragten geben an, über mehr als zehn Jah- ternehmen entsendet, um dort in Projekten mitzuwirken.
re Berufserfahrung in der Softwareentwicklung (vgl.
Abbildung 1.a) zu verfügen. 18% der Befragten haben Die Entwickler*innen sind an verschiedensten Applika-
zwischen sechs und zehn Jahre Berufserfahrung und tionen beteiligt (vgl. Abbildung 1.d). Besonders häufig
15% der Befragten haben zwischen zwei und fünf Jahre werden Webanwendungen (66%) und Backend-Appli-
Berufserfahrung. 6% der Befragten sind Berufseinstei- kationen (59%) entwickelt, gefolgt von Desktop-Appli-
ger*innen und verfügen über weniger als zwei Jahre Be- kationen (37%) und mobilen Applikationen (25%). Eher
rufserfahrung. Insgesamt haben wir mit unserer Online- selten werden Applikationen für das Embedded-Umfeld
Umfrage überwiegend sehr erfahrene Entwickler*innen entwickelt (14%).
erreicht.
Die Größe der Teams ist bei den befragten Entwick-
Gegliedert nach Unternehmensgröße stammen 14% ler*innen meist 15 oder weniger Personen (vgl. Abbil-
der Befragten aus Unternehmen mit maximal 50 Be- dung 1.e). Innerhalb des jeweiligen Projekts arbeiten
schäftigten und 26% aus Unternehmen mit mindestens die befragten Entwickler*innen üblicherweise in Teams
51 und maximal 250 Beschäftigten. Insgesamt sind damit mit 6-15 Personen (56%) oder 1-5 Personen (32%). Grö-
40% der Befragten bei sogenannten kleinen und mittle- ßere Teams mit mehr als 16 Personen sind eher selten
ren Unternehmen (KMU) beschäftigt (vgl. Abbildung 1.b). (13%).
61% der Befragten arbeiten in großen Unternehmen
(mehr als 250 Beschäftigte). Die Entwickler*innen arbeiten typischerweise in mehre-
ren Disziplinen: 64% sind im Anforderungsmanagement
Die Geschäftsmodelle der Unternehmen sind sehr un- aktiv, 81% im Entwurf, 86% in Implementierung und/
terschiedlich (vgl. Abbildung 1.c). In den meisten Fällen oder Softwaretest und 52% im Betrieb der Software tä-
wird die Software (55%) im eigenen Unternehmen ein- tig (vgl. Abbildung 1.f).
gesetzt. Zudem wird die Software an Kunden lizenziert
6
< 2 Jahre 1 - 3 Beschäftigte
4 - 10 Beschäftigte 1%
6%
11 - 50 Beschäftigte 4%
2 - 5 Jahre 15% 9% > 1.000 Beschäftigte
> 10 Jahre
61% 47%
18% 26%
6 - 10 Jahre
51 - 250 Beschäftigte 14%
251 - 1.000 Beschäftigte
a) Frage: „Seit wie vielen Jahren sind Sie in der
Softwareentwicklung tätig?“ b) Frage: „Wie viele Beschäftigte hat das Unternehmen?“
N=256. N=256.
Software wird zur unternehmens-
55% Web (Front-end/Back-end) 66%
internen Nutzung entwickelt
Verkauf / Lizenzierung von Software Back-end
36% (z.B. Serverkonfigurationen)
59%
an externe Kunden / Unternehmen
Desktop 37%
Software wird inhouse im Auftrag eines
externen Unternehmens entwickelt 28%
Mobile 25%
Entsendung von Mitarbeitern
in andere Unternehmen 15% Embedded 14%
Sonstiges 6% Sonstiges 8%
0% 10% 20% 30% 40% 50% 60% 0% 10% 20% 30% 40% 50% 60% 70%
c) Frage: „Was ist das Geschäftsmodell des Unternehmens bezüglich der d) Frage: „Bei welchen Applikationen sind Sie an der Entwicklung
Softwareentwicklung?“ Mehrfachantwort möglich. beteiligt?“ Mehrfachantwort möglich.
N=256. N=256.
90%
80% 86%
< 30 Personen 81%
70%
16 - 30 Personen 4%
9% 1 - 5 Personen 60%
64%
50%
32%
52%
40%
30%
20%
10%
56% 0%
6 - 15 Personen
Anforderungs- Implementierung
Entwurf Betrieb
management & Tests
e) Frage: „Wie groß ist das Team, in dem Sie
(typischerweise) tätig sind?“
N=256. f) Die Entwickler*innen wurden pro Disziplin gefragt: „Sind Sie in dieser
Disziplin tätig?“ (Ja oder Nein). Im Diagramm ist jeweils der Anteil der
Ja-Stimmen abgebildet.
N=256.
.
Abbildung 1: Überblick über den beruflichen Hintergrund der befragten Entwickler*innen
7
Die Entwickler*innen unserer Studie nutzen ein breites
Spektrum an Entwicklungsumgebungen und Program-
miersprachen (vgl. Abbildung 2). Besonders häufig wer-
den IntelliJ und Eclipse eingesetzt. Darüber hinaus sind Java 63%
die Entwicklungsumgebungen Visual Studio und Visual
JavaScript / TS 47%
Studio Code ebenfalls weit verbreitet. Bei den Program-
miersprachen liegen die Sprachen Java, JavaScript/Type- SQL 37%
Script und C# auf den vorderen Plätzen (vgl. Abbildung 3). C# 22%
Durchschnittlich nutzen die Entwickler*innen zwei bis Python 18%
drei Programmiersprachen und zwei unterschiedliche
Entwicklungsumgebungen. C++ 17%
PHP 9%
C 9%
IntelliJ IDEA 49% Kotlin 8%
Eclipse 43% R 8%
Visual Studio Code 33% Go 7%
Visual Studio 29% Swift 4%
Notepad++ (oder
vergleichbar) 24% Ruby 1%
vi / vim 16% Rust 1%
Android Studio 8% Objective-C 1%
Xcode 5% Sonstige 13%
NetBeans 4%
0% 10% 20% 30% 40% 50% 60% 70%
Sonstige 13%
Frage: „Welche Sprachen nutzen Sie primär in Ihrem Team?“
Mehrfachantwort möglich.
0% 10% 20% 30% 40% 50% N=221
Frage: „Welche Entwicklungsumgebungen (IDE) nutzen Sie in Ihren
Projekten?“ Mehrfachantwort möglich.
N=221
Abbildung 2: Überblick über die verwendeten Entwick- Abbildung 3: Überblick über die verwendeten Program-
lungsumgebungen miersprachen
2.2 Führungskräfte und Product Owner
Im Rahmen der Interviews haben wir 17 Personen an- Die Unternehmen, für die die befragten FK und PO tätig
hand eines Leitfadens interviewt. Davon sind sieben sind, entwickeln für verschiedene Branchen Software
ausschließlich als Product Owner (PO) und sechs aus- (z.B. Automobil, Gesundheit und Versicherung). Darüber
schließlich als Führungskräfte (FK) tätig. Die restlichen hinaus gibt fast die Hälfte der befragten FK und PO an,
vier Personen haben beide Rollen inne. Alle interview- für mehr als eine Branche Software zu entwickeln.
ten Personen verfügen über mehr- oder langjährige
Berufserfahrung und haben stets direkten Kontakt zur Auch bei den Unternehmen der interviewten Personen
Softwareentwicklung. unterscheiden sich die Geschäftsmodelle. Die Software
wird für den internen Gebrauch, im direkten Kundenauf-
Ähnlich zu den Befragten der Online-Umfrage stammen trag oder für den lizenzierten Verkauf entwickelt. Zwei
die befragten FK und PO sowohl aus kleinen (2 Personen) interviewte Personen arbeiten zudem für Unternehmen,
und mittleren Unternehmen (10 Personen), sowie aus Un- die ihre Mitarbeitenden zu anderen Unternehmen ent-
ternehmen mit mehr als 250 Mitarbeitenden (5 Personen). senden.
83
ENTWICKLUNGSPROZESS
UND BETRIEB
dem alle Disziplinen um beispielhafte security-stärken-
Es ist ja nicht so, dass wir uns keinerlei Ge- de Maßnahmen ergänzt wurden. Damit soll sicherge-
danken über Sicherheit machen. Aber es ist stellt werden, dass möglichst früh in der Entwicklung
natürlich auch immer ein Aufwand, den der gravierende Schwachstellen gefunden werden. Dies
Mitarbeiter dann mit sich trägt. Den man im- senkt den Aufwand, Fehler zu beheben, signifikant. Doch
mer im Vergleich sehen muss. wie präsent ist das Thema Security bei den Entwick-
– Interviewteilnehmer*in ler*innen in den vier Disziplinen Anforderungsmanage-
ment, Entwurf, Implementierung & Tests sowie Betrieb?
Und wie gut sehen sich die Entwickler*innen, Product
Für ein sicheres Endprodukt ist der Entwicklungspro- Owner und Führungskräfte in ihren aktuellen Prozessen
zess, neben geeigneten Werkzeugen und kompetenten hinsichtlich Security aufgestellt? Mittels unserer Studie
Entwickler*innen (vgl. Kapitel 4 und 5), von entschei- haben wir diese drei Fragen beleuchtet. Dabei haben
dender Bedeutung. Daher ist die Idee des so genannten wir alle Teilnehmenden der Studie nach ihrer allgemei-
Security-by-Design-Ansatzes der Folgende: Im gesam- nen Einschätzung und zusätzlich die Entwickler*innen
ten Entwicklungsprozess wird Security von vornherein nach einer Einschätzung bezüglich der vier genannten
und durchgängig mitbetrachtet. In Abbildung 4 ist ein Disziplinen befragt.
hierzu passender Entwicklungsprozess¹ abgebildet, bei
Sicherer Entwurf & Penetrations- Härtung & sichere
$_
Risikoanalyse tests Konfiguration
Anforderungs- Implementierung
Initialisierung Entwurf Release Betrieb
management & Tests
Bedrohungs- Code-Review & Sicherer
analyse risikobasierte Tests Betrieb
Abbildung 4: Security-by-Design-Entwicklungsprozess
1
Für den Security-by-Design-Entwicklungsprozess ist es nicht relevant, ob das Produkt nach Wasserfall, V-Modell oder agil entwickelt wird.
Bei der agilen Entwicklung erfolgen die Phasen Anforderungsmanagement bis Inbetriebnahme innerhalb eines oder mehrerer Sprints.
93.1 Wird Security im Entwicklungsprozess systematisch berücksichtigt?
Wir haben die Entwickler*innen gefragt, ob und wie sie rity zuständig ist. Dies kann entweder daran liegen,
Security in ihrem Entwicklungsprozess adressieren (vgl. dass alle Personen des Teams Security berücksichtigen
Abbildung 5): 59% der befragten Entwickler*innen ge- sollen und daher niemand explizit zuständig ist oder
ben an, dass sie keine klaren Richtlinien und Prozes- aber auch, dass Security nicht explizit betrachtet wird.
se zur sicheren Softwareentwicklung haben und 41% , Unsere generelle Empfehlung ist, diese Verantwortlich-
dass ihre Security-Anforderungen (z.B. zur Verarbeitung keit einer konkreten Person zuzuweisen. Ein klares Auf-
sensibler Daten) nicht klar definiert bzw. bekannt sind. gabenverständnis ist wichtig, so dass die Person dafür
sorgen kann, dass auch alle im Team entsprechende
Darüber hinaus geben 56% der Entwickler*innen an, dass Achtsamkeit walten lassen.
ihre Sammlung an Werkzeugen unpassend ist. Dies kann
daran liegen, dass keine passenden Werkzeuge am Markt Basierend auf der Einschätzung der Entwickler*innen
verfügbar sind, aber auch daran, dass bessere Werkzeuge wird Security von vielen Teams nicht systematisch be-
nicht genutzt werden können bzw. dürfen oder dass bis- rücksichtigt. Somit ergibt sich ein hohes Risiko, dass
her nicht nach besseren Werkzeugen gesucht wurde. diese eine dauerhaft hohe Qualität ihrer Softwarepro-
dukte nicht gewährleisten können.
Zudem geben 62% der Entwickler*innen an, dass es
in ihrem Team keine feste Person gibt, die für Secu-
ja nein ich weiß es nicht
Wir haben klar definierte Richtlinien und 39%
Prozesse zur sicheren Softwareentwicklung. 59%
N=208
2%
Security-Anforderungen (z.B. zur Verarbeitung 57%
sensibler Daten) sind klar definiert bzw.
bekannt. 41%
N=134 1%
Wir haben eine passende Sammlung an 40%
Werkzeugen, um Software sicher zu
entwickeln. 56%
N=221 4%
In unserem Team gibt es fest definierte 37%
Personen, die für die Security zuständig
sind.
62%
N=256 2%
0% 10% 20% 30% 40% 50% 60% 70%
Die Anworten „ja“ und „nein“ fassen sich zusammen aus den Anwortmöglichkeiten „stimme voll zu“ und „stimme
eher zu“ sowie aus „stimme eher nicht zu“ und „stimme gar nicht zu“.
Abbildung 5: Berücksichtigung von Security im Entwicklungsprozess
In den Interviews mit den Führungskräften (FK) und Pro- ringe oder gar keine Rolle spielt. Insgesamt wird Securi-
duct Ownern (PO) hat sich gezeigt, dass Security im Soft- ty im Softwareentwicklungsprozess somit typischerweise
wareentwicklungsprozess keine hohe, sondern eher eine unsystematisch, also ohne Festschreibung von konkreten
niedrige bis mittlere Priorität besitzt. Mehrheitlich wird Maßnahmen, behandelt. Hierdurch ergibt sich ein erhöh-
auf den Pen-Test² verwiesen, der jedoch erst nach der Ent- tes Risiko für die Qualität der entstehenden Produkte.
wicklung stattfindet. Eine systematische Berücksichtigung
der Security während der Entwicklung, wie beispielsweise
durch die Verwendung von Checklisten, mittels einer fes- Security fängt meistens bei den ganzen Pro-
ten Zuordnung von Verantwortung oder durch explizite zessen erst am Ende an. Wobei ich immer das
Security-Richtlinien, ist nur sehr selten anzutreffen. Zu- Gefühl habe, es müsste schon sehr viel früher
dem haben die meisten PO angegeben, dass in den agilen einsetzen. – Interviewteilnehmer*in
Meetings (Planning, Retro, Review) Security nur eine ge-
2
Ein Pen-Test (Penetration Test) wird typischerweise vor dem Release einer Software durchgeführt – oftmals durch Dritte. Hierbei wird das fertige
Produkt ausgeführt und auf Schwachstellen überprüft (bspw. falsche Konfigurationen, schlechte Passwörter, Angriffssicherheit gegen Standardangriffe).
103.2 Wird Security in den einzelnen Disziplinen systematisch berücksichtigt?
Von den in der Disziplin Anforderungsmanagement in- Einen Security-Experten, der die aufgenommen An-
volvierten Entwickler*innen geben zwei Drittel (67%) forderungen hinsichtlich Security überprüft, haben nur
an, dass auf Security geachtet wird (vgl. Abbildung 6). Al- 35% der Entwickler*innen im Team. Dabei würde gerade
lerdings haben nur 24% Vorlagen bzw. Standards für die eine klar benannte und hierfür ausgebildete Person da-
Aufnahme von Security- Anforderungen. Somit scheinen bei helfen, dass die Security-Anforderungen vollständig
die Anforderungen, falls sie überhaupt betrachtet wer- und sinnvoll sind, um so frühzeitig die Basis für ein si-
den, bei einem Großteil der Entwickler*innen unsyste- cheres Produkt zu legen.
matisch betrachtet zu werden. Eine systematische Vor-
gehensweise würde das Endprodukt verbessern, da es
die Gefahr senkt, dass Anforderungen falsch formuliert
oder vergessen werden.
ja nein ich weiß es nicht
Wird während des Anforderungs- 67%
managements auf den Aspekt
Security geachtet? 29%
N=164 5%
Gibt es Vorlagen bzw. Standards für die 24%
Erstellung von Security-Anforderungen? 62%
N=164
14%
Haben Sie einen Security-Experten, 35%
der Ihre Anforderungen überprüft? 60%
N=164
5%
0% 10% 20% 30% 40% 50% 60% 70%
Abbildung 6: Berücksichtigung der Security in der Disziplin Anforderungen
Bei dem Entwurf zeichnet sich ein ähnliches Bild wie jedoch haben nur 24% Vorlagen bzw. Standards. Zur
beim Anforderungsmanagement ab (vgl. Abbildung 7). Überprüfung der Sicherheit des Entwurfs haben erneut
So geben 77% der Entwickler*innen an, während des nur 32% der Entwickler*innen einen Experten.
Entwurfs des Softwaresystems auf Security zu achten,
ja nein ich weiß es nicht
Wird in Ihrem Team während des Entwurfs 77%
auf den Aspekt Security geachtet? 21%
N=208
2%
Gibt es Vorlagen bzw. Standards für die 24%
Erstellung eines sicheren Entwurfs? 68%
N=208
9%
Haben Sie einen Security-Experten, der 32%
Ihren Entwurf überprüft? 63%
N=208
5%
0% 10% 20% 30% 40% 50% 60% 70% 80%
Abbildung 7: Berücksichtigung der Security in der Disziplin Entwurf
11In der Disziplin Implementierung und Test haben 75% rity-Eigenschaften von ihrem entwickelten Produkt
der Entwickler*innen angegeben auf Security zu ach- eingehalten werden, haben 25% der Entwickler*innen
ten (vgl. Abbildung 8). Dabei setzen 27% der Entwick- einen entsprechenden Prozess. Ein finales Security-Re-
ler*innen entsprechende Vorlagen und Standards als view vor einem Release wird nur von 16% der Entwick-
Hilfestellung ein. Um sicherzustellen, dass alle Secu- ler*innen durchgeführt.
ja nein ich weiß es nicht
Wird während der Implementierung 75%
auf den Aspekt Security geachtet? 20%
N=221
5%
Gibt es Vorlagen bzw. Standards für die 27%
Erstellung von sicherem Code? 66%
N=221
7%
Haben Sie ein definiertes Vorgehen, um die 25%
Einhaltung von Security-Eigenschaften im
Code zu überprüfen? 69%
N=221 5%
Gibt es bei Ihnen ein finales 16%
Security-Review vor einem Release?
77%
N=134
7%
0% 10% 20% 30% 40% 50% 60% 70% 80%
Abbildung 8: Berücksichtigung der Security in der Disziplin Implementierung und Test
Auf unsere Frage nach dem Zeitpunkt, wann die Software während des Sprints (20%), sowie vereinzelte sonstige
bezüglich Security analysiert wird, haben wir mehrere Zeitpunkte (7%), wie beispielsweise nach dem Release
Antwortmöglichkeiten zugelassen, da ein mehrmaliges oder bei durchgeführten Pen-Tests. Somit lässt sich
Analysieren sehr empfehlenswert ist (vgl. Abbildung 9). insgesamt feststellen, dass die absolute Mehrheit der
So gibt knapp die Hälfte (48%) der Entwickler*innen an, Entwickler*innen ihre Software mindestens an einem
dass dies bereits während des Programmierens passiert. Punkt im Hinblick auf Security analysiert. Allerdings ge-
Ein weiterer beliebter Zeitpunkt zur Analyse der Security ben auch 20% der Entwickler*innen an, ihre Software
ist vor jedem Release (37%). Weitere Zeitpunkte waren nie hinsichtlich Security zu analysieren.
vor einem Check-in (10%), nach einem Check-in (20% ),
50%
48%
40%
37%
30%
20%
20% 20% 20%
10%
10%
7%
0%
Während der Vor jedem Check-in Nach jedem Check-in Innerhalb des Vor dem Release Nie Sonstiges
Implementierung durch einen Server gleichen Sprints der Software
Frage: „Wann wird bei Ihnen die Software bzgl. Security analysiert?“
Mehrfachantwort möglich. N=221.
Abbildung 9: Wann wird die Software bzgl. Security analysiert?
12Während des laufenden Betriebs der Software gibt es werden, geben 40% der Entwickler*innen an, dies mit-
bei 22% der Entwickler*innen automatisierte Security- zubekommen. Zudem sagen ebenfalls 40% der Entwick-
Checks (vgl. Abbildung 10). 28% führen automatische ler*innen, dass sie klare Richtlinien zum Umgang mit
Security-Checks nach einem Release durch. Für den (potenziellen) Sicherheitslücken, Angriffen, Datenlecks,
Fall, dass Sicherheitsprobleme (z.B. bzgl. genutzter Bi- etc. im Betrieb haben.
bliotheken) im Betrieb befindlicher Produkte gefunden
ja nein ich weiß es nicht
Wird die Security im laufenden Betrieb 22%
automatisch geprüft? 68%
N=134
10%
Gibt es automatische Security-Checks 28%
nachdem ein Release gebaut ist? 66%
N=134
5%
Bekommen Sie mit, ob für Ihre im Betrieb
befindlichen Produkte Sicherheitsprobleme 40%
gefunden wurden (z.B. bzgl. 48%
genutzter Bibliotheken)?
N=134
12%
Haben Sie ein definiertes Vorgehen, um 40%
auf potenzielle Sicherheitslücken,
Angriffe, Datenlecks, etc. zu reagieren? 49%
N=134 12%
0% 10% 20% 30% 40% 50% 60% 70%
Abbildung 10: Berücksichtigung der Security in der Disziplin Betrieb
Um weitere Informationen zum Vorgehen bei einem Si-
cherheitsvorfall zu erlangen, haben wir die Führungs- Das kann der Herr […] ganz sicher beantwor-
kräfte (FK) und Product Owner (PO) hiernach befragt. ten. Das ist unser Datenschutzbeauftragter und
Ein Drittel gibt an, keine Prozesse und Verantwortlich- der kennt den Prozess auf jeden Fall. Ich selbst
keiten zu haben bzw. kennt sie nicht. Bei einem Viertel bin da nicht verantwortlich und kenne den
sind die Prozesse und unternehmensweiten Verant- Prozess auch ehrlich gesagt nicht konkret.
wortlichkeiten weitestgehend geregelt, wobei weder – Interviewteilnehmer*in
die befragten FK und PO noch deren Entwickler*innen
konkrete Verantwortlichkeiten innerhalb eines Product
Security Incident Response Teams (PSIRT)³ haben. Bei Insgesamt decken sich somit die Angaben der FK und PO
den restlichen FK und PO sind die Prozesse und Ver- mit denen der Entwickler*innen, dass mehrheitlich die
antwortlichkeiten nur teilweise geregelt bzw. bekannt, Prozesse und Verantwortlichkeiten für einen Sicherheits-
wobei meist nur auf einen Datenschutzbeauftragten vorfall nicht gut genug definiert sind. Dabei ist dies insbe-
verwiesen wird. Diese Rolle ist jedoch klassisch nicht sondere für das schnelle Reagieren auf neu entdeckte und
für die Angriffssicherheit zuständig oder verantwort- gemeldete Schwachstellen wichtig. So kann beispiels-
lich und somit auch nicht diesbezüglich geschult. Eine weise durch einen professionellen Umgang mit bekannt-
persönliche Beteiligung der FK und PO in einem Pro- gewordenen Schwachstellen schlechte Presse vermieden
zess zur Behebung von Sicherheitsvorfällen ist insge- und verlorenes Vertrauen wiederhergestellt werden.
samt selten.
3
Ein Product Security Incident Response Team ist innerhalb einer Organisation rund um das Auftreten von Sicherheitsvorfällen in Produkten tätig.
Dazu gehört sowohl die Prävention durch entsprechende Awareness schaffende Maßnahmen und Fortbildungen/Schulungen, aber
insbesondere auch das schnelle Reagieren und Beheben von neu entdeckten Schwachstellen. Zu diesem Zweck koordinieren die Teams
Abläufe und Kommunikationswege innerhalb der eigenen Organisation unter Einbindung der meldenden Personen.
133.3 Sind die derzeitigen Prozesse geeignet, um Software sicher zu entwickeln?
Befragt nach dem Gesamtprozess meinen 64% der Ent- Dieser vermeintliche Widerspruch mag darin begrün-
wickler*innen, dass in ihrem Team nicht genügend Zeit det liegen, dass eine sichere Softwareentwicklung nicht
für die sichere Softwareentwicklung investiert wird (vgl. hoch priorisiert wird. Dadurch empfinden die Entwick-
Abbildung 11). Dennoch sind 62% der Entwickler*innen ler*innen zwar, dass zu wenig Zeit für eine sichere Soft-
der Meinung, dass ihr gesamter Entwicklungsprozess wareentwicklung investiert wird, sehen dies aber auch
und die dazugehörigen Werkzeuge – unabhängig vom nicht als Problem, da die aktuellen Prozesse gefühlt
Thema Security – für ihre Bedürfnisse passend sind. funktionieren.
ich stimme zu ich stimme nicht zu ich weiß es nicht
Für das Thema „sichere Softwareentwicklung“ 35%
wird in unserem Team genügend
Zeit investiert. 64%
N=256. 2%
Unser Entwicklungsprozess und die 62%
dazugehörigen Werkzeuge sind für unsere
Bedürfnisse passend. 34%
N=256. 4%
0% 10% 20% 30% 40% 50% 60% 70%
Die Anworten „ich stimme zu“ und „ich stimme nicht zu“ fassen sich zusammen aus den Anwortmöglichkeiten
„stimme voll zu“ und „stimme eher zu“ (zu „ich stimme zu“) sowie aus „stimme eher nicht zu“ und „stimme gar
nicht zu“.
Abbildung 11: Eignung der derzeitigen Prozesse
Im Vergleich der verschiedenen Disziplinen lässt sich rung & Tests sowie 78% im Betrieb). Daraus lässt sich
ein starker gemeinsamer Trend erkennen (vgl. Ab- ableiten, dass die Prozesse für einen kleinen Teil der
bildung 12): Genauere und verständlichere Prozesse Entwickler*innen funktionieren mögen, aber über alle
wünschen sich stets deutlich mehr als zwei Drittel der Disziplinen hinweg genauere und verständlichere Pro-
Entwickler*innen (77% in der Disziplin Anforderungs- zesse benötigt werden.
management, 81% im Entwurf, 80% bzgl. Implementie-
ich stimme zu ich stimme nicht zu ich weiß es nicht
77%
Anforderungen 16%
N=164
9%
81%
Entwurf 16%
N=208
3%
80%
Implementierung & Tests 15%
N=221
5%
78%
Betrieb 18%
N=134 4%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
Fragen: „Unsere gegenwärtigen Prozesse sollten genauer und verständlicher sein?“ Die Teilnehmenden wurden je Disziplin hierzu
befragt. Die Antworten „ich stimme zu“ und „ich stimme nicht zu“ fassen sich zusammen aus den Antwortmöglichkeiten „stimme voll
zu“ und „ stimme eher zu“ sowie aus „stimme eher nicht zu“ und „stimme gar nicht zu“.
Abbildung 12: Beurteilung der Genauigkeit und Verständlichkeit der Prozesse in den jeweiligen Disziplinen
143.4 Zwischenfazit
Die Studienteilnehmer*innen sind sich einig, dass unzutreffende Selbsteinschätzung vor, wenn sie sagen,
die aktuellen Prozesse für eine sichere Softwareent- dass auf Security geachtet wird. Eine mögliche Erklä-
wicklung und einen sicheren Betrieb stark verbesse- rung hierfür könnte darin liegen, dass den meisten Be-
rungswürdig sind. Dies belegen die Antworten aller teiligten nicht bewusst ist, was es für Möglichkeiten
Disziplinen nach einem Wunsch für verständlichere zur sicheren Softwareentwicklung gibt.
und genauere Prozesse (jeweils ~80%), das Empfinden
der meisten Entwickler*innen, dass zu wenig Zeit für Besorgniserregend ist darüber hinaus, dass 20% der
sichere Softwareentwicklung investiert wird (~60%), Entwickler*innen einräumen, während der Implemen-
aber auch die nur sehr wenig eingesetzten Maßnah- tierung und Tests nicht auf Security zu achten.
men (Vorlagen, Standards, Experten) für eine sichere
Softwareentwicklung, was die Führungskräfte und
Product Owner in den Interviews ebenfalls bestätigt Funktionalität vor Sicherheit. Es ist immer
haben. wichtiger, dass der Button von grün auf blau
wird, anstatt dass man nochmal ein Penetra-
Obwohl die Entwickler*innen angeben, dass auf Secu- tionstest über die Anwendung gehen lässt oder
rity geachtet wird, werden nur selten Maßnahmen um- dergleichen. Weil das eine bringt Geld, macht
gesetzt, um eine systematische sichere Softwareent- die Benutzer zufrieden, und das andere, da hat
wicklung zu gewährleisten. Ohne diese Maßnahmen man erst mal gar nichts von.
ist jedoch eine solche Gewährleistung sehr unwahr- – Interviewteilnehmer*in
scheinlich. Somit liegt bei den Entwickler*innen eine
154
WERKZEUGE
Einige Werkzeuge tragen insbesondere zur Gewährleis-
Also ich finde es total gut und wichtig, wenn tung der Security von Softwareprodukten bei, indem sie
wir Tools haben, die wir einsetzen können, so- Entwickler*innen bei der systematischen Überprüfung
wohl in der Entwicklungsumgebung, aber auch von Security-Anforderungen, der Generierung von siche-
noch viel stärker in unserer Build-Pipeline. ren Code-Snippets oder dem Aufspüren von Schwach-
– Interviewteilnehmer*in stellen zu unterstützen. Durch diese Unterstützung kann
die Anzahl an Security-Fehlern deutlich reduziert und die
Sicherheit der Anwendung gesteigert werden.
Werkzeuge sind in der heutigen Softwareentwicklung
ein entscheidender Bestandteil zur erfolgreichen Um- Neben all den Vorteilen hat der Einsatz von Werkzeugen
setzung von Projekten. Sie unterstützen Entwickler*in- allerdings auch Grenzen: Verschiedene Studien haben ge-
nen, Fehler zu vermeiden bzw. frühzeitig zu finden und zeigt, dass zu viele oder unsystematisch eingesetzte Werk-
zu beheben. Zusätzlich können durch Werkzeuge manu- zeuge dazu führen, dass die Qualität der Software langfris-
elle und zeitaufwändige Tätigkeiten automatisiert wer- tig sinkt. Dies trifft insbesondere auf den Aspekt Security
den, wodurch nicht nur Zeit eingespart, sondern auch zu4.
Fehler deutlich reduziert werden können. Insgesamt
führt ein systematischer Einsatz von Werkzeugen ent- In der vorliegenden Studie haben wir daher untersucht,
lang des Entwicklungsprozesses zu einer effizienteren inwieweit Werkzeuge heutzutage in der Entwicklung ge-
Entwicklung bei gleichzeitiger Steigerung der Qualität. nutzt werden. Zusätzlich haben wir ermittelt, welcher
Bedarf bezüglich solcher Werkzeuge besteht.
4.1 Nutzen Entwickler*innen Werkzeuge zur sicheren Softwareentwicklung?
Die befragten Entwickler*innen geben an, dass sie werden häufig Ticketsysteme (z.B. Atlassian Jira) oder
Werkzeuge entlang des gesamten Entwicklungspro- Microsoft Excel zur Dokumentation genutzt. Darüber hi-
zesses nutzen, jedoch in unterschiedlicher Intensität naus werden Ergebnisse von Security-Analysen aus vor-
(vgl. Abbildung 13). In den Disziplinen vor der Imple- herigen Releases betrachtet, um weitere Security-An-
mentierung (Anforderungsmanagement und Entwurf) forderungen zu erheben und im Entwurf entsprechende
werden vergleichsweise selten Werkzeuge eingesetzt. Eigenschaften zu berücksichtigen. 50% der befragten
Im Anforderungsmanagement nutzen 18% der Entwick- Entwickler*innen, die Werkzeuge nutzen, um Securi-
ler*innen Werkzeuge zur Erhebung und Dokumentation ty-Anforderungen zu erheben bzw. zu erfassen, nutzen
von Security-Anforderungen. Im Entwurf setzen 14% auch gleichzeitig Werkzeuge, um ihre Security-Anforde-
der Entwickler*innen Werkzeuge zur Dokumentation rungen automatisch zu analysieren. Somit können sie
von Security-Eigenschaften ein. In beiden Disziplinen frühzeitig Fehler finden und beheben.
4
https://www.heise.de/news/Studie-Mehr-Tools-weniger-Sicherheit-4799924.html
16ja nein ich weiß es nicht
7% 6% 9% 5% 6% 6%
14%
18%
76% 85% 81% 88%
Frage: „Nutzen Sie Werkzeuge, Frage: „Nutzen Sie Werkzeuge, Frage: „Nutzen Sie Werkzeuge, Frage: „Nutzen Sie Werkzeuge,
um Security-Anforderungen zu um Security-Anforderungen um Security-Eigenschaften im um Security-Eigenschaften im
erheben bzw. zu erfassen?“ automatisch zu analysieren (z.B. Entwurf zu erheben bzw. zu Entwurf automatisch zu
N=164 bzgl. Konsistenz)?“ erfassen?“ analysieren (z.B. bzgl.
N=164 N=208 Konsistenz)?“
N=208
5% 10% 5%
22% 28%
35%
52% 48%
68%
66%
61%
Frage: „Nutzen Sie Werkzeuge, Frage: „Nutzen Sie aktuell in Frage: „Wird die Security im Frage: „Gibt es automatische
um Security-Eigenschaften im Ihrem Team statische laufenden Betrieb automatisch Security-Checks nachdem ein
Code automatisch zu Codeanalyse- überprüft?“ Release gebaut ist?“
überprüfen?“ werkzeuge?“ N=134 N=134
N=220 N=220
Abbildung 13: Heutige Werkzeugnutzung zur sicheren Softwareentwicklung
Während der Implementierung nutzen 35% der befrag- im Code hartcodierte Passwörter befinden. Darüber hi-
ten Entwickler*innen Werkzeuge, um Security-Eigen- naus gibt es auch spezielle Werkzeuge zur statischen
schaften automatisch zu überprüfen. Darüber hinaus Analyse, mit denen komplexere Eigenschaften im Code
gibt ein Großteil der Entwickler*innen an, Werkzeuge geprüft werden können. Mit diesen Werkzeugen kann
zur statischen Codeanalyse einzusetzen (52% ). Mit Hil- zum Beispiel geprüft werden, ob Benutzereingaben vor
fe von statischen Codeanalysewerkzeugen lassen sich ihrer Weiterverarbeitung überprüft werden oder ob APIs
verschiedene Eigenschaften im Code automatisch ana- korrekt genutzt werden. Allerdings setzen nur 50% der
lysieren, ohne ihn ausführen zu müssen. Beispielsweise Entwickler*innen, die statische Codeanalysewerkzeu-
können security-relevante Eigenschaften, aber auch der gen nutzen, diese Werkzeuge zur Analyse von Security-
Programmierstil oder doppelter Code erkannt werden. Eigenschaften ein.
Am häufigsten nutzen die Entwickler*innen die stati-
schen Codeanalysewerkzeuge SonarQube und Find- Ein ähnliches Bild zeigt sich auch bei der Verwendung
Bugs. Beide Werkzeuge definieren standardmäßig u.a. von Werkzeugen während des Betriebs der Software.
security-relevante Regeln. 22% der befragten Entwickler*innen geben an, dass die
Security im laufenden Betrieb automatisch geprüft wird.
Mit den meisten statischen Codeanalysewerkzeugen Zudem analysieren 28% der befragten Entwickler*innen
lassen sich bereits einfache Security-Eigenschaften im automatisch ein Release auf mögliche Schwachstellen.
Code analysieren. Dazu gehört die Überprüfung, ob sich
174.2 Wie ist die Meinung der Führungskräfte und Product Owner zum
Thema Werkzeuge zur sicheren Softwareentwicklung?
Im Allgemeinen sehen die Führungskräfte (FK) und gen. Darüber hinaus können die Entwickler*innen bei
Product Owner (PO) einen hohen Bedarf an passenden den meisten Unternehmen ihre präferierten kostenfrei-
Werkzeugen zur sicheren Softwareentwicklung bei ih- en Werkzeuge selbst beschaffen und nutzen.
ren Entwickler*innen und stehen einer Anschaffung und
Einführung offen gegenüber. Befragt zu ihren Entwickler*innen geben die meisten FK
und PO an, dass diese nur Werkzeuge nutzen, von denen
Alle befragten FK und PO geben an, dass ihre Entwick- sie selbst überzeugt sind. Dadurch kann es vorkommen,
ler*innen sowohl kommerzielle als auch kostenlose dass für den gleichen Zweck unterschiedliche Werkzeuge
Werkzeuge einsetzen. Des Weiteren sind sie sich einig, im Einsatz sind – insbesondere wenn es mehrere kos-
dass beim Thema Werkzeuge nicht die Kosten im Vor- tenfreie Alternativen gibt. Hierbei ergibt sich somit das
dergrund stehen, sondern der Mehrwert, der durch die Risiko, dass diese Werkzeuge weniger zielgerichtet ein-
Nutzung der Werkzeuge erzielt werden kann. Zudem gesetzt werden. Nur ein PO hat angegeben, dass die Nut-
haben die FK und PO keine negativen Meinungen oder zung von kostenlosen Werkzeugen regelmäßig diskutiert
Vorurteile bzgl. der Nutzung von kostenfreien Werkzeu- wird und Richtlinien für die Nutzung erstellt werden.
Da sind die Entwickler frei, die Werkzeuge zu nutzen, die sie für gut halten. Natürlich gibt es dann
immer mal wieder Runden, in denen die Werkzeuge vorgestellt werden und die Vor- und Nachteile der
verschiedenen Werkzeuge miteinander verglichen werden. – Interviewteilnehmer*in
Für die Anschaffung von kostenpflichtigen Werkzeugen • Die Entwickler*innen haben zwar Bedarf an besseren
verfügen die befragten FK und PO in der Regel über Werkzeugen, allerdings haben sie bisher noch nicht
ausreichend Budget. Allerdings achten sie hier anders nach passenden Werkzeugen recherchiert.
als bei dem Einsatz von kostenfreien Werkzeugen genau
auf den Mehrwert, der bei der Nutzung der Werkzeuge • Die Entwickler*innen und FK und PO sprechen nicht
entsteht. Erst wenn die Entwickler*innen den Mehr- oder nur selten über das Thema Werkzeuge. Dadurch
wert ausreichend begründen können, unterstützen die kommt es zu keiner Verbesserung der Situation.
befragten FK und PO die Anschaffung. Zudem wird im
Falle einer Anschaffung häufig verlangt, dass die Ent- • Es fehlt die Übersicht über das Spektrum, welches mit
wickler*innen diese Werkzeuge auch einsetzen müssen. Werkzeugen abgedeckt werden kann, oder das Ver-
ständnis für Security-Themen.
Allerdings berichteten die FK und PO, dass ihre Ent-
wickler*innen nur sehr selten vorschlagen, ein kosten-
pflichtiges Werkzeug zu beschaffen. Dieser Widerspruch Auch da könnte ich nur mutmaßen weil die-
kann verschiedene Gründe haben: se Frage (Anmerkung der Redaktion: Bedarf für
mehr Security-Werkzeuge) von den Entwick-
• Die Auswahl an kostenfreien Werkzeugen ist für die lern noch nicht an mich herangetragen wurde.
Bedürfnisse der Entwickler*innen bereits passend. Ich würde aber mutmaßen, dass sie über jede
Form der Unterstützung sehr dankbar wären.
• Am Markt befindliche, kostenpflichtige Werkzeuge Ich gehe davon aus, dass sie auch ein Interes-
sind für die befragten Entwickler*innen nicht geeig- se daran haben, möglichst sichere Software zu
net. Dies könnte z.B. die Benutzbarkeit, die Perfor- entwickeln. Aber wenn ich ehrlich bin, müsste
mance oder fehlende Funktionen betreffen. Obwohl ich sagen, ich habe so eine Frage von den Ent-
Bedarf und Budget vorhanden sind, werden daher kei- wicklern noch nicht gestellt bekommen.
ne weiteren Werkzeuge angeschafft. – Interviewteilnehmer*in
184.3 Welchen Bedarf haben die Entwickler*innen?
Befragt nach dem Entwicklungsprozess und den dazu- ob sie eine passende Sammlung an Werkzeugen haben,
gehörigen Werkzeugen sind knapp zwei Drittel (62%) um Software sicher zu entwickeln. Hier geben nur noch
der Entwickler*innen der Meinung, dass diese für ihre 40% an, dass dies der Fall ist während die Mehrheit
Bedürfnisse passend sind. Ein Drittel (34%) widerspricht (56%) dies verneint. Somit besteht laut den Entwick-
dieser Aussage jedoch (vgl. Abbildung 14). In einer zwei- ler*innen ein deutlicher Bedarf an mehr bzw. besseren
ten Frage haben wir daher die Entwickler*innen gefragt, Werkzeugen.
ich stimme zu ich stimme nicht zu ich weiß es nicht
Unser Entwicklungsprozess und die 62%
dazugehörigen Werkzeuge sind für unsere 34%
Bedürfnisse passend.
4%
Wir haben eine passende Sammlung an 40%
Werkzeugen, um Software sicher zu 56%
entwickeln.
4%
0% 10% 20% 30% 40% 50% 60% 70%
Die Anworten „ich stimme zu“ und „ich stimme nicht zu“ fassen sich zusammen aus den Anwortmöglichkeiten
„stimme voll zu“ und „stimme eher zu“ sowie aus „stimme eher nicht zu“ und „stimme gar nicht zu“. N=256.
Abbildung 14: Eignung der heutigen Werkzeuge zur sicheren Softwareentwicklung
Der Mangel an adäquaten Werkzeugen fällt in den ein- Werkzeugen hoch ist (56% bzw. 64% , vgl. Abbildung 15),
zelnen Entwicklungsdisziplinen jedoch unterschiedlich sind 72% der Meinung, dass bessere Werkzeuge für die
aus. Während in den Disziplinen Anforderungsmanage- Implementierung dabei helfen würden, die Aufgaben
ment und Entwurf der Bedarf nach mehr bzw. besseren besser zu erledigen.
ich stimme zu ich stimme nicht zu ich weiß es nicht
56%
Anforderungsmanagement
N=164
31%
13%
64%
Entwurf der Applikation
N=208
26%
11%
Implementierung & Tests 72%
19%
N=221
9%
0% 10% 20% 30% 40% 50% 60% 70% 80%
Frage: „Mehr bzw. bessere Werkzeuge würden uns helfen, unsere Aufgaben besser zu erfüllen.“ Die Teilnehmenden wurden je
Disziplin hierzu befragt. Die Anworten „ich stimme zu“ und „ich stimme nicht zu“ fassen sich zusammen aus den Anwortmöglich-
keiten „stimme voll zu“ und „stimme eher zu“ sowie aus „stimme eher nicht zu“ und „stimme gar nicht zu“.
Abbildung 15: Bedarf an Werkzeugen zur sicheren Softwareentwicklung
194.4 Zwischenfazit
Werkzeuge sind ein wichtiger Bestandteil einer erfolg- Ein weiteres Ergebnis der Studie im Bereich Werkzeuge
reichen sicheren Softwareentwicklung. Die befragten ist, dass die Entwickler*innen einen hohen ungedeckten
Entwickler*innen, Führungskräfte (FK) und Product Ow- Bedarf an Werkzeugen haben, obwohl es von Seiten der
ner (PO) sehen ebenfalls die Bedeutung dieses Themas. befragten FK und PO genügend Budget gibt, Werkzeuge
Allerdings hat sich gezeigt, dass die Verbreitung und anzuschaffen.
Nutzung von Werkzeugen vor allem in den frühen Ent-
wicklungsdisziplinen sehr gering ist. Selbst während Bei der Nutzung von kostenfreien Werkzeugen sollte
der Implementierung setzt ein großer Teil keine Werk- zudem mehr darauf geachtet werden, dass eine Abstim-
zeuge zur sicheren Softwareentwicklung ein. Dadurch mung innerhalb des Teams geschieht sowie die Werk-
fallen viele Fehler erst spät in der Entwicklung oder zeuge nutzenstiftend eingesetzt und gut in die beste-
nach dem Release auf, wodurch teure und zeitintensive henden Prozesse integriert werden können.
Reparaturen notwendig sind5. Zudem steigt das Risiko,
dass im Produktiveinsatz Sicherheitsvorfälle geschehen.
5
Quelle: NIST Planning Report 02-3, „The Economic Impacts of Inadequate Infrastructure for Software Testing“, 2002, Page 5-4.
205
SECURITY-KOMPETENZ
Die Security-Kompetenz aller Beteiligten (Entwick-
ler*innen, Führungskräfte und Product Owner) ist ein Kompetenz kann man nie genug haben. Das
entscheidender Baustein, um das Thema Security wäh- Lernen hört nie auf. – Interviewteilnehmer*in
rend der Entwicklung systematisch und vollständig zu
adressieren. Wir haben daher alle Teilnehmenden der
Studie um eine Selbsteinschätzung gebeten und sie ge- Kompetenzen besitzen sollte und ob die Kompetenzen
fragt, welche Kompetenzen heute vorliegen, wer welche des Teams heute ausreichen.
5.1 Wie schätzen sich die Entwickler*innen jeweils selbst ein?
Um eine Selbsteinschätzung der Entwickler*innen zu bedeutende Angriffsart Injection7 zählt, ist dieser ver-
ihrer Security-Kompetenz zu erhalten, haben wir ent- gleichsweise hohe Wert erfreulich. In allen anderen
lang des Entwicklungsprozesses (vgl. Abbildung 4) die Themengebieten haben die Entwickler*innen deutlich
Maßnahmen zur sicheren Softwareentwicklung in zehn weniger praktische Erfahrungen. So sind es im Themen-
Themengebiete gegliedert6 und diese den Disziplinen gebiet Patch Management nur noch 42%. In den ver-
Anforderungsmanagement, Entwurf, Implementierung bleibenden Themengebieten haben zwischen 36% und
& Test und Betrieb zugeordnet. Die Aufgabe der Ent- 21% der Entwickler*innen praktische Erfahrungen.
wickler*innen war es, jeweils einzuschätzen, ob sie
selbst die Themengebiete und deren Konzepte kennen Bzgl. der praktischen Erfahrungen ist auffällig, dass alle
und, falls ja, ob sie praktische Erfahrungen hierzu ge- vier Themengebiete der Disziplin Implementierung so-
sammelt haben. Die Umfrage zielt somit auf die Frage wie das Themengebiet Pen-Tests in der oberen Hälfte
ab, ob die Entwickler*innen grundlegende Kompeten- von Abbildung 16 zu finden sind. Hingegen sind alle
zen und Erfahrungen haben und nicht, ob sie Expert*in- anderen Themengebiete (alles was vor oder nach der
nen in den jeweiligen Themengebieten sind. Implementierung stattfindet) in der unteren Hälfte der
Tabelle zu finden. Wir schlussfolgern daraus, dass dem
Abbildung 16 zeigt die Ergebnisse der Selbsteinschät- Thema Security während der Implementierung mehr
zung sortiert nach dem Anteil an praktischen Erfah- Priorität und Zeit im Vergleich zu den anderen Diszipli-
rungen (Spalte 4). Das bekannteste Themengebiet mit nen eingeräumt wird. Für eine sichere Softwareentwick-
praktischen Erfahrungen ist die Eingabeprüfung, die lung wäre es jedoch notwendig, dass auch die anderen
beim Einlesen von Daten stets durchgeführt werden Disziplinen mehr Priorität und Zeit für das Thema Secu-
sollte (61%). Da zu diesem Themengebiet auch die rity erhalten.
6
Diese Themengebiete sind nicht vollumfänglich, decken aber ein sehr großes Spektrum der sicheren Softwareentwicklung ab.
7
Unter anderem wird Injection von der OWASP Foundation als höchstes Risiko für Webanwendungen eingestuft:
https://owasp.org/www-project-top-ten/
21Dass der Pen-Test sich ebenfalls in der oberen Tabellen- aufzeigen. Darüber hinaus ist seine Durchführung meist
hälfte befindet, entspricht unserer Erwartungshaltung, auf wenige Tage begrenzt (Angreifer haben diese Be-
da dieser eine weit verbreitete Maßnahme ist, um die schränkung nicht) und er untersucht nicht, ob bereits
Security eines Softwareprodukts vor einem Release zu die Anforderungen oder der Entwurf eine Schwachstel-
prüfen. Ein Pen-Test hat jedoch auch viele Beschrän- le enthalten. Es sind somit alle Themengebiete relevant
kungen: Beispielsweise kann er – wie alle Testverfahren und nicht nur das Themengebiet Pen-Test.
– nur Fehler aufdecken und nicht deren Abwesenheit
Themengebiet und Themengebiet und
Themengebiet Konzepte bekannt, keine Konzepte bekannt und Themengebiet
Themengebiet nicht bekannt praktischen Erfahrungen praktische Erfahrungen mindestens bekannt Disziplin im Prozess
Eingabeprüfung
(Sanitization)
14% 26% 61% 87% Implementierung
Patch Management 25% 33% 42% 75% Implementierung
Penetrations-Tests
(Pen-Tests)
18% 46% 36% 82% Test
Korrekte Verwendung
von Kryptographie- 22% 43% 36% 79% Implementierung
Bibliotheken
Defensive Coding
(Schreiben von 27% 38% 36% 74% Implementierung
sicherem Code)
Entwurf sicherer
Architekturen
25% 45% 31% 76% Entwurf
Security-Anforderungen Anforderungs-
und Security-Testfälle
27% 44% 29% 73% management
Incident Response
(Verhalten bei 29% 45% 26% 71% Betrieb
Sicherheitsvorfällen
security-spezifische
Code Reviews
31% 45% 24% 69% Test
Durchführung einer Anforderungs-
Bedrohungsanalyse
27% 52% 21% 73% management
Die Themengebiete sind absteigend sortiert nach dem Anteil an praktischen Erfahrungen (Spalte 4). Die zusätzliche Spalte „mindestens bekannt“ zeigt den
prozentualen Anteil der Entwickler*innen, die das Themengebiet und dessen Konzepte kennen – unabhängig von den praktischen Erfahrungen (der
jeweilige Wert entspricht der Summe der Werte aus der Spalte 3 und 4).
Abbildung 16: Wie schätzen die Entwickler*innen ihre Security-Kompetenz je Themengebiet ein?
Abbildung 16 zeigt zudem in Spalte 5 inwiefern jedes Das Ergebnis ist, dass die Entwickler*innen sehr unter-
Themengebiet mindestens bekannt ist (diese ergibt schiedliche Kompetenzen haben. Bei der Betrachtung
sich aus der Summe der Spalten 3 und 4). Somit ergibt der Extreme wird ersichtlich, dass 2% gar keine The-
sich, dass alle Themengebiete bei mindestens 69% der mengebiete kennen und nur 3% Praxiserfahrung in al-
Entwickler*innen mindestens bekannt sind. Die Einga- len Themengebieten haben. 39% der Befragten kennen
beprüfung sowie der Pen-Test erreichen hierbei sehr alle Themengebiete – im Umkehrschluss bedeutet dies,
gute 87% bzw. 82%. Insgesamt lässt sich somit festhal- dass 61% mindestens ein Themengebiet nicht kennen.
ten, dass ein Großteil der Themen einen guten Bekannt- Darüber hinaus lässt sich die Gesamtheit der Entwick-
heitsgrad hat und kein Thema deutlich nach unten aus- ler*innen grob in drei Gruppen unterteilen. Gruppe 1
schlägt. besteht aus ungefähr einem Viertel der Entwickler*in-
nen (23%). Diese Gruppe kennt fünf oder mehr Themen-
Eine zweite Auswertung der Selbsteinschätzung der gebiete nicht und hat bei den wenigen Themengebie-
Entwickler*innen ist in Abbildung 17 zu sehen. Hier- ten, die sie kennen, nur sehr vereinzelt Praxiserfahrung.
bei haben wir je Entwickler*in gezählt, wie viele The- Gruppe 2 umfasst circa 41%. Sie kennen fünf oder mehr
mengebiete ihm*ihr unbekannt, bekannt, aber ohne Themengebiete und haben bei einigen auch Praxiser-
Praxiswissen, oder bekannt und mit Praxiswissen sind. fahrung, kennen aber auch einige Themengebiete nicht.
22Die dritte Gruppe, die circa ein Drittel der Entwickler*in- nung, dass alle Entwickler*innen in einem Großteil
nen umfasst, hat Praxiserfahrung in mindestens fünf der Themengebiete praktische Erfahrungen aufweisen
der Themengebiete und kennt fast alle Themengebiete. sollten. Ein Argument hierfür ist, dass Entwickler*innen
Unserer Meinung nach sollten alle Entwickler*innen heutzutage typischerweise in mehreren oder gar allen
nahezu alle Themengebiete kennen. Ein Grund hierfür Disziplinen aktiv sind und daher praktische Erfahrun-
ist, dass alle Entwickler*innen in den agilen Meetings gen benötigen, um den Aspekt Security berücksichtigen
(Planning, Review, Retro) jeweils verstehen sollten, wo- zu können. Insbesondere die Gruppe 1 benötigt somit
von gesprochen wird, bzw. mitreden können, sodass es einen Kompetenzausbau, um eine sichere Softwareent-
zu einem Meinungsaustausch und kritischen Nachfra- wicklung gewährleisten zu können.
gen kommen kann. Darüber hinaus sind wir der Mei-
Thema unbekannt Thema beaknnt + keine Praxiserfahrung Thema bekannt + Praxiserfahrung
Niedrige Kompetenz Mittlere Kompetenz Hohe Kompetenz
Sehr viele Themen unbekannt & Sehr viele Themen bekannt (fast) alle Themen bekannt &
nur wenig Praxiserfahrung sehr viele Themen Praxiserfahrung
10
9
8
7
6
Themengebiete
5
4
3
2
1
0
7
67
97
127
157
187
217
247
0
13
19
25
31
31
43
49
55
61
73
79
85
91
103
115
121
133
139
145
151
163
169
175
181
193
199
205
211
223
229
235
241
253
Entwickler*innen (aufsteigend sortiert nach Kompetenz)
Je Entwicker*in wurde gezählt wie viele Themengebiete unbekannt, bekannt und bekannt mit Praxiserfahrung sind.
N=256
Abbildung 17: Bekanntheit der Themengebiete je Entwickler*in
23Sie können auch lesen
