---
title: "SAMM 0→3 im KMU: 12 Monate, fünf Praktiken und die richtige Reihenfolge - OkamiOps Insights"
description: "OWASP SAMM umfasst 90 Aktivitäten und eine Skala von 0 bis 3 pro Praxis. Im offiziellen Benchmark, geprägt von Konzernen, liegt der Durchschnitt bei 1,44"
url: https://okamiops.com/de/insights/appsec-maturity-smb-2026/
lang: de
alternates:
  en: https://okamiops.com/insights/appsec-maturity-smb-2026/
  pt-BR: https://okamiops.com/pt/insights/appsec-maturity-smb-2026/
  de: https://okamiops.com/de/insights/appsec-maturity-smb-2026/
  x-default: https://okamiops.com/insights/appsec-maturity-smb-2026/
lastmod: 2026-09-10
---

# SAMM 0→3 im KMU: 12 Monate, fünf Praktiken und die richtige Reihenfolge

APPSEC · FEV · 2026 · 8 min

OWASP SAMM umfasst 90 Aktivitäten und eine Skala von 0 bis 3 pro Praxis. Im offiziellen Benchmark, geprägt von Konzernen, liegt der Durchschnitt bei 1,44 — Verification bei 1,12. Die Latte für Reife hängt tiefer, als das Wort vermuten lässt. Mit engem Scope und der richtigen Reihenfolge erreicht ein KMU Stufe 3 in den kritischen Praktiken in vier Quartalen.

- **Kategorie**: AppSec
- **Datum**: FEV · 2026
- **Lesezeit**: 8 min
- **Quellen**: 8

Stufe 0 in OWASP SAMM bedeutet nicht, dass das Team schlecht ist. Sie bedeutet, dass die Praxis in keiner erkennbaren Form existiert: niemand hat sie aufgeschrieben, niemand wiederholt sie, niemand misst sie. Dort startet fast jedes Unternehmen mit 20 bis 200 Personen, auch jene, die seit Jahren CI/CD betreiben und irgendwo einen Scanner laufen haben.

Die Frage der Kundschaft lautet nicht, was SAMM wert ist. Sie lautet, wie lange es dauert, bis das aufhört wehzutun. Die ehrliche Antwort: bei den Praktiken, die zählen, neun bis zwölf Monate. Was bremst, ist nicht die Komplexität des Modells. Es ist die Reihenfolge, in der man vorgeht.

**Der Fahrplan in drei Zahlen**

- **9–12 Monate** — bis Stufe 3 in den kritischen Praktiken
- **5 Praktiken** — bündeln die Risikosenkung pro investiertem Euro
- **8h + 2h /Woche** — ein verantwortlicher Senior + 2h je Squad, ohne Neueinstellung

## Das Modell ist kleiner, als es aussieht

SAMM v2 hat fünf Business Functions: Governance, Design, Implementation, Verification und Operations. Jede Funktion enthält drei Security Practices, macht fünfzehn. Jede Praxis teilt sich in zwei Streams, jeder Stream hat drei Stufen. Fünf mal drei mal zwei mal drei: neunzig Aktivitäten. Das ist das ganze Modell, und es passt in eine Tabelle.

Stufe 0 ist implizit — die Aktivität findet nicht statt. Stufe 1 heißt meist: tu es bewusst, auch wenn ad hoc. Stufe 2 heißt: standardisieren und automatisieren. Stufe 3 heißt: als Regel durchsetzen und mit Daten optimieren. Der Verlauf ist in allen fünfzehn Praktiken gleich, was das Modell planbar macht.

Der SAMM-Leitfaden selbst sagt, dass Vorbereiten, Bewerten, Ziel setzen und Plan erstellen — die ersten vier Schritte — eine Person ein bis zwei Tage kosten. Die Schritte 5 und 6, Umsetzen und Ausrollen, verschlingen die Monate. Die Diagnose war nie der Engpass.

