View source for Germany/Projekte/Top 10 fuer Entwickler-2013/Nächste Schritte für Software-Entwickler

{{Top_10_2013_DeveloperEdition:TopTemplate
  |useprev=2013PrevLinkDeveloperEdition
  |usenext=2013NextLinkDeveloperEdition
  |prev=A10-{{Top_10_2010:ByTheNumbers
            |10
            |year=2013
            |language=de}}
<!---    |next={{Top_10:LanguageFile|text=whatsNextforVerifiers|language=de}} --->
  |next=Nächste Schritte für Projektleiter und Anwendungsverantwortliche
  |year=2013
  |language=de
}}

{{Top_10_2010:SubsectionColoredTemplate
      |{{Top_10:LanguageFile|text=whatsNextforDevelopers|language=de}}
      ||year=2013
}}
{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstWhole|title={{Top_10:LanguageFile|text=establishAndUseAFullSetOfCommonSecurityControls|language=de}}|year=2013|language=de}}
Unabhängig davon, ob man ein Neuling im Bereich der Webanwendungssicherheit ist, oder schon mit den erläuterten Gefahren vertraut ist – die Entwicklung einer neuen, sicheren Webanwendung, oder das Absichern einer bereits existierenden, kann sehr schwierig sein. Für die Betreuung eines großen Anwendungsportfolios mag das abschreckend wirken.

===Viele OWASP Ressourcen sind frei verfügbar===
Um Organisationen und Entwicklern dabei zu helfen, ihre Anwendungssicherheitsrisiken kostengünstig zu reduzieren, stellt die OWASP zahlreiche frei zugängliche Ressourcen zur Verbesserung der Anwendungssicherheit zur Verfügung. Im Folgenden werden einige dieser OWASP Ressourcen vorgestellt, die Organisationen helfen können, sichere Webanwendungen zu erstellen. Auf der nächsten Seite stellen wir einige OWASP Ressourcen vor, die Organisationen dabei helfen können Ihre Anwendungs-sicherheit zu überprüfen.

