Security von Anfang an integrieren mit OWASP SAMM

Anschaulich wird das am Beispiel Threat Modeling. Als Aktivität in der Entwurfsphase findet es sich in der Business Function „Design“ und in der Practice „Threat Assessment“.

• Ausgehend von Level 0 (gar kein Threat Modeling) definiert OWASP SAMM die Anforderungen für die drei folgenden Reifegrade.
• Um Level 1 zu erfüllen, muss Threat Modeling mindestens für wichtige Anwendungen durchgeführt werden. Dabei gibt es noch keine großen Anforderungen an Umfang oder Frequenz. Die Nutzung einfacher Checklisten und die Dokumentation der Ergebnisse sind hier ausreichend.
• Für Level 2 muss Threat Modeling standardisiert eingeführt sein. Die beteiligten Personen müssen geschult sein, und die Bedrohungsanalyse muss umfangreicher durchgeführt werden. Außerdem muss festgelegt sein, wann eine Session jeweils durchgeführt werden soll.
• In Level 3 soll Threat Modeling mit anderen Aktivitäten integriert werden, zum Beispiel darauf aufbauende Security-Tests. Das soll möglichst automatisiert geschehen. Außerdem sollen die Prozesse und Vorlagen nun regelmäßig überarbeitet werden; Erfahrungen aus der Vergangenheit sollen in neue Bedrohungsszenarien einfließen.

In Kombination bietet das OWASP SAMM so einen breiten Überblick über die Phasen des Entwicklungsprozesses: mit 90 konkreten Aktivitätsbeschreibungen und zugehörigen Checklisten, um die Zielerreichung auf jedem Level systematisch zu überprüfen.

Strategisches Sicherheitsmanagement

Die Business Function „Governance“ legt den organisatorischen und strategischen Rahmen für sichere Softwareentwicklung fest. Vorausgeschickt sei der Hinweis, dass dies häufig der am wenigsten entwickelte Bereich in Entwicklungsteams ist. Meist starten Organisationen aus einer technischen Umsetzungsperspektive und bauen erst später einen einheitlichen Rahmen darum. Im Zentrum der Governance steht die Entwicklung einer Sicherheitsstrategie, die zur Unternehmensausrichtung passt und konkrete Ziele vorgibt. Dafür muss die Sicherheitsstrategie an die generelle Risikobereitschaft der Organisation anknüpfen. Mit Hilfe geeigneter Metriken lässt sich die Wirksamkeit von Sicherheitsmaßnahmen messbar machen und steuern.

Ein weiterer Fokus liegt auf Policies und Compliance. Dabei geht es einerseits um interne Sicherheitsrichtlinien, die klar, verbindlich und verständlich formuliert sind, und andererseits um die Identifikation und Einhaltung externer Anforderungen wie gesetzlicher Vorgaben oder branchenspezifischer Standards.

Abgerundet wird die Business Function durch Punkte zu Schulung und Awareness-Maßnahmen. Die beteiligten Rollen, etwa Entwickelnde, Architekt:innen und Betriebsteams, sollen durch Trainings in die Lage versetzt werden, Sicherheitsaspekte eigenverantwortlich zu verstehen und umzusetzen. Und zwar nicht als Zusatzaufgabe, sondern als integraler Bestandteil ihrer täglichen Arbeit. Ergänzt wird das durch den Aufbau einer Sicherheitsorganisation, die in Level 1 aus einzelnen Security-Champions und in Level 2 und 3 aus umfangreichen Strukturen besteht.

Sicheres Softwaredesign

Die Business Function „Design“ umfasst mehrere wichtige Aktivitäten, die im Entwurf einer Software von Bedeutung sind. Das beginnt bei der Einstufung des Schutzbedarfs der Anwendung (Application Risk Profile), basierend auf der Bedeutung des Systems für das Geschäftsmodell. Darauf aufbauend kann dann eine konkrete Bedrohungsanalyse (Threat Modeling) vorgenommen werden. Im Threat Modeling werden die Motivation und Möglichkeiten von Angreifern systematisch untersucht. Wird die eigene Bedrohungssituation genau verstanden, können auch passende Gegenmaßnahmen festgelegt werden.