Der offizielle Benchmark kalibriert die Erwartung. Er umfasst 30 Assessments, über 80% davon durch externe Assessoren, rund 60% aus Konzernen. Der Gesamtdurchschnitt liegt bei 1,44 von 3,0. Nach Funktion: Operations 1,81, Design 1,50, Implementation 1,46, Governance 1,35 und Verification 1,12. Der Bericht räumt ein, dass kleinere Unternehmen unterrepräsentiert sind.

Lies die niedrigste Zahl noch einmal. Verification — Security Testing, Prüfung der Anforderungen, Architekturbewertung — liegt bei 1,12, in einem Datensatz voller Großunternehmen. AppSec-Reife ist kein Budgetprivileg. Sie ist eine Folge von Methode.

## Die fünf Praktiken, die das Risiko zuerst bewegen

Nicht jede Praxis zahlt gleich. Fünf davon bündeln die Risikosenkung pro investiertem Euro, und die Reihenfolge zwischen ihnen zählt mehr als die Werkzeugwahl.

Secure Build. Stufe 1: Der Build-Prozess ist dokumentiert und wiederholbar, und du führst eine Bill of Materials der Abhängigkeiten. Stufe 2: automatisierte Pipeline, gehärtetes Build-Tooling, laufende Sicherheitsprüfungen. Stufe 3: Die Prüfungen sind verpflichtend, und der Build eines nicht konformen Artefakts schlägt fehl. Das ist der günstigste Sprung im Set, weil es Pipeline-Konfiguration ist und keine Teamumstellung. Und es ist der einzige, der Rückschritte verhindert.

Secure Deployment. Stufe 1: formalisiertes Deployment, gehärtetes Tooling, eingeschränkter Zugriff auf Produktionsgeheimnisse. Stufe 2: Deployment über alle Stufen automatisiert, mit Sicherheitsverifikationstests, und Secrets dynamisch aus einem Tresor injiziert, mit auditiertem menschlichem Zugriff. Stufe 3: Die Integrität jeder ausgelieferten Software wird automatisch geprüft. Günstig bis Stufe 2. Teuer bei 3, weil Signatur und Provenienz nötig werden.

Defect Management. Stufe 1: strukturierte Erfassung der Sicherheitsdefekte. Stufe 2: Schweregrade konsistent bewertet und ein SLA je Klasse. Stufe 3: SLAs durchgesetzt und das Defektsystem an das übrige Tooling angebunden. Fast null Kosten für Lizenzen, hohe Kosten an Disziplin. Hier bleibt die Mehrheit stecken, und die Benchmark-Analyse zeigt genau diese Schwachstelle: fehlende brauchbare Metriken.

Security Testing. Stufe 1: automatisierte Werkzeuge im Einsatz, dazu manuelle Tests der risikoreichsten Komponenten. Stufe 2: anwendungsspezifische Automatisierung und manueller Penetrationstest. Stufe 3: Sicherheitstests in Build, Deployment und Entwicklungsprozess integriert. Stufe 1 ist ein Nachmittag Arbeit. Stufe 2 verlangt Missbrauchsfälle für die eigenen Geschäftsregeln, und genau dort zeigt der Benchmark, dass die Mehrheit stehen bleibt.

Threat Assessment. Stufe 1: ein einfaches Risikoprofil der Anwendung und Threat Modeling nach bestem Bemühen, mit Brainstorming, den vorhandenen Diagrammen und einer schlichten Checkliste. Stufe 2: standardisierte Schulung, Prozesse und Werkzeuge. Stufe 3: kontinuierlich optimierte und automatisierte Methodik. Threat Modeling gehört im Benchmark zu den schwächsten Praktiken, und die Lesart der Assessoren ist unmissverständlich: Unternehmen halten die Praxis für esoterisch. Die pragmatische Variante passt in eine zweistündige Sitzung pro Service.

**Was Stufe 1, 2 und 3 in den fünf Praktiken bedeuten** (OWASP SAMM v2 · Skala 0–3 je Stream)

