- \n
- Sicherstellung eines einheitlichen Code-Stils im Team,<\/li>\n\n\n\n
- Entwicklung von lesbarem und wartbarem Code,<\/li>\n\n\n\n
- Entwicklung von m\u00f6glichst fehlerfreiem Code,<\/li>\n\n\n\n
- Minimierung von Sicherheitsl\u00fccken in der Software.<\/li>\n<\/ul>\n\n\n\n
Klassischerweise versuchen IT-Teams durch regelm\u00e4\u00dfige Code-Reviews diesen Zielen m\u00f6glichst nah zu kommen. Dieser Teil der Serie erkl\u00e4rt, wie Statische Code-Analyse die Erreichung der oben genannten Ziele im Einzelnen f\u00f6rdern kann.<\/p>\n\n\n\n\n\n
Wie Statische Code-Analyse helfen kann<\/h2>\n\n\n\n
Entsprechend der vier oben genannten Ziele kann man die Aufgaben f\u00fcr Statische Code-Analyse-Tools in folgende Kategorien aufteilen:<\/p>\n\n\n\n
- \n
- \u00dcberpr\u00fcfung des Code-Standards,<\/li>\n\n\n\n
- Berechnung von Softwaremetriken,<\/li>\n\n\n\n
- Erkennung von Fehlern im Code,<\/li>\n\n\n\n
- Erkennung von Sicherheitsl\u00fccken.<\/li>\n<\/ul>\n\n\n\n
Ein zus\u00e4tzlicher Querschnittsaspekt ist die Fortschritts\u00fcberwachung, d. h. die Speicherung von Metriken verschiedener Tools \u00fcber die Zeit. Dadurch wird nachverfolgbar, ob sich die Code-Qualit\u00e4t im Hinblick auf die konfigurierten Aspekte verbessert oder verschlechtert.<\/p>\n\n\n\n
Im Folgenden gehe ich detailliert auf die Kategorien ein.<\/p>\n\n\n\n
\u00dcberpr\u00fcfung des Code-Standards<\/h2>\n\n\n\n
Tools dieser Kategorie pr\u00fcfen, ob der Quellcode vorher festgelegten und konfigurierten Code-Formatierungsvorgaben entspricht. Dabei k\u00f6nnen Aspekte wie bspw. Klammersetzung, Einr\u00fcckung, Zeilenbreite, Leerzeichen und -zeilen, Klassen- und Methodenl\u00e4ngen, Anzahl von Methodenparametern und vieles weitere mehr \u00fcberpr\u00fcft werden.<\/p>\n\n\n\n
Warum ist einheitlicher Code-Standard wichtig?<\/h3>\n\n\n\n
Einheitlicher Code-Standard hat folgende Vorteile:<\/p>\n\n\n\n
- \n
- Einheitlich formatierten Code ist einfacher zu lesen und zu verstehen.<\/li>\n\n\n\n
- Wenn alle Entwickler direkt im einheitlichen Stil schreiben, dann fallen Reviews leichter, da der Code nicht erst an die gemeinsamen Regeln angepasst werden muss.<\/li>\n\n\n\n
- Schwer lesbarer und damit schwer nachvollziehbarer Code kann zu Fehlern und Sicherheitsrisiken f\u00fchren.<\/li>\n<\/ul>\n\n\n\n
Welche Code-Standards gibt es?<\/h3>\n\n\n\n
Moderne IDEs k\u00f6nnen Code selbstst\u00e4ndig formatieren. Dazu k\u00f6nnen in die IDE integrierte Formatierungsregeln verwendet, angepasst, exportiert und importiert werden. Die in Eclipse und IntelliJ standardm\u00e4\u00dfig integrierten Code-Stile sind allerdings unterschiedlich. Eclipse hat die Stile \"Java Conventions\", \"Eclipse\" und \"Eclipse 2.1\"; IntelliJ bietet den \"Default\"-Stil an. <\/p>\n\n\n\n
IntelliJ kann von Eclipse exportierte Formate importieren, andersherum ist das nicht m\u00f6glich. Da IntelliJ mit einem importierten Eclipse-Format nicht 100 % denselben Code generiert wie Eclipse, gibt es au\u00dferdem das Eclipse Code Formatter<\/a>-Plugin, das den Code in IntelliJ auf die exakt gleiche Art und Weise formatiert wie Eclipse.<\/p>\n\n\n\n
Die \"Java Conventions\" aus Eclipse entsprechen den 1997 von Sun herausgegebenen und zuletzt 1999 \u00fcberarbeiteten Java Code Conventions<\/a>. Entsprechend kennt dieser Stil keine neueren Sprachelemente wie bspw. Generics oder Lambdas. <\/p>\n\n\n\n
Ein moderner und verbreiteter IDE-unabh\u00e4ngiger Code-Stil ist der Google Java Style Guide<\/a>, welcher in vielen Projekten entweder direkt oder leicht abgewandelt verwendet wird. Der Google-Stil hat folgende Vorteile:<\/p>\n\n\n\n
- \n
- Es werden Konfigurationsfiles f\u00fcr Eclipse, IntelliJ und Checkstyle (dazu unten mehr) angeboten.<\/li>\n\n\n\n
- Es gibt nicht nur Vorgaben f\u00fcr Java, sondern f\u00fcr zahlreiche andere verbreitete Sprachen, wie HTML, CSS und JavaScript. So kann in einem Projekt, in dem verschiedene Sprachen zum Einsatz kommen, relativ einfach ein einheitlicher Stil verwendet werden.<\/li>\n<\/ul>\n\n\n\n
Um die Unterschiede zu demonstrieren, werde ich das folgende (sinnlose und absichtlich unsauber formatierte) Codest\u00fcck in allen zuvor genannten Code-Stilen formatieren.<\/p>\n\n\n
\n![\"Unformatierter](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/code_style_unformatted.png\")
<\/a>Unformatierter Code<\/figcaption><\/figure>\n<\/div>\n\n\n Die Ergebnisse seht ihr in der folgenden Bilderstrecke (zum Vergr\u00f6\u00dfern anklicken). Da beim Google Java Style standardm\u00e4\u00dfig mit zwei Leerzeichen einger\u00fcckt wird, habe ich noch eine zus\u00e4tzlich Variante mit vier Leerzeichen eingef\u00fcgt.<\/p>\n\n\n\n
\n ![\"Eclipse's](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/code_style_java_conventions.png\")
<\/a>Eclipse's \"Java Conventions\" formatter<\/figcaption><\/figure>\n\n\n\n ![\"Eclipse's](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/code_style_eclipse.png\")
<\/a>Eclipse's \"Eclipse\" formatter<\/figcaption><\/figure>\n\n\n\n ![\"Eclipse's](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/code_style_eclipse_2.1.png\")
<\/a>Eclipse's \"Eclipse 2.1\" formatter<\/figcaption><\/figure>\n\n\n\n ![\"IntelliJ's](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/code_style_intellij.png\")
<\/a>IntelliJ's \"Default\" formatter<\/figcaption><\/figure>\n\n\n\n ![\"Google](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/code_style_google.png\")
<\/a>Google Java Style<\/figcaption><\/figure>\n\n\n\n ![\"Google](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/code_style_google_4spaces.png\")
<\/a>Google Java Style with 4-space indentation<\/figcaption><\/figure>\n<\/figure>\n\n\n\n Wie ihr seht, sind alle Styles recht \u00e4hnlich. In allen wird eine leicht abgewandelte Variante des sogenannte \"One True Brace Style<\/a>\" (1TBS) oder auch \"Kernighan & Ritchie Style\" (K&R) verwendet: Die \u00f6ffnende geschweifte Klammer befindet sich in derselben Zeile wie die zugeh\u00f6rige Klassen- bzw. Methodendefinition oder des entsprechenden Control-Statements.<\/p>\n\n\n\n
Unterschiede sieht man in Details, wie bspw. <\/p>\n\n\n\n
- \n
- ob in einer Array-Definition zwischen den eckigen und den geschweiften Klammern oder auch innerhalb der geschweiften Klamern Leerzeichen stehen, <\/li>\n\n\n\n
- ob geschweifte Klammern um einzelne Statements erforderlich oder optional sind,<\/li>\n\n\n\n
- ob einzelne Statements in derselben Zeile direkt hinter dem Control Statement stehen d\u00fcrfen,<\/li>\n\n\n\n
- ob Leerzeilen entfernt oder eingef\u00fcgt werden.<\/li>\n<\/ul>\n\n\n\n
Gerade diese Details sind es, die beim Review st\u00f6ren, insbesondere wenn man Code-\u00c4nderungen hervorhebt und dann die beabsichtigten \u00c4nderungen aus dem Grundrauschen der vielen kleinen Formatierungs\u00e4nderungen herausfiltern muss.<\/p>\n\n\n\n
Wenn ihr einen eigenen Stil entwickelt, sollte dieser von den bekannten Stilen nur geringf\u00fcgig abweichen, sodass Entwickler sich nicht lange ungew\u00f6hnen m\u00fcssen, sondern den Stil m\u00f6glichst intuitiv verstehen k\u00f6nnen. Mein bevorzugter Stil entspricht im Prinzip Google Style (also insbesondere das erforderliche Setzen von geschweiften Klammern um einzelne Statements) mit dem einzigen Unterschied, dass ich um 4 Leerzeichen einr\u00fccke statt um 2, so wie ich es aus den urspr\u00fcnglichen Java Code Conventions gew\u00f6hnt bin.<\/p>\n\n\n\n
Wie kann statische Code-Analyse einheitlichen Code-Standard sicherstellen?<\/h3>\n\n\n\n
Moderne IDEs k\u00f6nnen den Code zwar formattieren, allerdings gibt es folgende zwei Einschr\u00e4nkungen:<\/p>\n\n\n\n
1. Sie k\u00f6nnen nicht alle Coding-Vorgaben sicherstellen, bspw. nicht die folgenden:<\/p>\n\n\n\n
- \n
- maximale Methoden- und Klassenl\u00e4nge,<\/li>\n\n\n\n
- maximale Anzahl \"Non Commenting Source Statements\" in einer Methode,<\/li>\n\n\n\n
- maximale Anzahl von Parametern einer Methode,<\/li>\n\n\n\n
- maximale Verschachtelungstiefe von Schleifen und Control-Statements.<\/li>\n<\/ul>\n\n\n\n
2. Sie k\u00f6nnen nicht sicherstellen, dass alle Entwickler die Formatter aktiviert und korrekt konfiguriert haben.<\/p>\n\n\n\n
Hier springen statische Code Analyse-Tools der Kategorie \"\u00dcberpr\u00fcfung des Code-Standards\" ein, die eben genau diese L\u00fccke schlie\u00dfen. Sind die entsprechenden Tools einmal konfiguriert und in die Build-Pipeline integriert, dann ist sichergestellt, dass \u00fcber das gesamte Projekt und von allen Teammitgliedern der gleiche Code-Stil verwendet wird. <\/p>\n\n\n\n
Tools zur \u00dcberpr\u00fcfung des Code-Standards<\/h3>\n\n\n\n
Der bekannteste Open-Source-Vertreter ist Checkstyle<\/a>. Checkstyle kann ziemlich flexibel konfiguriert und auf alle oben genannten Code-Stile angepasst werden. F\u00fcr den Google Java Style ist eine Checkstyle-Konfigurationsdatei zum Download verf\u00fcgbar. Ebenso kann Checkstyle in den Build-Prozess integriert werden, so dass dieser Warnungen ausgibt oder fehlschl\u00e4gt, wenn gegen die Regeln versto\u00dfen wurde. Auf Checkstyle werde ich im dritten Teil des Artikels detaillierter eingehen.<\/p>\n\n\n\n
Berechnung von Softwaremetriken<\/h2>\n\n\n\n
Softwaremetriken sind Funktionen, die bestimmte Qualit\u00e4tsmerkmale einer Software (wie z. B. Wartbarkeit, Erweiterbarkeit oder Verst\u00e4ndlichkeit) in einem objektiven und vergleichbaren numerischen Wert (z. B. \"maintainability index\", \"zyklomatische Komplexit\u00e4t\") darstellen. Softwaremetriken k\u00f6nnen Entwickler und Teams dabei helfen Qualit\u00e4tsziele zu erreichen. Dazu werden entsprechende Tools in den Build-Prozess integriert, um die Softwaremetriken zu berechnen und die Entwickler bei Abweichungen von zuvor festgelegten Sollwerten zu alarmieren.<\/p>\n\n\n\n
Welche Softwaremetriken gibt es?<\/h3>\n\n\n\n
Einige der bekanntesten Metriken sind die folgenden:<\/p>\n\n\n\n
Kompexit\u00e4tsmetriken:<\/p>\n\n\n\n
- \n
- Kopplung (coupling): das Ma\u00df der Abh\u00e4ngigkeiten zwischen den Modulen eines Systems \u2013 eine niedrige Kopplung f\u00fchrt zu besserer Verst\u00e4ndlichkeit und Wartbarkeit; <\/li>\n\n\n\n
- Koh\u00e4sion (cohesion): das Ma\u00df der Abh\u00e4ngigkeiten innerhalb eines Softwaremoduls <\/span>\u2013 eine hohe Koh\u00e4sion f\u00fchrt zu besserer Verst\u00e4ndlichkeit und Wartbarkeit;<\/span><\/li>\n\n\n\n
- Average Component Dependency: die durchschnittliche Anzahl von Abh\u00e4ngigkeiten der Komponenten in einem Softwaresystem;<\/li>\n\n\n\n
- Zirkul\u00e4ren Abh\u00e4ngigkeiten (circular dependencies): diese sind gleichzustellen mit einer hohen Kopplung der involvierten Module \u2013 keines kann alleinstehend wiederverwendet werden \u2013 und keines kann ohne die anderen verstanden werden;<\/span><\/li>\n\n\n\n
- Zyklomatische Komplexit\u00e4t (cyclomatic complexity): die Anzahl unterschiedlicher Pfade durch ein Softwaremodul \u2013 je h\u00f6her die zyklomatische Komplexit\u00e4t, desto schwieriger ist das Softwaremodul zu verstehen;<\/li>\n\n\n\n
- Maintainability Index: ein Wert, der sich aus der Kombination bestimmter anderer Metriken ergibt.<\/li>\n<\/ul>\n\n\n\n
Metriken zur Testabdeckung (code coverage \/ test coverage):<\/p>\n\n\n\n
- \n
- Line coverage: dieser Wert gibt an, wie viele Codezeilen im Verh\u00e4ltnis zur Gesamtanzahl der Codezeilen durch automatische Tests abgedeckt sind;<\/li>\n\n\n\n
- Branch coverage: das Verh\u00e4ltnis der durch Tests abgedeckten Programmablaufpfade zu den gesamt m\u00f6glichen Ablaufpfaden.<\/li>\n<\/ul>\n\n\n\n
Folgende Grafik zeigt die zirkul\u00e4ren Abh\u00e4ngigkeiten eines Projekts, an dem ich gearbeitet habe:<\/p>\n\n\n
\n![\"Zirkul\u00e4re](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2019\/08\/Circular_Package_Dependencies-800x510.png\")
<\/a>Zirkul\u00e4re Abh\u00e4ngigkeiten zwischen 63 Java-Packages<\/figcaption><\/figure>\n<\/div>\n\n\n Bis wir die zirkul\u00e4ren Abh\u00e4ngigkeiten aufgel\u00f6st hatten (durch Neuzuordnung von Klassen zu Packages sowie durch Anwendung des Dependency Inversion Principle<\/a>), war es unm\u00f6glich Teile des Codes in wiederverwendbare Module auszulagern. Auch war es insbesondere f\u00fcr neue Entwickler im Team sehr schwer sich in Code-Teile einzuarbeiten, da dies letztendlich ein zumindest grobes Verst\u00e4ndnis aller 63 Packages erforderte.<\/p>\n\n\n\n
Tools zur Berechnung von Softwaremetriken<\/h3>\n\n\n\n
Die bekanntesten Open-Source-Tools dieser Kategorie sind JaCoCo<\/a> und Cobertura<\/a> zur Messung der Testabdeckung, Sonargraph Explorer<\/a> f\u00fcr die Berechnung und Darstellung von (zyklischen) Abh\u00e4ngigkeiten, sowie SonarQube<\/a> f\u00fcr die Berechnung von Metriken zur Komplexit\u00e4t, Wartbarkeit, Zuverl\u00e4ssigkeit, Sicherheit und Testabdeckung.<\/p>\n\n\n\n
Erkennung von Fehlern im Code<\/h2>\n\n\n\n
Tools dieser Kategorie versuchen potentielle Fehler im Code zu finden, in dem sie h\u00e4ufig vorkommende Fehlermuster erkennen. Beispiele daf\u00fcr sind:<\/p>\n\n\n\n
- \n
- sichere\/potentielle
NullPointerException<\/code>s,<\/li>\n\n\n\n- Vergleich mit <\/span>
equals()<\/code> auf Objekten verschiedener Klassen<\/span>,<\/li>\n\n\n\n- Klassen, die
equals()<\/code> definieren, aber nichthashCode()<\/code> \u2013 bzw. vice versa,<\/li>\n\n\n\n- String-Vergleiche mit
==<\/code> oder!=<\/code> (so etwas ist entweder ein Fehler oder \u2013 wenn beabsichtigt \u2013 f\u00fcr den n\u00e4chsten Entwickler verwirrend und somit fehleranf\u00e4llig),<\/li>\n\n\n\nswitch<\/code>-Statements ohnedefault<\/code>-Option,<\/li>\n\n\n\nswitch<\/code>-Statements mit \"fall throughs\" (diese sind verwirrend, da der Leser oft nicht wei\u00df, ob sie beabsichtigt sind),<\/li>\n\n\n\n- unbenutze Konstruktor- oder Methodenparameter,<\/li>\n\n\n\n
- unbenutzte lokale Variablen,<\/li>\n\n\n\n
- unbenutzte private Felder und Methoden,<\/li>\n\n\n\n
- Resourcen, die nicht (in jedem Fall) geschlossen werden,<\/li>\n\n\n\n
- Objekte, die Referenzen auf ver\u00e4nderliche interne Objekte, wie bspw. Listen nach au\u00dfen sichtbar machen (anstatt Kopien oder Read-Only-Proxys)<\/span>,<\/li>\n\n\n\n
- fehlende
assert<\/code>-Statements in Unit-Tests.<\/li>\n<\/ul>\n\n\n\nStatische Code-Analyse-Tools zur Erkennung von Fehlern sind bspw. der Java-Compiler selbst (mit entsprechenden Parametern), die Open Source Tools PMD<\/a>, FindBugs<\/a> bzw. dessen Nachfolger SpotBugs<\/a>, und SonarQube<\/a>, welche ich im dritten Teil der Artikelserie detailliert vorstellen werde.<\/p>\n\n\n\n
Erkennung von Sicherheitsl\u00fccken<\/h2>\n\n\n\n
Letztendlich werden Sicherheitsl\u00fccken in der Software durch Fehler im Code verursacht. In Abgrenzung zur vorangegangenen Kategorie handelt es sich hierbei jedoch um Fehler, die deutlich schwieriger zu erkennen sind, da hierf\u00fcr aufw\u00e4ndige Datenfluss-Analysen durchgef\u00fchrt werden m\u00fcssen: Es muss gepr\u00fcft werden, wie Eingabedaten durch das System und ggf. auch durch externe Libraries flie\u00dfen und verarbeitet werden, sowohl \u00fcber regul\u00e4re als auch au\u00dferordentliche Ausf\u00fchrungspfade. Beispiele f\u00fcr Sicherheitsl\u00fccken sind:<\/p>\n\n\n\n
- \n
- Command und SQL Injection: fehlende\/unzureichende Verifizierung von Eingabewerten kann dazu f\u00fchren, dass z. B. User-Eingaben in Formularen durch die Software als (SQL-)Kommandos interpretiert werden k\u00f6nnen (z. B. \"
; delete * from User;<\/code>\" \u2013 wird dies unver\u00e4ndert als Teil einer Query an die Datenbank geschickt, wird m\u00f6glicherweise die komplette User-Tabelle geleert);<\/li>\n\n\n\n- Fehler in der Zugriffskontrolle, so dass unberechtigte User Funktionen ausf\u00fchren k\u00f6nnen, f\u00fcr die sie keine Berechtigung haben (z. B. private Daten anderer User auslesen);<\/li>\n\n\n\n
- Cross-Site-Scripting: das Einschleusen von sch\u00e4dlichem ausf\u00fchrbaren Code z. B. \u00fcber Request-Parameter in einer URL;<\/li>\n\n\n\n
- Cross-Site-Request-Forgery: hierbei wird einem eingeloggten User eines Systems ein Link untergeschoben, \u00fcber den dieser unbewusst eine f\u00fcr ihn sch\u00e4dliche Aktion ausf\u00fchrt (z. B. k\u00f6nnte er dadurch sein Passwort auf ein durch den Angreifer festgelegtes Passwort \u00e4ndern, woraufhin dieser sich in den User-Account einloggen k\u00f6nnte).<\/li>\n<\/ul>\n\n\n\n
Wichtige Begriffe im Zusamenhang mit Softwaresicherheit sind:<\/p>\n\n\n\n
- \n
- CWE \u2013 Common Weakness Enumeration<\/a>: eine durch die Entwickler-Community erstellte Liste h\u00e4ufig auftretender Sicherheitsl\u00fccken, in der jeder Schwachstelle ein eindeutiger Bezeichner zugewiesen wird, wie bspw. CWE-77 f\u00fcr die oben erw\u00e4hnte \"Command Injection\" oder CWE-89 f\u00fcr \"SQL Injection\". Diese Liste ist nicht priorisiert. Sie dient sozusagen als gemeinsame Sprache: fast alle Softwaresicherheitstools geben bei erkannten Schwachstellen den entsprechenden CWE-Identifikator mit an.<\/li>\n\n\n\n
- OWASP \u2013 Open Web Application Security Project<\/a>: eine Non-Profit-Organisation mit dem Ziel die Sicherheit von Software zu erh\u00f6hen. Das bekannteste Projekt ist die \u201eOWASP Top 10<\/a>\u201c-Liste, die die aktuell zehn kritischsten Sicherheitsrisiken von Webanwendungen (einschlie\u00dflich ihrer CWE-Klassifikation) auflistet. Die Liste wurde zuletzt 2017 aktualisiert.<\/li>\n\n\n\n
- CWE\/SANS Top 25 Most Dangerous Software Errors<\/a>: eine alternative Liste der 25 kritischsten Sicherheitsrisiken \u2013 allerdings seit 2011 nicht aktualisiert.<\/li>\n<\/ul>\n\n\n\n
Diese Listen sind priorisiert und k\u00f6nnen somit verwendet werden, um die Behebung von Sicherheitsl\u00fccken zu priorisieren (s. Rollout-Strategie<\/a>).<\/p>\n\n\n\n
OWASP-Benchmark<\/h3>\n\n\n\n
Ein weiteres OWASP-Projekt ist der OWASP-Benchmark<\/a>. Diese kostenlose, quelloffene Test-Suite pr\u00fcft, wie gut ein Softwaresicherheitstool bestimmte Schwachstellen aufsp\u00fcrt, d. h. wie viele tats\u00e4chliche Fehler es findet und \u2013 dem gegen\u00fcbergestellt \u2013 wie viele false positives es meldet. Der OWASP-Benchmark hilft die verf\u00fcgbaren Sicherheitstools untereinander zu vergleichen und entsprechend den Anforderungen an die Softwaresicherheit zu beurteilen.<\/p>\n\n\n\n
Tools f\u00fcr die Erkennung von Sicherheitsl\u00fccken<\/h3>\n\n\n\n
Im Open-Source-Bereich sind mir hier Find Security Bugs<\/a>, ein FindBugs\/SpotBugs-Plugin, und das oben bereits erw\u00e4hnte SonarQube<\/a> bekannt. Beide werde ich im dritten Teil der Serie n\u00e4her vorstellen. F\u00fcr Anwendungen mit erh\u00f6hten Sicherheitsanforderungen sollte man hier ggf. auf Tools kommerzieller Anbieter zur\u00fcckgreifen, welche allerdings au\u00dferhalb des Rahmens dieser Artikelserie liegen.<\/p>\n\n\n\n
- OWASP \u2013 Open Web Application Security Project<\/a>: eine Non-Profit-Organisation mit dem Ziel die Sicherheit von Software zu erh\u00f6hen. Das bekannteste Projekt ist die \u201eOWASP Top 10<\/a>\u201c-Liste, die die aktuell zehn kritischsten Sicherheitsrisiken von Webanwendungen (einschlie\u00dflich ihrer CWE-Klassifikation) auflistet. Die Liste wurde zuletzt 2017 aktualisiert.<\/li>\n\n\n\n
- Vergleich mit <\/span>
- sichere\/potentielle