Im Bereich Security Requirements geht es zum einen um die Festlegung ganz grundsätzlicher Sicherheitsanforderungen und deren Integration in die Implementierungsprozesse. Außerdem behandelt OWASP SAMM hier die Anforderungen an Third-Party-Software und Dienstleister.

Zuletzt wird der Bereich Architektur betrachtet. OWASP SAMM fordert hier gemeinsame Sicherheitsprinzipien, zentralisierte Security-Services und die Evaluierung und gegebenenfalls Vereinheitlichung von Tech-Stacks.

Sichere Implementierung

Die Business Function „Implementation“ befasst sich mit der sicheren Umsetzung von Software auf Code- und Build-Ebene. Ein zentrales Thema ist die Verwendung sicherer Entwicklungspraktiken. Dabei geht es nicht nur um das Vermeiden klassischer Schwachstellen wie SQL Injection oder XSS, sondern auch um das Aufstellen und Einhalten interner Codestandards, die Sicherheitsaspekte systematisch berücksichtigen. OWASP SAMM adressiert zudem Build- und Deployment-Prozesse: Diese sollten für Level 1 mindestens formalisiert, für Level 2 sogar automatisiert sein. Das Ziel ist, dass nur reproduzierbar geprüfter, freigegebener Code produktiv geht.

Ein weiterer Fokus liegt auf dem Umgang mit Abhängigkeiten zu Drittsystemen und Open-Source-Komponenten. Hier gilt es, bekannte Schwachstellen frühzeitig zu identifizieren und systematisch zu beheben. Dazugehört schon in Level 1 die Erstellung einer Software Bill of Materials (SBOM) und der Einsatz von Dependency-Scanning-Tools ebenso wie später klare Richtlinien für den Einsatz externer Bibliotheken.

Testen auf Security

Die vierte Business Function „Verification“ umfasst alle sicherheitsrelevanten Testaktivitäten, mit denen die Umsetzung der Sicherheitsanforderungen und die Resilienz der Anwendung sichergestellt wird.

Ein wichtiger Bestandteil ist die Prüfung des Designs auf Architekturebene – etwa durch Security-Architecture-Reviews oder gezielte Untersuchung auf Designfehler, die sich nicht über klassische Tests abbilden lassen.

Darüber hinaus geht es auch darum, ob und wie gut Anforderungen an Sicherheit überhaupt getestet werden. Auch hier knüpft SAMM an die Aktivitäten aus der Designphase an und fordert die Überprüfung dort definierter Sicherheitsanforderungen und das Ableiten passender Testfälle auf die definierten Bedrohungsszenarien.

Schließlich betrachtet OWASP SAMM die Durchführung sicherheitsfokussierter Testmethoden wie statische Codeanalyse, dynamische Tests (z. B. mit DAST-Tools) oder Fuzzing. Das Ziel ist, potenzielle Schwachstellen möglichst früh zu erkennen und zu beseitigen. In Level 1 geschieht das unregelmäßig und nach Best Effort, für Level 2 dann umfangreicher und systematisch.

Sicherer Betrieb

Die letzte Business Function „Operations“ beschäftigt sich mit der Absicherung der Software im laufenden Betrieb – sowohl organisatorisch als auch technisch.

Ein zentrales Thema ist dabei Incident-Management: Die Teams sollten in der Lage sein, Sicherheitsvorfälle schnell zu erkennen, einzuordnen und kontrolliert zu bewältigen. Dazu gehören auf Level 1 ein einfaches Logging und Monitoring, auf Level 2 klare Prozesse, definierte Szenarien mit Zuständigkeiten und regelmäßige Übungen.

Ein weiterer Baustein ist das Environment-Management. Hier geht es um die sichere Konfiguration und den Betrieb der Systemumgebungen, insbesondere auch um Prozesse zum Updaten der Systeme. In Level 1 kann das noch gelegentlich geschehen, solange zumindest ein Überblick über die verwendeten Versionen besteht. Auf Level 2 müssen dann Prozesse aufgestellt werden, die externe Informationen berücksichtigen und Priorisierungen vornehmen.

