Sicherheit, die eingebaut ist — nicht aufgesetzt.
Wir begleiten Ihre Software vom ersten Threat Model bis zum signierten Release. Mit STRIDE, OWASP, ISO/IEC 27034, SLSA — und Mapping auf CRA, NIS2, DORA und EU AI Act. Application Security als Engineering-Disziplin, nicht als Audit-Theater.
Application Security scheitert nicht an Tools. An Timing.
In den meisten Organisationen kommt Sicherheit erst am Ende ins Spiel — als Türsteher vor dem Release. Die Folge: teure Rückläufe, frustrierte Entwickler, lückenhafte Compliance. Drei strukturelle Muster sehen wir immer wieder.
Security als Türsteher
Pen-Test erst kurz vor Go-Live. Befunde landen Wochen nach dem Merge. Fixes werden zu Hotfixes. Niemand will mehr Security-Themen aufmachen, weil sie das Release verzögern.
Verteilte Verantwortung
Dev, AppSec, Compliance, Audit, Legal — vier Sprachen, vier Tools, vier Excel-Listen. Jede Gruppe weiß einen Teil, niemand sieht das Ganze. Wer ein konsistentes Sicherheitsbild eines Produkts haben will, baut es manuell.
Compliance ohne Evidenz
SBOMs werden manuell erstellt. Threat Models leben in einem Confluence von 2022. Audits werden zur Archäologie-Übung. Bei CRA, NIS2, DORA und EU AI Act reicht das in 24 Monaten nicht mehr.
„Sichere Software ist kein Audit-Ergebnis. Sie ist eine Entwicklungsdisziplin — die man einbauen muss, bevor der erste Commit fällt."
Sicherheit in jeder Phase. Nicht nur in einer.
Der Secure Software Development Lifecycle (SSDLC) ist keine zusätzliche Pipeline — es ist die richtige Pipeline. Wir verankern Security-Aktivitäten in allen sieben Phasen, mit klar definierten Artefakten und Gates.
Security Requirements Engineering
Schutzbedarfsanalyse, regulatorische Anforderungen, Use- und Misuse-Cases. Sicherheits- und Datenschutz-Ziele werden mit Business-Zielen gleichrangig in die Anforderungen geschrieben — nicht als Anhang.
Threat Modeling — STRIDE & MAESTRO
Wir modellieren Bedrohungen, bevor die erste Zeile Code entsteht. STRIDE für klassische Systeme, MAESTRO für KI-Komponenten. Resultat: priorisierte Mitigations, dokumentierte Designentscheidungen, audit-festes Threat Register.
Secure Coding & Developer Enablement
Coding Guidelines, sichere Defaults, Pull-Request-Templates mit Security-Checks. Hands-on-Schulungen, die Entwickler tatsächlich besuchen. Pair-Reviews mit AppSec für kritische Pfade. Sicherheit wird Teil der Engineering-Kultur.
SAST · SCA · Secret Scanning
Statische Code-Analyse, Software-Composition-Analysis und Secret-Scanning als Blocking-Gates in jeder Pipeline. Befunde werden priorisiert und kontextualisiert — keine 5.000-Findings-Reports, sondern handhabbare Backlogs.
Penetration Tests & DAST
Strukturierte Pen-Tests entlang OWASP ASVS, MASVS und ISVS. Dynamic Application Security Testing in Staging, mit ML-gesteuerter Test-Selection. Erkenntnisse fließen zurück in Threat Model und Secure Coding Guides.
SBOM · Provenance · Release Gate
Jedes Artefakt erzeugt SBOM und Provenance. Open-Policy-Agent prüft Compliance vor jedem Production-Deploy. Approver darf nicht Author sein. Signierte Releases, nachvollziehbare Build-Chain, SLSA Level 3 als Ziel.
Runtime Monitoring & Vulnerability Management
Anomalie-Detection auf Behavior-Baseline. CVE-Triaging mit Asset-Kontext. Incident-Playbooks, die zu DORA-Art.-17- und NIS2-Meldepflichten passen. Schwachstellen-Lebenszyklus bis zum verifizierten Fix.
Governance, Audit & KPIs
Was nicht messbar ist, wird nicht besser. Wir definieren Security-KPIs (MTTR, Mean Time to Detect, Backlog-Aging, Test-Coverage), liefern Dashboards für Vorstand und Auditor — und automatisieren die Evidenz-Sammlung über die gesamte Pipeline.
Drei Artefakte, sieben Phasen.
Vom ersten Threat Model über SAST-Gate bis zum signierten Release — alles maschinen-prüfbar, alles audit-fest.
Wir glauben, dass Application Security nicht durch mehr Tools entsteht, sondern durch klare Verantwortung, einbettbare Aktivitäten in jeder Phase und Evidenz, die der Auditor sieht, bevor er fragt.
Standards, die funktionieren.
Wir bauen nicht auf erfundene Methoden, sondern auf etablierte Standards — und kombinieren sie zu einem konsistenten Rahmen für Ihre Domäne.
Vom STRIDE-Threat-Model in der Architektur bis zur SLSA-Härtung der Build-Pipeline. Von OWASP ASVS für Web-Backends bis MASVS für mobile Apps und AISVS für KI-Komponenten. Standards sind die Sprache, in der Audit, Vorstand und Engineering sich verstehen.
Ein SSDLC. Vier Regularien. Ein Audit-Repo.
CRA, NIS2, DORA und der EU AI Act greifen alle direkt in den Software-Entwicklungsprozess. Wer den SSDLC sauber aufstellt, erfüllt die Pflichten gleichzeitig — statt vier parallele Compliance-Prozesse zu pflegen.
Security-by-design, SBOM, Vorfallsmeldung, Updates für 10 Jahre, Schwachstellen-Management. Im SSDLC verankert durch Threat Modeling (Phase 2), SAST/SCA (Phase 4), SBOM & Signing (Phase 6), Vulnerability Management (Phase 7).
Risikomanagement, Lieferkettensicherheit, Audit-Trails, Meldepflichten 24 / 72 h. Im SSDLC: RBAC und Audit-Logs in der Pipeline, signierte Builds, automatisiertes Incident-Routing.
ICT-Risikomanagement, Resilienz-Tests, Drittparteienkontrolle (Finanzsektor). Im SSDLC: Chaos Engineering und Recovery-Drills im Run, Provenance über die Build-Chain, Vendor-Scanning auf jeder Abhängigkeit.
Bei High-Risk-AI: Lifecycle-Doku, Datenqualität, menschliche Aufsicht. Im SSDLC: MAESTRO-Threat-Modeling für KI-Komponenten, AISVS-Tests, Model-Cards als Artefakt in jeder Pipeline.
Tiefe statt Vielzahl. Praxis statt Theorie.
Wir sind keine Generalisten, die alles ein bisschen können. Application Security und SSDLC ist unser Kerngeschäft seit über zwei Jahrzehnten.
Drei Schritte. Messbarer Fortschritt.
Wir starten nicht mit einem 200-Seiten-Konzept, sondern mit einer ehrlichen Standortbestimmung. Danach planen wir gemeinsam — schrittweise, mit konkreten Artefakten am Ende jeder Phase.
Diagnose
Wo stehen Sie heute? Wir kartieren Ihre aktuelle Application-Security-Reife entlang OWASP SAMM und finden die drei Hebel mit dem höchsten ROI.
- SAMM-Assessment
- Threat-Model-Review bestehender Systeme
- Compliance-Gap-Analyse
- Quick-Win-Roadmap (30 Tage)
Härtung
Wir verankern die Security-Aktivitäten dort, wo sie hingehören — in den Phasen, in den Tools, in den Teams. Mit klaren Verantwortlichkeiten und automatisierten Gates.
- Threat Modeling in Architektur-Workflow
- SAST/SCA-Gates in Pipelines
- SBOM- und Provenance-Generation
- Secure-Coding-Guides & Dev-Training
Skalierung
Aus einer Pilot-Anwendung wird das Standardvorgehen für das gesamte Portfolio. KPIs werden sichtbar, Audits werden vorhersehbar, Releases werden ruhiger.
- Self-Service-Templates für Dev-Teams
- Executive Security Dashboards
- SLSA-L3-Härtung produktionsweit
- Audit-Ready für CRA, NIS2, DORA
Bevor du losläufst.
Was Teams am häufigsten zum SSDLC fragen — kompakt beantwortet.
Nein. Ein SSDLC sitzt oberhalb Ihres bestehenden Stacks. Wir nutzen Ihre vorhandenen SAST/SCA-Tools, Repos und Pipelines weiter — wir verbinden sie zu einem konsistenten Prozess mit klaren Gates und Artefakten.
Beide. Security definiert die Standards und Gates, Dev verankert die Aktivitäten in der täglichen Arbeit. AppSec ist der Brückenkopf. Wir helfen, die Verantwortlichkeiten klar zu definieren und automatisierte Gates zu etablieren — damit Security nicht zum Bottleneck wird.
Erste Quick Wins in 30 Tagen (SAMM-Assessment, Top-3-Hebel, automatisierte Pipeline-Gates). Spürbare Reduktion von Hotfixes und Release-Verzögerungen in 3–6 Monaten. Audit-Reife für CRA/NIS2/DORA in 6–12 Monaten je nach Ausgangslage.
Ein gut aufgesetzter SSDLC erfüllt alle vier Regularien gleichzeitig — siehe unsere Compliance-Mapping-Sektion. CRA fordert Security-by-Design, SBOM und Updates; NIS2 fordert Risikomanagement und Lieferkettensicherheit; DORA fordert ICT-Resilienz; AI Act fordert Lifecycle-Doku für High-Risk-Systeme. Alle vier werden im SSDLC durch Threat Modeling, SAST/SCA, SBOM-Signing und Runtime-Monitoring abgedeckt.
Realistisch: Wir starten mit dem, was da ist. Erst Inventarisierung und Threat Modeling, dann schrittweise Pipeline-Hardening. Auch ohne moderne CI/CD lassen sich SBOM, Schwachstellen-Management und Audit-Trails einführen — über Wrapper-Skripte und Out-of-Band-Scans.
SLSA L3 ist das Ziel für regulierte Branchen (CRA, DORA). Für die meisten Organisationen ist L2 ein guter erster Meilenstein in 6 Monaten. L3 erfordert isolierte Builds, signierte Provenance und Two-Person-Approval — wir planen den Weg dorthin stufenweise.
Lassen Sie uns über Ihre Application Security sprechen.
30 Minuten Erstgespräch. Wir hören zu, ordnen ein, sagen ehrlich, ob wir helfen können. Und wenn nicht — sagen wir Ihnen, wer es besser kann. Kein Pitch.