{| cellspacing="1" cellpadding="1" border="0" width="100%;"
|{{Top 10:RoundedBoxBegin|year=2013}}{{#switchtablink:Anforderungen an die Anwendungssicherheit|<br/>Anforderungen an die Anwendungssicherheit}}
{{Top 10:RoundedBoxEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
* Um eine sichere Webanwendung zu erstellen, ist es wichtig, vorher zu definieren was "sicher" im Falle einer speziellen Anwendung bedeutet. Das OWASP empfiehlt dazu den [[ASVS | OWASP Application Security Verification Standard (ASVS)]] als Leitfaden zur Erstellung von Sicherheitsanforderungen. Bei Outsourcing der Anwendungsentwicklung empfiehlt sich der [[OWASP_Secure_Software_Contract_Annex | OWASP Secure Software Contract Annex]].
{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxBegin|year=2013}}{{#switchtablink:Anwendungs-Sicherheits-Architektur|<br/>Anwendungs-Sicherheits-Architektur}}
{{Top 10:RoundedBoxEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
* Anstatt Sicherheit nachträglich in eine Anwendung zu implementieren, ist es kosteneffektiver, diese schon beim Design zu beachten. OWASP empfiehlt hierzu den [[OWASP_Guide_Project | OWASP Developer’s Guide]], das [[OWASP Secure Application Design Project|OWASP Secure Application Design-Projekt]] und die [[Cheat_Sheets | OWASP Prevention Cheat Sheets]] als Startpunkt. Sie gelten als Leitfäden, wie Sicherheitsaspekte von Anfang an einfließen können.
{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxBegin|year=2013}}{{#switchtablink:standardisierte Sicherheitskontrollen|<br/> Standardisierte Sicherheitskontrollen}}
{{Top 10:RoundedBoxEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
* Die Entwicklung starker und anwendbarer Sicherheitskontrollen ist recht schwierig. Standardisierte Sicherheitskontrollen für Entwickler vereinfachen die Entwicklung sicherer Anwendungen. Das OWASP empfiehlt dazu das [[ESAPI | OWASP Enterprise Security API (ESAPI) Project]] - ein Modell, dass APIs zur Entwicklung sicherer Anwendungen zur Verfügung stellt. ESAPI unterstützt Implementierungen in [[ESAPI |Java]], [[ESAPI |.NET]], [[ESAPI | PHP]], [[ESAPI | Classic ASP]], [[ESAPI | Python]], sowie [[ESAPI |Cold Fusion]].
{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxBegin|year=2013}}{{#switchtablink:Sicherer Entwicklungszyklus SDLC|<br/>Sicherer Entwicklungszyklus (Secure&nbsp;Development&nbsp;Lifecycle SDLC)}}
{{Top 10:RoundedBoxEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
* Um den Prozess zur sicheren Anwendungserstellung in einer Organisation zu verbessern, empfiehlt OWASP das [[SAMM | OWASP Software Assurance Maturity Model (SAMM)]]. Das Modell hilft bei der Formulierung und Umsetzung einer Software-Sicherheitsstrategie, die spezifische Risiken der eigenen Organisation berücksichtigt.
{{Top 10:GrayBoxEnd|year=2013}}
|-
|{{Top 10:RoundedBoxBegin|year=2013}}{{#switchtablink:Anwendungs-Sicherheits-Ausbildung|<br/>Anwendungs-Sicherheits-Ausbildung}}
{{Top 10:RoundedBoxEnd|year=2013}}
|{{Top 10:GrayBoxBegin|year=2013}}
* Das [[:Category:OWASP_Education_Project | OWASP Education Project]] bietet Material zur Schulung von Entwicklern im Bereich der Anwendungssicherheit und stellt eine Vielzahl an [[OWASP_Education_Presentation | OWASP Educational Presentations]] bereit. Praktische Erfahrungen über Schwachstellen können mithilfe des [[WebGoat | OWASP WebGoat-]], [[:Category:OWASP_WebGoat.NET |  WebGoat.NET-]], oder des [[OWASP_Broken_Web_Applications_Project | OWASP Broken Web Applications-]]Projekts gesammelt werden. Um aktuell informiert zu bleiben, besuchen Sie die [[OWASP_AppSec_Conference |OWASP AppSec Conference]], ein OWASP Training, eines der [[Germany/Chapter_Meetings | lokalen OWASP Chapter Meetings]], oder einen [[Germany/Stammtisch_Initiative | OWASP Stammtisch]].
{{Top 10:GrayBoxEnd|year=2013}}
|}
<br/>
Es stehen zahlreiche weitere OWASP Ressourcen zur Verfügung. Besuchen Sie die OWASP Projects Seite, die eine Liste aller [[Projects | OWASP Projekte]], organisiert nach dem Qualitätsstatus der einzelnen Veröffentlichungen (Veröffentlicht, Beta oder Alpha) enthält. Viele OWASP Ressourcen sind in unserem Wiki verfügbar und können auch in [http://stores.lulu.com/owasp Papierformat] bestellt werden.
{{Top_10:SubsectionTableEndTemplate}}

===mögliche Erweiterung:===
{{taggedSection
    | type=tbd 
    | comment=Hier werden zusätzliche Hinweise zusammengestellt. Z.B. auf Basis der [https://www.bsi.bund.de/DE/Publikationen/Studien/Webanwendungen/index_htm.html BSI-Leitfäden zur Entwicklung sicherer Webanwendungen]
}} 
=Anforderungen an die Anwendungssicherheit=
Zunächst sind die durch die Anwendung zu verarbeitenden Daten zu definieren und deren Schutzbedarf festzulegen. Das Ziel der Schutzbedarfserhebung ist es zu ermitteln, in welchem Ausmaß die Webapplikation in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit geschützt werden muss, um in späteren Phasen daraus die Sicherheitsanforderungen, Maßnahmen sowie Audit-Pläne ableiten zu können. Die Grundwerte stellen jene Faktoren dar, die von Angriffen bedroht werden. In der Informationssicherheit sind drei fundamentale Grundwerte vorhanden: Vertraulichkeit, Integrität und Verfügbarkeit.</span>

Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Das Belauschen, eine Weitergabe oder Veröffentlichung von vertraulichen Informationen ist daher nicht erwünscht.
Die Integrität von Daten gewährleistet deren Vollständigkeit und Unversehrtheit über einen bestimmten Zeitraum und ermöglicht die Aufdeckung einer Manipulation.
Verfügbarkeit kann sich auf IT-Systeme oder Daten beziehen und fordert, dass sie zu definierten Zeiten, im Einklang mit der Vertraulichkeit und der Integrität, von Anwendern stets wie vorgesehen genutzt werden können.</span>

Die Grundwerte beziehen sich nicht ausschließlich auf Daten, sondern sollten ebenfalls auf Datenflüsse, Kommunikationskanäle oder ganze IT-Systeme umgelegt werden.</span>

Webanwendungen besitzen unterschiedliche Schutzbedürfnisse. Da diese in der Praxis meist nicht quantifizierbar sind, werden sie in drei Kategorien eingeteilt: „Normal“, „Hoch“ und „Sehr hoch“. Diese Definition entspricht den Begriffen des IT-Grundschutzes des BSI. Unter einem normalen Schutzbedarf sind Schadensauswirkungen begrenzt und überschaubar, während unter einem hohen bzw. sehr hohen Schutzbedarf die Schadensauswirkungen beträchtlich bzw. existenziell bedrohlich sein können. Diese Kategorien dienen als Entscheidungsgrundlage, welche Sicherheitsanforderungen für die jeweilige Webanwendung getroffen werden sollten.</span>

Um die Zuordnung zu einer der Kategorien zu erleichtern, können verschiedene Schadenszenarien betrachtet werden (z.B. ein Verstoß gegen Gesetze oder Vorschriften). Die Schadensszenarien fassen Schäden zusammen, die beim Eintreten einen Verlust eines Schutzzieles bedeuten. Die Webanwendung muss mindestens hinsichtlich der folgenden Schadensszenarien bewertet werden. Darüber hinaus – wenn notwendig – können weitere Schadensszenarien definiert oder es müssen die individuellen Gegebenheiten berücksichtigt werden.
</span>
{{Top_10:SubsectionTableBeginTemplate|type=headertab}}  {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstLeft|title=Anforderungen an die Anwendungssicherheit (1)|year=2013|language=de}} 
====Tbd====
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=right|title=Anforderungen an die Anwendungssicherheit (2)|year=2013|language=de}} 
====Tbd====
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=left|title=Anforderungen an die Anwendungssicherheit (3)|year=2013|language=de}} 
====Tbd====
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|year=2013|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* 

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2013|language=de}}
* 

{{Top_10:SubsectionTableEndTemplate}}
 
=Anwendungs-Sicherheits-Architektur=
Um eine Webanwendung möglichst sicher zu gestalten ist eine geeignete Sicherheitsarchitektur zu konzipieren. Hierbei spielen insbesondere die folgenden Aspekte eine zentrale Rolle:</span>
* Werden Designprinzipen angewendet?
** z.B. Seperation of Concerns: Ist jede Aufgabe einer und nur einer logischen Komponente zugeordnet?
* Wurden alle notwendigen Angriffsvektoren ermittelt und behandelt?
* Ist die Architektur vollständig in Bezug auf funktionale und nicht funktionale Sicherheitsanforderungen?
* Ist die Architekturbeschreibung auf dem aktuellen Stand und entspricht der vorliegenden Code-Basis?
* Wurden die wesentlichen Designentscheidungen durch Dokumentation explizit gemacht?
* Sind alle wesentlichen Entscheidungen nachvollziehbar?
* Qualität und Ausführlichkeit der Dokumentation
* Sind fachliche und technologische Aspekte getrennt adressiert?
* Ist die Anwendung über eine logische Komponentenbildung auf verschiedensten Ebenen strukturiert?
* Erfolgen der Datenfluss, der Steuerungsfluss und die Fehlerbehandlung durchgehend konsistent nach demselben Schema (zumindest innerhalb von Komponenten derselben Architektur-Ebene)?
* Wie gut erlaubt die Architektur die Erweiterbarkeit der Anwendung während der Wartung?
* Sind vorhandene Schnittstellen definiert und hinreichend dokumentiert?
=Standardisierte Sicherheitskontrollen=  
Um die Sicherheit und damit auch die Qualität der Software zu erhöhen, ist es notwendig, während des gesamten Entwicklungszeitraums sicherheitsspezifische Tests durchzuführen. Je früher dabei Schwachstellen identifiziert werden, desto geringer fallen die zur Behebung notwendigen Kosten aus. Eine häufig verwendete Methodik ist die Verwendung von Security Gates. Security Gates stellen eine Form der innerhalb der Qualitätssicherung häufig verwendeten Quality Gates dar. Dabei handelt es sich um Meilensteine im Projekt, die nur unter Einhaltung definierter Sicherheits- bzw. Qualitätskriterien passiert werden dürfen. Security Gates werden häufig mit den Ergebnissen obligatorischer Sicherheitstests verknüpft. So ließe sich bestimmen, dass eine Anwendung vor dem Produktivgang einen Penetrationstest durchlaufen muss und durch diesen keine gravierenden Mängel identifiziert werden dürfen.
Security Gates helfen damit, ein Mindestmaß an Sicherheit in einem Projekt umzusetzen.
</span>
{{Top_10:SubsectionTableBeginTemplate|type=headertab}}  {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstLeft|title=Konzeption und Planung|year=2013|language=de}} 
Am Ende der Konzeptions- und Planungsphase sollten folgende Dokumente erstellt worden sein, die vom Auftraggeber auf ihre Vollständigkeit zu prüfen sind:
* Liste der verwendeten Guidelines und Good Practices für das Softwaredesign
* Objektmodell mit Datentypen, Datenklassifizierungen und Datenflüssen
* Access Control Matrix bzw. Rollen und Berechtigungskonzepte
* Abuse Cases
* Bedrohungsmodellierung (Liste mit Zugangspunkten zur Applikation, Bedrohungsmodell mit Vertrauensgrenzen (Trust Boundaries), Liste identifizierter und bewerteter Bedrohungen, Liste mit begründeten Gegenmaßnahmen)
* Liste aller Sicherheitsanforderungen
* Detaillierte Testplanung
* Planung von Quality Gates
* Planung von Security Pushes
* Software Security Metriken1
* Sicherheitsarchitektur

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=right|title=Implementierungsphase|year=2013|language=de}} 
Während bzw. am Ende der Implementierungsphase sollten folgende Punkte geprüft werden:
* An welchen Stellen wurden Standard-APIs verwendet?
* An welchen Stellen wurden Standard-APIs nicht verwendet und warum?
* Wurde der eigene Code sauber von Fremdmodulen getrennt?
* Wurden Daten bzw. Ressourcen von dem Code getrennt?
* Existiert eine Liste/ein Repository mit zu verwendenden Frameworks?
** Ja: Wie wird die Liste gewartet und wie wird auf Schwachstellen reagiert?
** Nein: Welche Frameworks kommen zum Einsatz und warum?
* Kommen Eigenentwicklungen für sicherheitskritische Komponenten zum Einsatz?
** Wenn ja, dann nur mit Begründung, warum man sich für eine Eigenentwicklung entschieden hat.
* Werden Maßnahmen zum Schutz des Source Codes werden getroffen?
* Werden die im Sicherheitsprojektplan vorgesehenen Quality Gates und Security Pushes  eingehalten?
* Werden die festgelegten Sicherheitsanforderungen erfüllt?
* Ist der Quellcode, insbesondere sicherheitskritische Abschnitte, ausreichend dokumentiert (auf Qualität und Ausführlichkeit der Dokumentation ist zu achten)?
* Werden allgemeine Secure Coding Standards verwendet?
* Werden programmiersprachen-spezifische Secure Coding Standards verwendet?
* Sind Qualität und Umfang der Secure Coding Standards hinreichend und beinhalten diese z.B.
** einen einheitlichen Programmierstil, 
** eine Trennung von Eingabedaten und Befehlen und
** eine Fehlerbehandlung.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=left|title=Testphase|year=2013|language=de}} 
Erste Softwaretests finden bereits während der Entwicklungsphase statt. Speziell beim Einsatz agiler Entwicklungsmethoden sollte es zu jedem Ende eines Sprints möglich sein, die Ergebnisse der Testverfahren zu prüfen. Dabei muss sichergestellt werden, dass gefundene Schwachstellen und deren Behebung dokumentiert und nachvollziehbar sind.

* Sind Test-, Entwicklungs- und Produktivumgebung voneinander getrennt?
* Das Testteam ist nicht das Entwicklerteam.
* Werden die geplanten Tests durchgeführt?
* Sind Ergebnisberichte der durchgeführten Tests vorhanden?
* Wurden behobene Fehler dokumentiert?
* Findet vor der Auslieferung ein finaler Security Check statt?
* Die Qualität und Ausführlichkeit der Dokumentation sind ausreichend.

Hierbei ist zwischen den folgenden Testarten zu unterscheiden:

* Security Test Cases: Security Test Cases werden herangezogen, um die spezifizierten funktionalen und nicht funktionalen Sicherheitsanforderungen einer Anwendung zu überprüfen.
* Security Unit Tests: Security Unit Tests überprüfen Softwareeinheiten (sog. Units) auf korrekte Funktionalität. Ein Security Unit Test ist ein Stück Code, das ein anderes Stück Code aufruft. Das Ergebnis des Aufrufs wird anschließend auf Richtigkeit überprüft.
* Design Review: Im Design Review wird die Umsetzung der durch die Sicherheitsarchitektur definierten Anforderungen geprüft.
* Code Review: Im Zuge eines Code Reviews wird der Programmcode manuell überprüft. Neben Fehlern im Code können mit einem Code Review auch Fehler in der Umsetzung von Sicherheitsanforderungen, der Einhaltung von Entwicklungsrichtlinien und unzureichende Dokumentation des Source Codes festgestellt werden. Der Vorteil des manuellen Code Review ist, dass dieses auch ohne vollständigen Code, beispielsweise für einzelne Module, durchgeführt werden kann.
* Statische Codescans: Durch die Verwendung von Tools zur statischen Codeanalyse können eine Vielzahl von (weit verbreiteten) Fehlerarten detektiert und behoben werden. Wichtig ist dabei jedoch, die Ergebnisse dieser Tools durch einen Experten analysieren und bewerten zu lassen.
* Web Security Scanner: Auf Webanwendungen spezialisierte Scanner können verwendet werden, um über die HTTP-Schnittstelle Schwachstellen wie XSS oder SQL-Injection zu detektieren.
* Fuzzing: Viele Fehler in Applikationen werden durch falsche oder unerwartete Benutzereingaben ausgelöst. Beim Fuzzing wird versucht, solche unerwarteten Eingabewerte zu finden, die beispielsweise einen Buffer Overflow auslösen. Theoretisch müssten bei einem vollständigen Fuzztest alle Eingabemöglichkeiten getestet werden, was aber in der Praxis bei komplexeren Programmen nicht durchführbar ist. Aus diesem Grund ergibt es Sinn, nur Werte und Muster zu testen, die mit hoher Wahrscheinlichkeit einen Fehler auslösen. Ein Beispiel wären die Bereichsgrenzen von numerischen Variablen.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|year=2013|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* 

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2013|language=de}}
* 

{{Top_10:SubsectionTableEndTemplate}}

=Sicherer Entwicklungszyklus SDLC=
Software sicher zu entwickeln ist eine komplexe Herausforderung. Umso wichtiger ist daher eine strukturierte Herangehensweise, welche die notwendigen Aktivitäten sowie die Bewertungskriterien definiert und damit eine nachhaltige Berücksichtigung von Softwaresicherheit im Rahmen der Softwareentwicklung gewährleistet. Folglich werden in diesem Kapitel allgemeine Anforderungen definiert, die eine Organisation sowohl bei der Konzeption und Implementierung als auch bei der Verifikation von Sicherheit unterstützen.</span>

Mit fortschreitender Entwicklung steigen die Kosten für die Behebung von Fehlern gleichsam sprunghaft und deren Erkennungsrate geht zurück. Je eher eine Schwachstelle gefunden und behoben wird, desto weniger Kosten entstehen. Auch das Sicherheitsniveau einer Anwendung wird grundlegend in frühen Phasen deren Entwicklung bestimmt. Spätere Änderungen sind vergleichbar mit dem Versuch, einen Fehler im Rohbau eines Hauses im Nachhinein zu korrigieren.</span>

Da sicherheitsrelevante Entscheidungen im gesamten Lebenszyklus einer Webanwendung getroffen werden, leitet sich hieraus die Notwendigkeit ab, diese auch in jeder einzelnen Entwicklungsphase entsprechend zu berücksichtigen. Dies wird erreicht, indem über dem existierenden Vorgehensmodell zur Entwicklung ein Secure Development Lifecycle (SDL) definiert wird, der entsprechende Aktivitäten zur Erstellung bzw. Analyse der Sicherheit jeder einzelnen Phase, also eine Art sicheren Entwicklungsprozess, definiert.</span>

Natürlich sind Entwicklungsprozesse häufig sehr stark organisationsspezifisch ausgeprägt. Der SDL muss diese spezifische Art und Weise, wie eine Organisation Software entwickelt, gleichsam berücksichtigen, um zu funktionieren.
Davon ist natürlich nicht nur dessen Einführung betroffen. Der Versuch von heute auf morgen einen vollumfänglichen Sicherheitsprozess einzuführen wird wahrscheinlich damit scheitern. Denn damit ist häufig auch die Umstellung eben dieser Art und Weise verbunden, mit der eine Organisation Software entwickelt und das geschieht in der Regel nicht von heute auf morgen.</span>

{{Top_10:SubsectionTableBeginTemplate|type=headertab}}  {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstLeft|title=Reifegrade|year=2013|language=de}} 
Organisationen entwickeln auf teilweise sehr unterschiedliche Weise Software und auch in Bezug auf Sicherheit findet man große Unterschiede. Dies betrifft sowohl das aktuell erreichte Sicherheitsniveau als auch die angestrebten Sicherheitsziele. Diese Heterogenität zwischen den Organisationen muss berücksichtigt werden, wenn die Einführung von Sicherheitsaktivitäten (auch als „Sicherheitsinitiative“ bezeichnet) geplant und angegangen wird. Das Verständnis von Reifegraden ist dabei elementar. Solche Reifegrade beispielsweise von BSIMM und Open SAMM einbezogen.

Der Gedanke ist dabei einfach: Jede Aktivität einer Phase des Entwicklungsprozesses besitzt einen bestimmten Reifegrad. Sowohl hinsichtlich des aktuellen Implementierungsgrades (Ist-Zustandes) als auch hinsichtlich gewünschter oder theoretisch denkbarer Ausprägungen (Soll-Zustand). Der Reifegrad einer Aktivität resultiert aus der Gesamtheit der Teilaktivitäten, die in dieser Aktivität durchgeführt werden. Nicht jedes Unternehmen besitzt die höchsten Sicherheitsanforderungen, und genau dies wird durch die Reifegrade berücksichtigt.

Gleichwohl bieten Reifegrade auch die Möglichkeit, einen Secure Development Lifecycle (SDL) zu bewerten und Unzulänglichkeiten aufzudecken. Häufig haben Unternehmen etwa einen sehr hohen Reifegrad beim Security Testing, berücksichtigen den Bereich der konzeptionellen Sicherheit dagegen kaum. Bezieht man den Reifegrad auf den SDL, wird dabei die Gesamtheit der umgesetzten Aktivitäten (und deren Reifegrade) betrachtet. Reifegrade spielen auch bei der strukturierten Planung und Einführung von Aktivitäten in der Organisation eine entscheidende Rolle. Für die visuelle Darstellung der Reifegrade und insbesondere für die Darstellung deren gewünschter Entwicklung können Scorecards herangezogen werden.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=right|title=Scorecards|year=2013|language=de}} 
Zur Unterstützung der Umsetzung der sicheren Softwareentwicklung (insbesondere zur Anhebung des Reifegrades) können Scorecards herangezogen werden. Jede Phase des Entwicklungsprozesses wird mit einem Reifegrad anhand der umgesetzten Aktivitäten bewertet und in der Scorecard eingetragen. Zusätzlich wird in der Scorecard zu jeder Phase des Entwicklungsprozesses der angestrebte Ziel-Reifegrad eingetragen.

