Ein Framework zur Integration von Anwendungssicherheit in die Softwareentwicklung (FIASSE) unter Verwendung des Securable Software Engineering Model (SSEM)
# Ein Framework zur Integration von Anwendungssicherheit in die Softwareentwicklung (FIASSE) [](https://creativecommons.org/licenses/by-sa/4.0/) **Hinweis:** Dieses Repository ist eine fortlaufende Arbeit. Beiträge sind willkommen! ## Überblick TL;DR: Bitte lesen Sie die [DOKUMENTATION](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md). Erkunden Sie die [FIASSE-Website](https://fiasse.org). Besuchen Sie die [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions), um beizutragen. Dieses Repository enthält Ressourcen und Materialien für das OWASP Framework zur Integration von Anwendungssicherheit in die Softwareentwicklung (FIASSE). FIASSE (ausgesprochen /feiz/ wie „phase") ist ein herstellerunabhängiges Framework, das einen **entwicklerzentrierten, prinzipienbasierten Ansatz** für die Entwicklung **sicherbarer** Software fördert. Es erkennt an, dass Sicherheit ein dynamischer, fortlaufender Prozess ist – wie die Entwicklung selbst. Es führt das Securable Software Engineering Model (SSEM) als **gemeinsame Designsprache** ein, die etablierte Begriffe der Softwareentwicklung nutzt, um Sicherheit in Softwarearchitektur, Design und Engineering zu integrieren, indem Sicherheit in die Prinzipien eingebettet wird, die den Code selbst formen. Das Framework ermöglicht Entwicklungsteams, widerstandsfähig Rechenwert zu schaffen und dabei die Wahrscheinlichkeit materieller Auswirkungen durch Cyber-Ereignisse über die gesamte Lebensdauer des Codes hinweg zu verringern. FIASSE ist ein kreationales Framework. Es befasst sich damit, wie Sicherheit in Software implementiert wird, und verbindet Engineering-Entscheidungen direkt mit sicherbaren Ergebnissen. Es ist kein Assurance-Framework, kein Reifegradmodell und kein Ersatz für Kontrollkataloge oder Schwachstellenmetriken. Es ergänzt diese Ansätze und verringert den nachgelagerten Druck auf Assurance und Compliance. ## Zweck Praktische Leitlinien bereitzustellen, die **Entwickler befähigen**, sicherbare Software zu erstellen, ohne tiefgehende Sicherheitsexpertise zu benötigen, und Sicherheitsfachleute anzuleiten, ihre Sicherheitserfahrung effektiv in die Softwareentwicklung einzubringen. FIASSE erreicht dies durch eine **Software-Engineering-Perspektive**, wodurch die kognitive Belastung reduziert und die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams gefördert wird. ## Wie unterscheidet es sich? Während assurance-orientierte Projekte wie die OWASP Top 10 hervorheben, was zu vermeiden ist (eine Blockliste), bietet OWASP FIASSE eine Reihe positiver Attribute und Praktiken, denen zu folgen ist (eine Allowlist). Dieser Ansatz nutzt vorhandene Software-Engineering-Fähigkeiten, um sicherbare Software zu entwickeln, anstatt von Entwicklern zu verlangen, Exploit-Techniken zu erlernen oder eine schwächenzentrierte Denkweise anzunehmen. Der Schwerpunkt liegt darauf, praktisches, sicheres Codieren durch vertraute Engineering-Prinzipien zu ermöglichen. Durch die klare Definition der praktischen Rolle von Sicherheit innerhalb des Entwicklungsprozesses stellt dieses Framework sicher, dass Geschäftswert effektiv erfasst wird. Die Festlegung expliziter Sicherheitserwartungen, bevor Code geschrieben wird, verringert die Wahrscheinlichkeit, dass Sicherheitsmängel später entdeckt und behoben werden müssen. Eine effektive Einführung sollte bestehende Assurance-Metriken verbessern, den Wechsel von Befunden reduzieren, dauerhaftere Korrekturen hervorbringen und die Behebungszeit verkürzen. ## Grundwerte FIASSE orientiert sich an vier Grundwerten. Jeder drückt eine relative Präferenz aus: Beide Seiten haben Wert, aber wenn Entscheidungen getroffen werden müssen, bevorzugt FIASSE die linke. - **Sicherbare Attribute vor Sicherheitskontrollen**: Bevorzugen Sie die Engineering-Qualitäten, die es ermöglichen, ein System zu bauen und verteidigungsfähig zu halten, gegenüber Sicherheitskontrollen, die nachträglich eingefügt werden, um Schwächen auszugleichen. - **Beteiligung vor Bewertung**: Bevorzugen Sie strukturierte Zusammenarbeit zwischen Sicherheit und Entwicklung über den gesamten Lebenszyklus hinweg gegenüber einer Bewertung, die nach Abschluss der Arbeit durchgeführt wird. - **Engineering-Grundprinzipien vor Sicherheitsjargon**: Bevorzugen Sie die Verankerung in etablierten Software-Engineering-Grundprinzipien gegenüber sicherheitsspezifischem Jargon oder gegnerischen Heuristiken. - **Geschäftswert vor Sicherheitsaktivität**: Bevorzugen Sie Sicherheit, die die Wertschöpfung der Organisation aufrechterhält, gegenüber Sicherheit, die als Selbstzweck verfolgt wird. ## Schlüsselprinzipien - **Das Paradigma der Absicherbarkeit**: Es gibt keinen statischen Zustand „sicher“. Ein System, das heute als sicher erklärt wird, kann morgen verwundbar sein. FIASSE lenkt das Engineering-Ziel von „Ist es sicher?“ hin zu „Ist es so gebaut, dass Sicherheit aufrechterhalten werden kann?“ – durch adaptive Resilienz, evolutionäre Sicherheit und kontinuierliche Verbesserung. - **Resiliente Bereitstellung von Rechenwert**: Die primäre Direktive der Softwareentwicklung im geschäftlichen Kontext. Software muss funktionale Anforderungen erfüllen und zugleich die absicherbaren Qualitäten aufrechterhalten, die es ihr ermöglichen, der Veränderung, Belastung und den Angriffen standzuhalten, die auf jede Veränderung folgen. - **Sicherheitsmission: Reduzierung materieller Auswirkungen**: Die Mission der Sicherheit ist es, die Wahrscheinlichkeit materieller Auswirkungen eines Cyber-Ereignisses zu reduzieren. Die vollständige Eliminierung von Sicherheitsverletzungen ist kein praktikables Geschäftsziel, daher müssen Sicherheitsstrategien mit Geschäftszielen und Risikobereitschaft übereinstimmen. - **Die Beziehung zwischen Qualität und Sicherheit**: Sicherheit kann die Softwarequalität nicht übersteigen. Die Qualitäten, die Software leicht verständlich, veränderbar, testbar und beobachtbar machen, sind dieselben Qualitäten, die es ermöglichen, sie abzusichern. Investitionen in Engineering-Qualität sind Investitionen in Sicherheit. - **Entwicklerzentrierte Sicherheit**: Softwareentwickler befähigen, absicherbare Systeme mit vertrauten Software-Engineering-Prinzipien zu bauen, anstatt von ihnen zu verlangen, die Denkweise eines Penetrationstesters zu übernehmen. - **SSEM als gemeinsame Designsprache**: Verwendung etablierter Software-Engineering-Begriffe (z. B. Analysierbarkeit, Modifizierbarkeit, Testbarkeit) zur Definition und Diskussion von Sicherheitsattributen. Dies macht Sicherheit für Entwickler zugänglich und gibt Sicherheitsfachleuten eine gemeinsame Grundlage für die Bewertung. - **Ausrichtung der Sicherheit an Entwicklungs- und Geschäftszielen**: Sicherheit und Entwicklung sind komplementär, nicht gegnerisch. AppSec beteiligt sich früh im SDLC, insbesondere während der Anforderungserhebung und Feature-Planung, damit Erwartungen explizit sind, bevor Code geschrieben wird. - **Das Transparenzprinzip**: Systeme werden so gestaltet, dass autorisierte Parteien den internen Zustand und das Verhalten verstehen können. Strukturiertes Logging, Instrumentierung und Audit-Trails sind in den Code integriert und werden nicht allein durch externe Tooling bereitgestellt. - **Das Prinzip der geringsten Überraschung**: Systeme verhalten sich auf eine Weise, die für Benutzer, Entwickler und Administratoren intuitiv und vorhersehbar ist. Vorhersehbarkeit unterstützt die Analyse, reduziert die kognitive Belastung und macht Vertrauensgrenzen klar. - **Anforderungen als erstklassiger Bürger in AppSec**: Sicherheitsfunktionen, Bedrohungsszenarien und Sicherheitsakzeptanzkriterien werden über den Anforderungsprozess geliefert. Schwachstellen lassen sich häufig auf eine Erwartung zurückführen, die nie spezifiziert wurde, daher gehört diese Lücke in den Anforderungsprozess. ## Engineering-Prinzipien Abschnitt 4 des Frameworks gibt Entwicklern Prinzipien, die direkt auf Code-Ebene gelten: - **Das Grenzkontrollprinzip**: Flexibilität im Inneren eines Systems ist ein zu bewahrendes Engineering-Gut. Kontrolle an jeder Vertrauensgrenze ist eine durchzusetzende Sicherheitsanforderung. - **Kanonische Eingabebehandlung**: Eingaben am Eintrittspunkt kanonisieren, validieren und bereinigen. Das **Prinzip des kanonischen Parsens** parst externe Eingaben an der Grenze in einen kanonischen internen Typ und schlägt fehlgeschlossen fehl, wenn das Parsen nicht erfolgreich ist. - **Das Prinzip der isolierten Integrität**: Integritätskritische Werte wie Preise, Rollen und Objektzustand werden aus autoritativen serverseitigen Quellen abgeleitet. Sie werden niemals direkt von einem Client akzeptiert. - **Resilientes Programmieren**: Defensive Programmierpraktiken erzwingen eine vorhersehbare Ausführung. Dazu gehören starke Typisierung, Eingabevalidierung an Vertrauensgrenzen, Ausgabekodierung, umfassende Fehlerbehandlung, sichere Ressourcenverwaltung, ordnungsgemäßes und sicheres Fehlschlagen sowie geringste Privilegien auf Code-Ebene. - **Abhängigkeitsverwaltung**: Wenden Sie SSEM-Attribute bei der Auswahl, Integration, Überwachung und Wartung von Abhängigkeiten für die gesamte Dauer der Beziehung an. ## Das Securable Software Engineering Model (SSEM) SSEM definiert die Attribute, die Software absicherbar machen. Teams legen Ziele für jedes Attribut fest, bewerten Systeme anhand dieser Ziele und verbessern sich schrittweise. Die Attribute sind in drei Kategorien gegliedert: | **Wartbarkeit** | **Vertrauenswürdigkeit** | **Zuverlässigkeit** | |:--------------------|:-------------------:|----------------:| | Analysierbarkeit | Vertraulichkeit | Verfügbarkeit | | Änderbarkeit | Rechenschaftspflicht | Integrität | | Testbarkeit | Authentizität | Resilienz | | Beobachtbarkeit | | | SSEM hat bewusst kein Attribut für Autorisierung. Autorisierung ist eine Sicherheitsfunktion, die als Anforderung erfasst und anhand von Abnahmekriterien umgesetzt wird. Die oben genannten Attribute sind das, was eine solche Funktion absicherbar macht. Anhang A des Frameworks beschreibt Ansätze zur Messung jedes Attributs. ## Repository-Inhalt - [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md): das vollständige FIASSE-Framework und die SSEM-Spezifikation als einzelnes Dokument. - [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework): das Framework aufgeteilt in eine Datei pro Abschnitt. Diese Abschnittsdateien sind die maßgebliche Quelle für das Framework. Der [Code-Index](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) trennt die Abschnitte, die direkt auf Code anwendbar sind, von den Prozess-, Rollen- und Adoptionsabschnitten. [llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt) bietet einen Index für Sprachmodelle. - [skills/](https://github.com/owasp/fiasse/blob/main/skills): FIASSE und SSEM als Skills für KI-Coding-Agenten verpackt (siehe unten). - TODO: Implementierungsleitfäden für die FIASSE-Methodik - Beispiele wurden nach [Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement) verschoben ## Erste Schritte 1. Sehen Sie sich die Dokumentation im Verzeichnis [docs](https://github.com/owasp/fiasse/blob/main/docs) an. Beginnen Sie mit dem [vollständigen Framework](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md) oder verwenden Sie den [Code-Index](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md), um die Abschnitte zu finden, die auf den vorliegenden Code anwendbar sind. 2. Diskutieren Sie die Konzepte und Prinzipien mit Ihren Teams und in den [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) 3. Beginnen Sie, die Prinzipien in Ihren Software-Engineering-Praktiken anzuwenden, etwa bei der Anforderungserhebung, bei Merge-Reviews und beim Prompt Engineering. 4. Befolgen Sie die Adoptionsschritte in Abschnitt 8 des Frameworks: Bewerten Sie aktuelle Praktiken, integrieren Sie die SSEM-Terminologie, identifizieren Sie Schlüsselpersonen, schulen und trainieren Sie Teams, übernehmen Sie agentische AppSec-Tooling als Kapazitätsentlastung, fördern Sie die Zusammenarbeit und überwachen und verbessern Sie kontinuierlich. - Bonus: Installieren Sie das Plugin passend zu Ihrer IDE oder Ihrem KI-gestützten Kommandozeilen-Agenten Ihrer Wahl (z. B. GitHub Copilot, Claude Code, OpenCode usw.) und verwenden Sie die bereitgestellten Prompts, um absicherbaren Code zu generieren. Suchen Sie in der Prompt-Bibliothek nach „Securability Engineering" oder „FIASSE". - FIASSE ist außerdem Teil des [OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook). ## Skills für KI-Coding-Agenten Das Verzeichnis [`skills/`](https://github.com/owasp/fiasse/blob/main/skills) verpackt FIASSE/SSEM als gebrauchsfertige Skills für KI-Coding-Agenten, die das Format [Agent Skills](https://code.claude.com/docs/en/skills) unterstützen (z. B. Claude Code). Kopieren Sie das benötigte Skill-Verzeichnis in den Skills-Pfad Ihres Agenten. - **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)**: Eine kompakte, vollständig eigenständige Referenz, die alle zehn SSEM-Attribute und die Kernprinzipien abdeckt (No Static State of Secure, Isolated Integrity, Canonical Input Handling, Boundary Control, Least Astonishment). Gedacht als Standard für die alltägliche Codegenerierung und -prüfung. - **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)**: Ein Deep-Dive-Skill für kontextintensive, architektonisch komplexe Arbeiten wie die Gestaltung von Vertrauensgrenzen, Authentifizierungssysteme, dienstübergreifende Datenflüsse oder Abhängigkeitsarchitekturen. Er verweist auf den spezifischen mitgelieferten Framework-Abschnitt (in `skills/securable-code/framework/`), der für den vorliegenden Code relevant ist, und tauscht zusätzlichen Kontext gegen die vollständige Argumentation des Quell-Frameworks ein. Verwende standardmäßig `securability`; greife auf `securable-code` zurück, wenn die Designentscheidungen so wenig offensichtlich sind, dass es gerechtfertigt ist, das Framework selbst zu lesen. ## Zusammenfassung Dieses Repository definiert securable Software als Software, die so gebaut ist, dass sie verteidigungsfähig bleibt: so strukturiert, dass sie verstanden, geändert, getestet und gehärtet werden kann, während sich die Welt um sie herum verändert. Es betont, dass Sicherheit ein fortlaufender Prozess ist und keine statische Errungenschaft. Es führt das Securable Software Engineering Model (SSEM) ein, das Sicherheit als eine inhärente Reihe von Qualitäten gut entwickelter Software begreift. Dazu präsentiert es die Attributkategorien Wartbarkeit, Vertrauenswürdigkeit und Zuverlässigkeit (einschließlich Resilienz). FIASSE plädiert dafür, Sicherheitspraktiken dort in den Entwicklungsworkflow zu integrieren, wo sie die größte Wirkung entfalten. Dies bewegt sich von einem Ansatz „Sicherheit als Nachgedanke“ oder „Shift Left“ hin zu einem proaktiven, kollaborativen Modell. Product Owner, Entwickler und Sicherheitsfachleute arbeiten von den frühesten Designphasen an zusammen, insbesondere durch die Definition von Sicherheitsanforderungen, kollaborative Threat Modeling und Sicherheits-Akzeptanzkriterien. Dies schafft klare Erwartungen für Code-Aktivitäten und Tests. Merge-Reviews fungieren als Leitplanken, nicht als Tore. Jeder Merge erzeugt einen beratenden Securability Report, und das Gating ist eine Richtlinienentscheidung mit einem Override-Pfad. Erkenntnisse aus Validierung und Produktion werden als empirische Intelligenz behandelt, die auf die vorgelagerte Phase verweist, die sie hätte verhindern können. Softwareentwickler erhalten Anleitung zum Ausbalancieren von Flexibilität und Kontrolle. Sie erhalten außerdem ein definitives Modell für Sicherheitsentscheidungen. Letztlich befähigt dies alle Stakeholder, zum Aufbau robusterer, zuverlässigerer und inhärent securable Systeme beizutragen. FIASSE unterscheidet sich von bestehenden Ansätzen dadurch, dass Entwickler weder zu Sicherheitsexperten werden noch eine adversariale Denkweise annehmen müssen. Es benennt gängige AppSec-Anti-Patterns wie das „Shoveling Left“ roher Tool-Ausgaben auf Entwickler und exploit-first-Schulungen und ersetzt sie durch das Actionable Security Intelligence Principle. Dieser Ansatz zielt darauf ab, die kognitive Belastung der Entwickler zu reduzieren und gleichzeitig sicherzustellen, dass Sicherheitspraktiker darauf vertrauen können, dass ihre Anliegen durch spezifische Attribute von Code und Software-Engineering-Prozessen adressiert werden. FIASSE möchte offen, zugänglich und kollaborativ sein. ## Roadmap Erste Meilensteine für das FIASSE-Projekt: - **Projektgrundlage** - Etablierung von Projekt-Governance, Beitragsrichtlinien und Kommunikationskanälen. - **Kernspezifikationen** - Formale Veröffentlichung des FIASSE-Frameworks und der SSEM-Spezifikation mit detaillierten Kernattributen und Integrationsstrategien. - **Adoption und Bildungsressourcen** - Ein SSEM-Primer zur Einführung in das Modell und seine Anwendung. - Eine Sammlung erster Anwendungsfälle und Adoptionsmuster zur Veranschaulichung des praktischen Nutzens. - Laufende Entwicklung von Implementierungsleitfäden, Beispielen und weiteren Bildungsmaterialien. Weitere Meilensteine werden mit dem Projektteam entwickelt. Community-Beiträge sind über [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) willkommen. ## Ergänzende Ressourcen Dieses Repository ergänzt die [FIASSE-Website](https://fiasse.org). Das Projekt [OWASP FIASSE](https://owasp.org/www-project-fiasse/) ist Teil der [OWASP Foundation](https://owasp.org/), einer gemeinnützigen Organisation mit der Mission, unsichere Software zu beseitigen. Die OWASP Foundation bietet eine Fülle von Ressourcen und Frameworks, die mit den Prinzipien von FIASSE übereinstimmen. Dieses Framework konzentriert sich auf Securable Software Engineering und wird durch andere OWASP-Projekte ergänzt: - Überprüfung von Sicherheitsfunktionen und eine fertige Bibliothek mit Sicherheitsanforderungen: [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) - Assurance-Reifegrad: [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/) - Produktsicherheits-Compliance: [OWASP Product Security Capability Framework (PSCF)](https://owasp.org/www-project-product-security-capability-framework/) OWASP hostet außerdem zahlreiche Projekte, die Sicherheitsanforderungen und -funktionen dokumentieren, wie etwa [OWASP Mobile Application Security](https://mas.owasp.org/). Der [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/) ist eine umfassende Ressource für verschiedene weitere OWASP-Ressourcen. Eine weitere großartige Ressource für Referenzanforderungen und Assurance-Praktiken ist [OpenCRE](https://opencre.org/), das verschiedene Sicherheitsframeworks zusammenführt und abbildet. Kontrollkataloge wie NIST SP 800-53, ISO/IEC 27001 Anhang A und PCI DSS unterstützen Risikomanagement, Assurance und externe Bewertung. FIASSE ersetzt sie nicht. Es behandelt sie als Eingabe für die Anforderungserhebung, wobei eine Katalogkontrolle in eine Sicherheitsanforderung mit Akzeptanzkriterien übersetzt wird, bevor die Entwicklung sie umsetzt. Das NIST [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final) definiert einen Kernbestand sicherer Softwareentwicklungspraktiken, die in vier Gruppen gegliedert sind. FIASSE definiert keinen solchen Praktikensatz. Es orientiert sich am SSDF, indem es die Integration von Sicherheit in den Softwareentwicklungslebenszyklus betont. Der [Software Security Code of Practice](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance) des NCSC definiert gewünschte Ergebnisse und einige Schlüsselstrategien. FIASSE konzentriert sich auf Prinzipien und Strategien der ersten Ebene als Folgemaßnahmen zur Erreichung absicherbarer Ergebnisse und richtet sich an Entwicklungs- und Assurance-Teams, damit diese sich mit Geschäftsstrategien abstimmen. SSEM spezifiziert die Attribute, die zur Erzeugung der gewünschten Ergebnisse verwendet werden, und die FIASSE-Methodik bietet praktische Anleitung zur Umsetzung dieser Attribute in der Software-Engineering-Praxis. Die Secure Coding Standards des [CERT](https://www.cert.org/) der Carnegie Mellon University sind eine Reihe von Regeln auf Sprachebene, die sowohl Beispiele für „was man nicht tun sollte“ mit Mustern für verwundbaren Code als auch Beispiele für „was man tun sollte“ bereitstellen. FIASSE ergänzt diese Regeln durch einen prinzipienbasierten Ansatz, der Programmierern hilft, das „Warum?“ hinter absicherbarem Code zu verstehen. Das Software Factory Security Framework ([SF2](https://sf2framework.com/)) „bietet Sicherheitsverantwortlichen einen strategischen Ansatz zur Skalierung von Sicherheitsfähigkeiten bei gleichzeitiger Verbesserung der Geschäftsergebnisse.“ Es ist ein Framework auf Organisationsebene, das den Fokus von FIASSE auf Software-Engineering-Praktiken ergänzt. ## Mitwirken Beiträge zur Verbesserung der Dokumentation und der Beispiele sind willkommen. Weitere Details finden Sie in unseren [Beitragsrichtlinien](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md). ## Lizenz Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) – Details finden Sie in der Datei [LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt). ## Danksagungen Dieses Projekt ist eine gemeinschaftliche Anstrengung der OWASP-Community. Wir danken allen Mitwirkenden für ihren wertvollen Beitrag und ihr Engagement für die Verbesserung der Software-Sicherheit. Es gibt eine [Liste der Mitwirkenden](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md), die an diesem Projekt teilgenommen haben. Einige frühe Mitwirkende haben dazu beigetragen, die ersten Konzepte zu formen und die Ideen einem Red-Teaming zu unterziehen.