Kontinuierliche Software-Security

Egal ob Threat Modeling, Dependency Updates oder Sicherheitstest: Security-Aktivitäten sind keine einmaligen Tasks, die dann für immer abgehakt werden. Sie müssen kontinuierlich durchgeführt und dafür in den Entwicklungsalltag integriert werden. Das OWASP SAMM fordert hier oft nur „regelmäßige“ Aktivitäten, die passende Auslegung ist häufig eine Herausforderung.

Hierfür empfehlen sich zwei grundsätzliche Vorgehensweisen: eine periodische Durchführung von Aktivitäten (Kasten: „Periodische Aktivitäten“) oder das Triggern von Aktivitäten durch andere Prozessschritte (Kasten: „Trigger-Aktivitäten“).

Beispiele für periodische Aktivitäten:

• Einmal täglich: Blick auf die Schwachstellen in Abhängigkeiten

• Einmal wöchentlich: Triage von Findings aus Schwachstellenscan

• Einmal monatlich: Update des übergreifenden Threat Models

• Einmal jährlich: Externer Pentest

Das sind selbstverständlich nur Vorschläge zur Frequenz dieser Aktivität. Komplexe Produkte mit sensiblen Daten erfordern vielleicht häufigere Tests, während rein interne Anwendungen einen geringeren Schutzbedarf haben.

Ein anderer Ansatz kann es sein, Security-Maßnahmen an bestehende Prozesse anzuknüpfen. Durch die Verbindung mit etablierten Aktivitäten fällt es leichter, an die Sicherheit zu denken. Hierfür bedarf es passender Trigger, die klar definiert und bereits im Entwicklungsprozess verankert sind. Im besten Fall kann so über die Zeit eine echte Gewohnheit entstehen.

Beispiele für Trigger-Aktivitäten:

• Statische Code-Analyse für jeden neuen Commit

• Misuse Testcase für jeden Happy Path Test

• Threat Modeling für jede neue Story

• SBOM-Generierung und Überprüfung für jedes neue Release

• Security-Training für jedes neue Teammitglied

Diese beiden Möglichkeiten sind hilfreich, um eine Securityaktivität von „gelegentlich, unregelmäßig“ (SAMM-Level 1) auf „regelmäßig, systematisch“ (Level 2) zu bringen.

Software-Security auf Organisationsebene

Mit diesen Aktivitäten können Entwicklungsteams Security in den verschiedenen Projektphasen verankern. In der Praxis stoßen sie dabei oft auf ähnliche Fragestellungen und Probleme: Welche Bedrohungslage ist für unsere Domäne relevant? Wie sichern wir unseren Tech-Stack passend ab? Wie konfigurieren wir die passenden Testtools? Es lohnt sich, wenn Organisationen und Unternehmen das übergreifend angehen. So können Sicherheitsüberlegungen zentral getroffen, einheitliche Tools und Services bereitgestellt und Wissen effizient ausgetauscht werden.

Das ist ein zentraler Gedanke des OWASP SAMM, insbesondere auf den Reifegradstufen zwei und drei und im Speziellen in der gesamten Business Function „Governance“. Die Aktivitäten hier schaffen die Voraussetzungen dafür, dass Sicherheit in der Organisation geplant, gesteuert, überwacht und weiterentwickelt werden kann. Es geht um das Aufstellen einer Sicherheitsstrategie, klare Richtlinien, messbare Ziele und Schulungen, die die Entwicklungsteams unterstützen.

Awareness und Training

Sicherheitsbewusstsein beginnt mit dem Verständnis der Risiken und der eigenen Verantwortung. Durch gezielte Awareness-Maßnahmen und rollenspezifische Schulungen wird sichergestellt, dass alle Beteiligten – von der Entwicklung bis zum Management – über relevante Bedrohungen, sichere Praktiken und geltende Richtlinien informiert sind. Training ist dabei kein einmaliges Event, sondern Teil eines kontinuierlichen Lernprozesses, der mit der Entwicklungstechnologie und Bedrohungslage mitwächst. Aus den geplanten Aktivitäten und den zuständigen Personen lassen sich so die richtigen Trainings für jede Rolle auswählen.

