OWASP, das offene
Toolkit für Anwendungssicherheit

OWASP steht für Open Worldwide Application Security Project. Es ist eine gemeinnützige Stiftung, die frei verfügbare, von der Community getragene Ressourcen erstellt, mit denen Teams sichere Software entwickeln und überprüfen. Es ist keine Zertifizierung, kein Gesetz und kein einzelnes Framework — es ist eine Sammlung von Standards, Leitlinien und Werkzeugen, an denen sich Engineering- und Application-Security-Teams ausrichten.

Diese Unterscheidung ist wichtig, denn über OWASP wird oft so gesprochen, als wäre es ein Abzeichen, das man verdient. Es gibt kein "OWASP-Zertifikat" und keinen Prüfer, der Sie gegen OWASP zertifiziert. Stattdessen sagen Teams, ihre Software sei "gegen die OWASP Top 10 getestet" oder "nach dem ASVS auf Stufe 2 gebaut" — sie richten sich nach einem veröffentlichten Standard aus, sie bestehen keine Prüfung.

OWASP versteht man am besten als Werkzeugkasten. Einige Projekte schaffen Bewusstsein für die wichtigsten Risiken; eines ist ein detaillierter, überprüfbarer Anforderungsstandard; ein weiteres ist ein Modell, um zu verbessern, wie Ihr Team Software baut. Sie wählen die Teile, die zu der Software passen, die Sie ausliefern.

Die OWASP Top 10 sind das Projekt, das die meisten meinen, wenn sie "OWASP" sagen. Es ist ein Awareness-Dokument, das die kritischsten Sicherheitsrisiken für Webanwendungen auflistet — Kategorien wie fehlerhafte Zugriffskontrolle, Injection, Sicherheits-Fehlkonfiguration und verwundbare Komponenten, gereiht danach, wie häufig und wie schwerwiegend sie in der Branche sind.

Sie wird regelmässig aktualisiert, wenn sich die Bedrohungslage verändert; die meistzitierte Ausgabe ist die Liste von 2021, eine neue Ausgabe ist in Arbeit. Jeder Eintrag ist eine Risikokategorie und kein einzelner Fehler, weshalb sie als Awareness- und Priorisierungswerkzeug funktioniert: Sie zeigt einem Team, woher der grösste Schaden tendenziell kommt, damit es weiss, wo es zuerst ansetzt.

Wichtig ist zu verstehen, was die Top 10 nicht sind. Sie sind keine Checkliste, gegen die man sich zertifiziert, und "die Top 10 abzudecken" bedeutet nicht, dass eine Anwendung sicher ist. Sie sind der Ausgangspunkt, die Risiken, gegenüber denen kein Team blind sein sollte, nicht die Ziellinie. Für einen überprüfbaren Standard, an dem Sie entwickeln und testen können, verweist OWASP auf das ASVS.

Beim OWASP Application Security Verification Standard (ASVS) wird aus Bewusstsein etwas Überprüfbares. Wo die Top 10 die Risiken benennen, ist das ASVS ein strukturiertes Gerüst detaillierter Sicherheitsanforderungen — für Authentifizierung, Session-Management, Zugriffskontrolle, Eingabevalidierung, Kryptografie und mehr, an denen Teams ihre Anwendungen entwerfen, entwickeln und testen.

Die Anforderungen sind in Stufen zunehmender Sicherheit gegliedert. Stufe 1 (L1) ist eine Grundlinie, die für die meisten Anwendungen angemessen und weitgehend von aussen prüfbar ist; Stufe 2 (L2) ist der Standard, den die meisten Anwendungen mit sensiblen Daten anstreben sollten; Stufe 3 (L3) ergänzt die Strenge, die man bei der kritischsten Software erwartet. Die Wahl einer Stufe legt die Messlatte fest, gegen die Ihre Anwendung geprüft wird.

In der Praxis ist das ASVS die Antwort, wenn jemand Nachweise statt Absichten verlangt. Es macht aus "wir folgen OWASP" eine konkrete Reihe von Anforderungen, auf die Sie Ihre Kontrollen und Testergebnisse abbilden können — genau das, was ein Prüfer oder ein sicherheitsbewusster Kunde sehen will.

OWASP SAMM (das Software Assurance Maturity Model) verschiebt die Frage von "ist diese Anwendung sicher?" zu "ist unsere Art, Software zu bauen, sicher?". Es ist ein Modell, um den Reifegrad Ihres sicheren Software-Entwicklungszyklus (secure SDLC) zu bewerten und zu verbessern — die Praktiken rund um Governance, Design, Implementierung, Verifizierung und Betrieb.

Mit SAMM kann ein Team messen, wo seine Praktiken zur Anwendungssicherheit heute stehen, ein realistisches Ziel setzen und die Schritte dorthin planen. Am nützlichsten ist es für Organisationen, die über einmalige Korrekturen hinaus sind und ein Programm wollen: eine bewusste, sich verbessernde Art, Software sicher zu bauen, statt einer Hektik vor jedem Release oder Audit.