|  | Stufe 1 | Stufe 2 | Stufe 3 |
| --- | --- | --- | --- |
| Secure Build | Dokumentierter, wiederholbarer Build-Prozess, mit SBOM der Abhängigkeiten | Automatisierte Pipeline, abgesicherte Werkzeuge, laufende Prüfungen | Verpflichtende Prüfungen — der Build eines nicht konformen Artefakts schlägt fehl |
| Secure Deployment | Formalisiertes Deployment, abgesicherte Werkzeuge, eingeschränkter Zugriff auf Geheimnisse | Automatisiertes Deployment mit Verifikationstests; Geheimnisse über einen Tresor | Integrität der gesamten bereitgestellten Software automatisch verifiziert |
| Defect Management | Strukturierte Nachverfolgung von Sicherheitsmängeln | Konsistent bewertete Schwere + SLA je Klasse | SLA durchgesetzt und System in die übrigen Werkzeuge integriert |
| Security Testing | Automatisierte Tools + manueller Test des größten Risikos | Anwendungsspezifische Automatisierung + manueller Pentest | Tests in Build, Deployment und Entwicklung integriert |
| Threat Assessment | Grundlegendes Risikoprofil + Threat Modeling nach bestem Aufwand | Standardisierte Schulung, Prozesse und Werkzeuge | Methodik kontinuierlich optimiert und automatisiert |

## KI schreibt die Hälfte des Codes; die Prüfung ist nicht mitgewachsen

Der GenAI Code Security Report 2026 von Veracode hat über 100 Modelle bei Aufgaben zur Codegenerierung getestet. Die durchschnittliche Bestehensquote bei Sicherheit liegt bei 56%, gegenüber 55% im ersten Bericht. Rund 44% der Aufgaben erzeugten eine Schwachstelle. Das beste Modell im Set, GPT-5.5, erreicht 68% und scheitert immer noch an fast jeder dritten Sicherheitsaufgabe.

Die Verteilung ist nützlicher als der Durchschnitt. Kryptografie besteht in 87% der Fälle, SQL Injection in 83%. XSS besteht zu 15%. Log Injection zu 12%. Übersetzt: Das Modell hat parametrisierte Abfragen gelernt und verkettet weiterhin Ausgaben für Nutzende. Und Veracode schätzt, dass KI in Organisationen, die solche Werkzeuge einsetzen, bereits etwa die Hälfte des committeten Codes schreibt.

Das Abhängigkeitsvolumen zieht mit. Sonatype hat 2025 über 454.600 neue schädliche Pakete identifiziert, bei einem laufenden Gesamtbestand von 1,233 Millionen blockierten Paketen. In 55,9% der Fälle ist der Vektor der Missbrauch des öffentlichen Registrys selbst.

Der Effekt zeigt sich als Schuldenberg. Im State of Software Security 2026 von Veracode betrifft Security Debt 82% der Organisationen, gegenüber 74% im Jahr 2025 und 71% im Jahr 2024. Kritische Schuld — ein schwerer Fund, der länger als ein Jahr offen ist — steigt auf 60%. Hochriskante Schwachstellen wuchsen in zwölf Monaten um 36%.

Die praktische Schlussfolgerung lautet nicht: hört auf, KI zu nutzen. Sie lautet: Der Engpass ist vom Schreiben zur Prüfung gewandert. Build-Gates und automatisierte Tests sind keine gute Praxis mehr, sondern Betriebsbedingung. Kein KMU-Team prüft doppelt so viel Code manuell mit derselben Personalstärke.

## Der Plan, Quartal für Quartal