Vereinheitlichte Prozesse

Security-Entscheidungen sind selten binär. Oft müssen Abwägungen getroffen, Mittelwege sowie die richtige Balance gefunden werden. Entwicklungsteams fehlt oft der Überblick über das große Ganze der Sicherheitsaktivitäten, und sie haben mit anderen funktionalen und nichtfunktionalen Anforderungen bereits zahlreiche Entscheidungen zu treffen. Um diese Mental Load zu reduzieren und ein einheitliches Sicherheitsniveau herzustellen, sind produktübergreifende Überlegungen hilfreich. Diese münden in einheitliche Entwicklungsprozesse oder zumindest klare Rahmenbedingungen für die Teams.

OWASP SAMM bietet selbst einen Metarahmen für solche vereinheitlichten Prozesse. Er ist damit gleichzeitig Orientierungs- und Argumentationshilfe. Gegenüber dem Management eines Unternehmens können der etablierte Name und die erprobte Methodik genauso helfen, Akzeptanz und Unterstützung zu gewinnen wie gegenüber den Entwicklungsteams.

Der richtige Start mit OWASP SAMM

Eigentlich zielt SAMM auf ganze Organisationen ab, mit dem Ziel, einheitliche Vergleiche zu ermöglichen. Doch auch ein einzelnes Entwicklungsteam kann mit OWASP SAMM bereits eine gute Selbsteinschätzung der Reife der eigenen Security-Prozesse erhalten.

Dafür ist es notwendig, den Scope passend zu wählen. Zahlreiche Business Functions zielen gerade auf die übergreifende Betrachtung von Sicherheitsaktivitäten. Deshalb ist es sinnvoll, die Business Functions auf die Bereiche einzuschränken, die das Team selbst verantwortet. Das sind in der Regel mindestens die drei mittleren Bereiche Design, Implementation und Verification. Der übergreifende Bereich Governance hingegen ist für einzelne Teams oft nur begrenzt beeinflussbar, oder die beschriebenen Prozesse müssen explizit uminterpretiert werden. Ähnliches gilt für den Bereich Operations: Wenn das Team dem DevOps-Gedanken folgt und auch für den Betrieb verantwortlich ist, kann auch hier angesetzt werden. Ansonsten ist eine Einschätzung selbstverständlich auch, eine Verbesserung aber nur eingeschränkt möglich.

Mit ein wenig Flexibilität in der Auslegung der Formulierung kann das Entwicklungsteam so aber einen guten Überblick über die relevanten Bereiche bekommen und eine Beurteilung des eigenen Reifegrads erhalten.

OWASP SAMM organisationsweit einführen

Seine Stärken spielt OWASP SAMM dann aus, wenn es die Sicherheitsaktivitäten für eine ganze Organisation strukturiert. Das Modell bietet dann einen strukturierten und praxisnahen Rahmen, um Sicherheit systematisch in den gesamten Softwarelebenszyklus einer Organisation zu integrieren. Anders als punktuelle Maßnahmen oder technische Einzeltools betrachtet SAMM das große Ganze. Besonders hilfreich ist die Kombination aus Flexibilität und Struktur: Jedes Team kann dort starten, wo es steht, und sich schrittweise weiterentwickeln – mit einer Roadmap, die auf konkrete Risiken und Ressourcen abgestimmt ist.

Die Einführung von OWASP SAMM beginnt mit einer Istanalyse: In einem Assessment wird erhoben, wie gut sicherheitsrelevante Praktiken in den verschiedenen Bereichen des Softwareentwicklungsprozesses bereits umgesetzt sind – von der Governance über Design und Implementierung bis hin zu Testing und Betrieb. Dabei steht nicht die Bewertung einzelner Personen oder Teams im Fokus, sondern das gemeinsame Verständnis des aktuellen Stands. Das OWASP-SAMM-Projekt bietet hierfür zahlreiche Ressourcen und Tools, unter anderem eine Toolbox, mit der das Assessment vereinfacht werden kann. Empfohlen wird trotzdem ein zentralisiertes Assessment, etwa durch ein Security-Department, um eine Vergleichbarkeit zu gewährleisten. Ein Self-Assessment der Teams birgt die Gefahr unterschiedlicher Interpretationen.