Scorecards dienen in erster Linie der anschaulichen Darstellung des derzeitigen Reifegrades sowie des angestrebten Reifegrades. Sie können aber auch zur Gap Analyse (Gegenüberstellung des SOLL- und IST-Zustandes) sowie zu laufenden Messungen herangezogen werden. Der Unterschied zwischen IST und SOLL kann mit Unterstützung einer Roadmap geplant und nach erfolgreicher Umsetzung verringert werden.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=left|title=Roadmap|year=2013|language=de}} 
Jede Vorgehensweise muss für eine erfolgreiche und nachvollziehbare Umsetzung geplant werden. Die Planung für die Einführung von Sicherheit in der Softwareentwicklung kann mit Hilfe einer Roadmap erfolgen. Roadmaps definieren, wie der Reifegrad einer Phase iterativ angehoben werden kann. Hierbei werden bestimmte Aktivitäten in bestimmten Iterationen definiert und umgesetzt. Je nach Organisation kann die Anzahl der Iterationen variieren. Hier ein Beispiel für Iterationen, die häufig verwendet werden:
* Iteration 1: Kurzfristig, z.B. innerhalb der nächsten drei Monate
* Iteration 2: Mittelfristig, z.B. innerhalb des aktuellen Jahres
* Iteration 3: Mittelfristig, z.B. innerhalb eines Jahres
* Iteration 4: Langfristig, z.B. innerhalb der nächsten zwei bis drei Jahre
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|year=2013|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* 

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2013|language=de}}
* 