Annahmen verschieben den Zeitplan, deshalb gehören sie ausgesprochen: 15 bis 40 Personen in der Entwicklung, 3 bis 8 Services in Produktion, ein einziger CI-Anbieter, ein Senior Engineer als technisch verantwortliche Person mit 8 Stunden pro Woche, dazu 2 Stunden pro Woche je Squad, und offene Werkzeuge — SAST, Dependency- und Image-Scanner, DAST und ein Secrets-Tresor. Ohne dedizierte Neueinstellung. Bei 40 Repositories und drei CI-Anbietern kommt ein Quartal dazu.

Quartal 1 — Secure Build auf Stufe 2, Defect Management auf Stufe 1. Eine Referenz-Pipeline, eine SBOM bei jedem Build, Dependency- und Secret-Scanning im Warnmodus, und eine einzige Queue für Sicherheitsdefekte. Noch blockiert nichts. Ziel des Quartals sind Zahlen, keine Gates.

Quartal 2 — Secure Build auf Stufe 3, Security Testing auf Stufe 1. Die Prüfungen werden verpflichtend, und der Build schlägt bei einem neuen kritischen Fund fehl. Die Regel, die den Zeitplan rettet: Blockiere nur, was neu ist. Altlasten laufen über die Queue mit SLA, nicht über das Gate. Sonst schaltet das Team das Gate am ersten Freitag ab.

Quartal 3 — Threat Assessment auf Stufe 1 und 2, Secure Deployment auf Stufe 2. Ein Risikoprofil je Service, eine Threat-Modeling-Sitzung je Service mit Checkliste, und Secrets wandern aus Umgebungsvariablen in einen Tresor mit dynamischer Injektion und auditiertem menschlichem Zugriff. Das Quartal mit den meisten Gesprächen und dem wenigsten Tooling.

Quartal 4 — Security Testing auf Stufe 2, Defect Management auf Stufe 2 und 3. Missbrauchsfälle für die kritischen Geschäftsregeln geschrieben, ein externer Penetrationstest beauftragt, ein SLA je Schweregrad veröffentlicht und durchgesetzt. Am Ende des vierten Quartals steht Stufe 3 dort, wo sie das Risiko verändert, und Stufe 2 im übrigen Kern. Governance und Operations steigen im Windschatten mit: versionierte Richtlinien und Incident Response werden zur Folge dessen, was gebaut wurde.

**Der Plan, Quartal für Quartal**

- **Q1** — Secure Build auf Stufe 2 + Defect Management auf Stufe 1 — nur messen, noch nichts blockiert
- **Q2** — Secure Build auf Stufe 3 + Security Testing auf Stufe 1 — verpflichtendes Gate nur für neue Funde
- **Q3** — Threat Assessment auf Stufe 1–2 + Secure Deployment auf Stufe 2 — Secrets wandern von .env in den Tresor
- **Q4** — Security Testing auf Stufe 2 + Defect Management auf Stufe 2–3 — externer Pentest und veröffentlichtes SLA

## Messen, ohne die Punktzahl zu frisieren

Der SAMM-Wert ist ein Nebenprodukt. Wird er zum Ziel, lernt das Team, Häkchen zu setzen. Vier Messgrößen widerstehen der Manipulation besser.

Anteil der Builds, die das verpflichtende Gate durchlaufen haben, nicht Anteil der Repositories mit installiertem Scanner. Medianzeit von Fund bis Behebung je Schweregrad, gemessen in der Defekt-Queue und gegen das veröffentlichte SLA gehalten. Alter des ältesten offenen kritischen Funds, die einzige Zahl, die verborgene Schuld offenlegt. Und der Anteil der Funde aus der Pipeline statt aus externem Audit: Findet der Pentest weiterhin, was die Pipeline abfangen sollte, ist die Pipeline Dekoration.

**Vier Messgrößen, die der Manipulation widerstehen**