Im Anschluss wird ein Zielreifegrad definiert – abgestimmt auf geschäftliche Anforderungen, regulatorische Rahmenbedingungen und vorhandene Ressourcen. Klassischerweise ist das zunächst Level 1. Das muss nicht zwingend in jedem Bereich gleichzeitig angestrebt werden. Vielmehr geht es darum, eine sinnvolle Zielsetzung zu finden, die zur Organisation, zur bestehenden Prozessreife und zu den Einflussmöglichkeiten der Teams passt.

Aus dem Vergleich von Ist- und Zielzustand entsteht eine Roadmap zur Verbesserung: Sie benennt konkrete Maßnahmen, priorisiert sie nach Aufwand und Wirkung und gibt Orientierung für die Umsetzung in der Praxis. Je nach Ausgangslage können erste Schritte schnell umsetzbar sein – etwa die Einführung strukturierter Threat-Modeling-Workshops oder die verbindliche Integration von Dependency-Scannern in den Build-Prozess.

Umsetzung der Maßnahmen

Im weiteren Verlauf werden die definierten Maßnahmen schrittweise umgesetzt und organisatorisch begleitet. Entscheidend ist dabei, dass Sicherheit nicht als zusätzlicher Ballast empfunden wird, sondern als Teil eines professionellen Entwicklungsprozesses. Dafür müssen die einzelnen Aktivitäten passend auf die bestehenden Rollen verteilt und auch neue Rollen etabliert werden, beispielsweise Security-Champions. Diese fungieren als Bindeglied zwischen dem Security-Department und den Entwicklungsteams.

Neben passenden Schulungen für diese Rollen bieten Vorlagen und Leitlinien eine wichtige Unterstützung für die Entwicklungsteams. Sollen die Teams individuelle Sicherheitsanforderungen aufstellen, so helfen konkrete Templates mit Vorschlägen als Orientierung. Sollen die Teams Tooling für Security-Tests integrieren, sind zentral bereitgestellte Lösungen hilfreich.

Messbarkeit und Verbesserungen

Ein zentraler Gedanke von SAMM ist die kontinuierliche Verbesserung: Durch passende Metriken lassen sich Fortschritte messen, neue Ziele setzen und Maßnahmen anpassen. Neben den direkten Reifegraden nach OWASP SAMM lassen sich weitere Metriken aufstellen. Empfohlen wird die Messung von Aufwand, Ergebnissen und Rahmenbedingungen.

Gerade für den Anfang gilt: Diese Metriken sollten ohne großen Aufwand erhebbar sein, im besten Fall sogar schon vorliegen und nur noch eingesammelt werden.

In der Gesamtschau (Aufwand vs. Ergebnisse im gegebenen Rahmen) können so Entwicklungen beobachtet werden. In der Realität benötigt es aber einige Zeit, bis echte Trends erkennbar sind. Umso wichtiger ist eine frühe, konsistente Erhebung der Zahlen, um später Erkenntnisse ziehen zu können. So kann Sicherheit nicht als einmaliges Projekt, sondern als lernender, nachhaltiger Prozess verankert werden.

Die Rolle einer zentralisierten Security

Sicherheit lässt sich durch spezialisierte Services gezielt unterstützen, etwa durch automatisierte Codeanalysen mit zentral bereitgestellten Tools, Threat-Modeling-Workshops, Dokumentation zu häufigen Architekturfragen oder bereitgestellten Vorlagen für die Incident-Response-Unterstützung. Diese Security-Services entlasten Produktteams, bündeln Know-how und sorgen für Konsistenz in der Umsetzung. Wichtig ist, dass sie frühzeitig eingebunden, gut erreichbar und an den Entwicklungsalltag angepasst sind – als Partner, nicht als Kontrollinstanz. Oft haben einzelne Teams schon funktionierende Lösungen, die nur noch für die Gemeinschaft generalisiert und bereitgestellt werden müssen.