SAMM und das ASVS ergänzen einander. Das ASVS prüft eine konkrete Anwendung gegen Anforderungen; SAMM lässt die Organisation reifen, die Anwendungen baut. Teams nutzen oft das ASVS, um die Messlatte für das zu heben, was sie ausliefern, und SAMM, um die Messlatte dafür zu heben, wie sie es ausliefern.

Webanwendungen sind nicht das Einzige, was Teams ausliefern, deshalb pflegt OWASP gezielte Projekte für andere Bereiche. Die OWASP API Security Top 10 spiegeln die Hauptliste, aber für APIs, und decken die für sie spezifischen Risiken ab — fehlerhafte Autorisierung auf Objektebene, fehlerhafte Authentifizierung und die übrigen Schwachstellen, die auftauchen, wenn Maschinen statt Browser die Clients sind.

Für Mobile übernimmt das OWASP MASVS (Mobile Application Security Verification Standard) die Rolle, die das ASVS für Web spielt: eine strukturierte Reihe überprüfbarer Sicherheitsanforderungen für mobile Apps. Wenn Ihr Produkt eine API-Plattform oder eine mobile Anwendung ist, sind das die OWASP-Projekte, die am direktesten auf das passen, was Sie bauen.

OWASP veröffentlicht ausserdem eine umfangreiche Bibliothek an unterstützendem Material — die Cheat Sheet Series mit prägnanten Umsetzungshinweisen sowie Werkzeuge wie ZAP für Sicherheitstests und Dependency-Check, um bekannte verwundbare Komponenten zu finden. Das sind weniger Standards, an denen man sich ausrichtet, als praktische Hilfe, um die gewählten zu erfüllen.

OWASP ist selten das Ziel an sich. Häufiger ist es die Art, wie Teams die Erwartungen an "sichere Entwicklung" umsetzen, die andere Frameworks verlangen, aber nicht ausformulieren. Diese Frameworks fordern, Software sicher zu entwickeln; OWASP ist die konkrete Antwort auf das Wie.

ISO 27001 enthält in Annex A eine Kontrolle für sichere Entwicklung; Ihre Entwicklung an OWASP auszurichten, gegen die Top 10 zu testen und nach dem ASVS zu bauen, ist ein praktischer Weg, das nachzuweisen. PCI DSS verweist auf Praktiken für sicheres Programmieren, und die OWASP Top 10 sind die Referenz, an der diese Praktiken üblicherweise verankert sind. SOC 2 betrachtet Ihre Change- und Entwicklungskontrollen, wo ein an OWASP ausgerichteter sicherer SDLC Ihnen etwas Konkretes liefert, worauf Sie verweisen können.

Wenn also eines dieser Frameworks fragt, wie Sie Software sicher bauen, ist "wir richten unseren SDLC an OWASP aus" oft die praktische, mit Nachweisen belegte Antwort. Die Arbeit, die Sie für die Ausrichtung an OWASP leisten, ist dieselbe, die diese Kontrollen verlangen — einmal erledigt und über alle hinweg wiederverwendet.

OWASP wird vor allem von den Menschen genutzt, die Software bauen und absichern: Engineering-Teams, Application-Security- und Product-Security-Fachleute sowie die Architekten, die Entwicklungsstandards setzen. Es ist herstellerneutral und frei verfügbar, weshalb es zur Standardreferenz geworden ist statt der Methodik eines einzelnen Anbieters.

Wie ein Team es nutzt, hängt vom Reifegrad ab. Ein Team am Anfang seines Wegs beginnt vielleicht damit, sicherzustellen, dass es den Risiken der OWASP Top 10 nicht ausgesetzt ist. Ein etablierteres Team entwirft und testet gegen das ASVS auf einer gewählten Stufe und nutzt SAMM, um laufend zu verbessern, wie es baut. Die Ressourcen skalieren von einem ersten Awareness-Durchgang bis zu einem gemessenen, kontinuierlich verbesserten Programm.

Weil es nichts gibt, wogegen man sich zertifiziert, bedeutet die Einführung von OWASP, zu wählen, wie Sie sich messen, und das dann konsequent zu tun. Der übliche Ansatz: die Top 10, um Bewusstsein und Prioritäten zu setzen, das ASVS auf einer gewählten Stufe als die Anforderungen, gegen die Sie prüfen, und SAMM, um den Reifegrad des Programms über die Zeit zu verfolgen.

Die praktische Herausforderung besteht darin, all das aktuell und verbunden zu halten. Die Ausrichtung an OWASP ist kein einmaliger Durchlauf: Anforderungen ändern sich, wenn die Standards überarbeitet werden, neuer Code bringt neues Risiko, und der Nachweis, dass Sie eine Anforderung tatsächlich erfüllen, muss gepflegt und nicht nur einmal erstellt werden. Teams, die ihre OWASP-Zuordnung in verstreuten Tabellen führen, finden sie veraltet vor, sobald ein Kunde oder Prüfer sie sehen will.

Das Ziel ist ein lebendiges Bild: welche ASVS-Anforderungen gelten, wo jede steht, was sie belegt und wie das auf die Compliance-Kontrollen abbildet, die sie ebenfalls erfüllt — aktuell gehalten, während sich Software und Standards beide bewegen.