1. **% Builds durchs verpflichtende Gate** — Nicht der Anteil der Repos mit installiertem Scanner — misst, was wirklich blockiert, nicht was nur läuft.
2. **Mediane Zeit von Fund bis Behebung** — Je Schweregrad, gemessen in der Defekt-Queue und gegen das veröffentlichte SLA geprüft.
3. **Alter des ältesten offenen kritischen Funds** — Die einzige Zahl, die verborgene Schuld offenlegt.
4. **Anteil der Funde aus der Pipeline** — Statt aus externem Audit: Findet der Pentest weiterhin, was die Pipeline abfangen sollte, ist die Pipeline Dekoration.

Zwei Hygieneregeln. Friere den Scope des Assessments ein, mit demselben Satz an Services in jeder Runde, sonst steigt der Durchschnitt, ohne dass sich etwas ändert. Und verlange Belege: ein Artefakt, ein Log, eine versionierte Konfiguration. Im SAMM-Benchmark wurden über 80% der Assessments von Dritten durchgeführt, und das ist kein Zufall.

Wer in ein anderes Vokabular übersetzen muss: NIST SSDF (SP 800-218) bringt 19 Praktiken und 42 Aufgaben in vier Gruppen und taugt gut als gemeinsame Sprache mit Kundschaft und Audit. OWASP DSOMM geht hinunter bis zur technischen Pipeline-Aktivität. Und der 12-Schritte-Leitfaden der ENISA deckt ab, was außerhalb des Codes liegt.

**SAMM in den kritischen Praktiken · KMU · Monat 0 vs Monat 12** (Stufe 3 = Maximum des Modells)

| Element | Wert |
| --- | --- |
| secure build · M0 | 0 |
| secure build · M12 | 3 |
| security testing · M0 | 0 |
| security testing · M12 | 2 |
| threat assessment · M0 | 0 |
| threat assessment · M12 | 2 |
| defect management · M0 | 1 |
| defect management · M12 | 2 |

> **Was Sie morgen tun sollten**: Fang mit Secure Build an: ein verpflichtendes Gate, das nur neue Funde blockiert, während Altlasten über eine Queue mit SLA laufen. Es ist die einzige Änderung, die Rückschritte verhindert, während der Rest steigt.

## Quellen dieser Analyse

- **01**: [OWASP SAMM · The Model (v2)](https://owaspsamm.org/model/)
- **02**: [OWASP SAMM · The SAMM Benchmark Report](https://owaspsamm.org/benchmark/benchmark-report/)
- **03**: [OWASP SAMM · Quick Start Guide](https://owaspsamm.org/docs/getting-started/)
- **04**: [Veracode · 2026 State of Software Security](https://www.veracode.com/blog/2026-state-of-software-security-report-risky-security-debt/)
- **05**: [Veracode · 2026 GenAI Code Security Report](https://www.veracode.com/blog/2026-genai-code-security-report-ai-risk/)
- **06**: [Sonatype · 2026 State of the Software Supply Chain](https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware)
- **07**: [NIST · SP 800-218 Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- **08**: [ENISA · Cybersecurity guide for SMEs: 12 steps](https://www.enisa.europa.eu/publications/cybersecurity-guide-for-smes)

## Weiterlesen

- **CONSULTORIA · AGO · 2026**: [Was KI 2026 wirklich kostet: drei Stufen, mit offener Rechnung](https://okamiops.com/de/insights/quanto-custa-implementar-ia-2026/) (6 min)
- **GATEWAY · JUL · 2026**: [LLM-Output-Preise unterscheiden sich um 106×. Ihr KMU zahlt den Höchstpreis.](https://okamiops.com/de/insights/llm-cost-spread-2026/) (6 min)
- **APPSEC · ABR · 2026**: [OWASP LLM Top 10 (2025): fünf Risiken mit realen Vorfällen — und wie Sie jedes abdecken](https://okamiops.com/de/insights/owasp-llm-top-10-2025/) (8 min)

## Keine lose Meinung. Jede Zahl hat eine Quelle, jeder Artikel endet mit was zu tun ist.

Wir schreiben, was wir beim Lösen des Problems für einen Kunden lernen. Wenn Ihr Fall einem davon ähnelt, beginnt das Gespräch hier.