Die Einführung von OWASP SAMM sollte nicht als reines Security-Projekt verstanden werden, sondern als organisationsweiter Veränderungsprozess. Damit dieser gelingt, ist eine transparente, kontinuierliche Kommunikation zentral, insbesondere gegenüber den Entwicklungsteams, die viele der Maßnahmen unmittelbar betreffen.

Bereits zu Beginn sollte klar vermittelt werden, warum SAMM eingeführt wird: nicht als Kontrolle, sondern um langfristig mehr Sicherheit mit weniger Reibungsverlust zu erreichen. Dabei hilft es, Risiken und Ziele aus der Perspektive der Produktverantwortung zu erklären. Wie hilft es uns, Ausfallzeiten zu vermeiden? Was bedeutet das für die eigentliche Featureentwicklung? Wie kommen wir vom Feuerlöschen in planvolles Handeln? Schon vom initialen Assessment an ist das wichtig. Frühzeitig eingebundene Teams fühlen sich nicht bewertet, sondern gehört und beteiligt.

Im Anschluss sollte die Roadmap nicht einfach „von oben herab“ festgelegt und ausgerollt werden. Stattdessen empfiehlt es sich, Pilotbereiche oder engagierte Teams zu identifizieren, mit denen erste Verbesserungen erprobt werden können. Erfolgsgeschichten aus diesen Bereichen – etwa ein besser automatisiertes Patchmanagement oder strukturierteres Threat Modeling – können dann als positive Narrative in die Breite kommuniziert und optimalerweise auch direkt übertragen werden.

Nicht zuletzt braucht es sichtbares Leadership Commitment: Wenn Führungskräfte Sicherheit zur Priorität erklären – auch bei Featuredruck – und sich aktiv für die Umsetzung der SAMM-Roadmap einsetzen, schafft das Vertrauen und Orientierung.

OWASP SAMM und zukünftige Regulatorik

Mit dem eingangs angesprochenen Cyber Resilience Act (CRA) zeichnet sich ein regulatorischer Wandel ab, der die sichere Softwareentwicklung von der freiwilligen Best Practice zur verbindlichen Pflicht macht. Hersteller digitaler Produkte müssen künftig nachweisen, dass sie Security by Design und Security by Default entlang des gesamten Produktlebenszyklus umsetzen.

OWASP SAMM bietet hierfür einen praxiserprobten Bezugsrahmen. Die einzelnen Security-Practices des Modells decken bereits zentrale Anforderungen des CRA ab, darunter Risikobewertungen, sichere Entwicklungsprozessschritte, Schwachstellenmanagement, Dokumentation und Incident Handling. Unternehmen, die SAMM bereits nutzen, schaffen damit eine nachvollziehbare Struktur, um Sicherheitsmaßnahmen nicht nur umzusetzen, sondern auch zu dokumentieren und im Rahmen von Audits oder Konformitätsbewertungen belegen zu können.

Besonders relevant wird SAMM dort, wo der CRA organisatorische und prozessuale Sicherheitspflichten fordert. So hilft etwa die Practice „Security Requirements“ beim formalen Nachweis sicherheitsrelevanter Anforderungen, während „Operational Management“ die kontinuierliche Überwachung und Pflege sicherheitskritischer Systeme adressiert.

Insgesamt kann SAMM als Übersetzungswerkzeug dienen: Es ermöglicht, technische und organisatorische Sicherheitsmaßnahmen in eine Form zu bringen, die regulatorisch anschlussfähig ist – ohne den Entwicklungsteams unnötige Bürokratie aufzubürden. Angesichts der kommenden regulatorischen Anforderungen ist OWASP SAMM damit nicht nur ein Reifegradmodell, sondern ein strategisches Werkzeug, um Sicherheit in Einklang mit rechtlichen Pflichten, operativer Umsetzbarkeit und wirtschaftlichen Zielen zu bringen.