{{Top_10:SubsectionTableEndTemplate}}

=Anwendungs-Sicherheits-Ausbildung=
Unter dem Begriff Awareness versteht man die Bewusstseinsbildung hinsichtlich Sicherheitsthemen. Alle an der Entwicklung einer Anwendung beteiligten Mitarbeiter müssen mit dem Thema Sicherheit konfrontiert werden. Das betrifft sowohl Entwickler als auch Projektmanager, Qualitätstester, Administratoren usw.</span>

Es muss sichergestellt werden, dass von jedem Mitarbeiter die Folgen von Sicherheitsmängeln sowie geltenden Anforderungen verstanden werden. Auch das Thema Datenschutz sollte in diesem Rahmen in ausreichendem Maße adressiert werden. Diese Bewusstseinsbildung erfolgt zumeist durch Schulungen.</span>

Diese Schulungen können sowohl von externen als auch interne Experten durchgeführt werden. Eine solche Veranstaltung kann abhängig von den spezifischen Erfordernissen entweder als mehrtägiger Workshop oder als computergestützter modularer Kurs aufgebaut werden. Der Inhalt sollte sowohl konzeptuelle als auch technische Informationen beinhalten.
Die Ausgestaltung kann und sollte dabei unterschiedliche Zielgruppen angemessen adressieren. Einem Projektmanager muss in der Regel nicht das gleiche technische Verständnis vermittelt werden, wie dies etwa bei Entwicklern der Fall ist, insbesondere wenn diese mit der konkreten Implementierung von sicherheitsrelevanten Funktionen betraut worden sind.
Ein grundlegendes Awareness-Training sollte für alle an der Entwicklung einer Webanwendung beteiligten Personen verpflichtend sein und periodisch durchgeführt werden. Neue Mitarbeiter sollen ein entsprechendes Training unmittelbar nach Firmeneintritt erhalten.</span>

<headertabs/>
{{Top_10_2013_DeveloperEdition:BottomAdvancedTemplate
    |type=0
    |useprev=2013PrevLinkDeveloperEdition
    |usenext=2013NextLinkDeveloperEdition
  |prev=A10-{{Top_10_2010:ByTheNumbers
            |10
            |year=2013
            |language=de}}
<!---    |next={{Top_10:LanguageFile|text=whatsNextforVerifiers|language=de}} --->
  |next=Nächste Schritte für Projektleiter und Anwendungsverantwortliche
  |year=2013
  |language=de
}}