##  Pfadnavigation

1. [ Startseite ](/)
2. [ Software Testing & Qualität - Testautomatisierung, KI & Agilität ](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)
3. IT-Sicherheit als Teamaufgabe: Von abstrakten Zielen zu konkreten Anforderungen

# IT-Sicherheit als Teamaufgabe: Von abstrakten Zielen zu konkreten Anforderungen

            **Podcast:**

   [Software Testing & Qualität - Testautomatisierung, KI & Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

              **Erscheinungsdatum:**

   26. Mai 2026

            **Länge:**

   00:23:39

    [         Link zur Episode (extern)   ](https://www.richard-seidl.com/de/podcast/security-requirements-testbar-machen)

 ![Security-Anforderungen im Team entwickeln - Markus Geiger](https://www.botcaster.de/sites/default/files/styles/podcast_n_episode_metadata_image_1x/public/2026-08/a6cfead9-03a8-48f9-a3a5-b17bfb80e353.jpg.webp?itok=Uv_ng2Jx)

###   Security-Anforderungen im Team entwickeln - Markus Geiger

   26. Mai 2026 · [Software Testing & Qualität - Testautomatisierung, KI & Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

In der Welt der Softwareentwicklung sind nicht-funktionale Anforderungen oft ein wunder Punkt - schwammig, schwer greifbar und noch schwerer zu testen. Nirgendwo wird dies deutlicher als bei der IT-Sicherheit. Die pauschale Forderung Das System muss sicher sein hilft niemandem weiter. Doch wie verwandelt man diese abstrakte Erwartung in konkrete, umsetzbare Maßnahmen, die ein Entwicklungsteam wirklich weiterbringen? In einer neuen Episode des Podcasts *Software Testing & Qualität* spricht Host Richard Seidl mit dem Security-Experten Markus Geiger darüber, wie Teams das Thema Sicherheit proaktiv und pragmatisch gestalten können - ganz ohne spezialisierte Hacker-Kenntnisse.

Diese Episode, aufgezeichnet auf der OOP 2026 in München, liefert einen klaren Fahrplan für Entwickler:innen, Tester:innen und Product Owner. Im Zentrum steht die Frage: Wie können wir Sicherheit von Anfang an als integralen Bestandteil der Qualität betrachten und sie genauso systematisch behandeln wie Performance oder Usability? Markus zeigt, dass der Schlüssel nicht in komplexen Werkzeugen, sondern in einem veränderten Denkansatz und der richtigen Kommunikation im Team liegt.

## Das Wichtigste auf einen Blick

- **Spreche über Schutzziele, nicht über Sicherheit:** Statt pauschal Sicherheit zu fordern, konzentriere dich auf die konkreten Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit (das CIA-Prinzip). Frage gezielt, was der Schaden wäre, wenn Daten öffentlich, verändert oder nicht verfügbar wären.
- **Identifiziere, was wirklich schützenswert ist:** Nicht alle Daten und Funktionen sind gleich kritisch. Der erste Schritt ist immer, die Assets - also die schützenswerten Güter deiner Anwendung - zu identifizieren und ihren jeweiligen Schutzbedarf zu bewerten.
- **Sicherheit ist eine Teamaufgabe:** Du brauchst keine Elite-Hacker im Team. Ein grundlegendes Sicherheitsbewusstsein kann und sollte im gesamten Entwicklungsteam verankert werden. Jeder kann und soll dazu beitragen.
- **Nutze spielerische Methoden für den Einstieg:** Threat-Modeling-Kartenspiele wie Elevation of Privilege sind ein niederschwelliger Weg, um im Team über Bedrohungen zu diskutieren. Sie fördern die Kreativität und machen das oft trockene Thema greifbar und unterhaltsam.
- **Integriere Sicherheit frühzeitig (Shift Left):** Ein Penetrationstest kurz vor dem Release ist nur eine späte und teure Form der Fehlerfindung. Sicherheit muss von Beginn an in der Architektur und im Design berücksichtigt werden, um kostspielige Nachbesserungen zu vermeiden.
- **Der Cyber Resilience Act als praxisnaher Leitfaden:** Auch wenn die Umsetzung in vielen Unternehmen noch zögerlich ist, bieten die technischen Richtlinien zum EU-Gesetz (z. B. vom BSI) einen wertvollen und verständlichen Leitfaden für bewährte Sicherheitspraktiken.

## Vom abstrakten Wunsch zur konkreten Anforderung: Das CIA-Prinzip

Markus Geiger eröffnet das Gespräch mit einer Analogie, die jeder im Software-Testing kennt: Qualitätsanforderungen für Performance. Würde man einen Stakeholder nach der gewünschten Antwortzeit fragen, bekäme man oft eine konkrete, messbare Angabe wie unter einer Sekunde in 99 % der Fälle. Solche Qualitätsszenarien sind testbar und umsetzbar. Bei der Sicherheit hingegen, erklärt Markus, fehlt vielen die Sprache, um ihre Bedürfnisse ebenso präzise auszudrücken.

Hier kommt das CIA-Prinzip ins Spiel, ein Akronym für die drei zentralen Schutzziele:

- **Confidentiality (Vertraulichkeit):** Welche Daten dürfen unter keinen Umständen an die Öffentlichkeit gelangen? Ein Verstoß könnte hier sogar rechtliche Konsequenzen haben.
- **Integrity (Integrität):** Was passiert, wenn Informationen unbemerkt verändert werden? Ist das ein kritisches Problem oder heilt sich das System von selbst?
- **Availability (Verfügbarkeit):** Entsteht ein finanzieller Schaden, wenn das System für eine halbe Stunde ausfällt, oder würde es niemand bemerken?

Indem man diese gezielten Fragen stellt, verschiebt sich die Diskussion von einer vagen Sorge hin zu einer risikobasierten Bewertung. Dieser Ansatz erfordert im ersten Schritt die Identifikation der schützenswerten Güter (Assets). Bei einem LinkedIn-Profil, so Markus, ist Vertraulichkeit kein Ziel, Integrität hingegen schon - niemand möchte, dass Fremde den eigenen Lebenslauf verändern. Erst wenn klar ist, *was* geschützt werden soll und *wovor*, können sinnvolle Maßnahmen abgeleitet werden.

## Kataloge und Threat Modeling: Werkzeuge für die Praxis

Oft greifen Teams zu umfassenden Katalogen wie dem OWASP Application Security Verification Standard (ASVS). Markus betont, dass solche Werkzeuge extrem nützlich sind, aber erst im zweiten Schritt. Sie liefern konkrete Anleitungen und technische Maßnahmen, sind aber nur dann effektiv, wenn man zuvor die eigenen Schutzziele definiert hat. Ohne diese Vorarbeit läuft man Gefahr, Maßnahmen für Probleme umzusetzen, die für das eigene System gar nicht relevant sind. Man würde ja auch nicht das gesamte Kryptografie-Kapitel umsetzen, wenn es gar keine vertraulichen Daten gibt.

Eine entscheidende Ergänzung ist das Threat Modeling. Hier geht es darum zu verstehen, auf welche Weise die definierten Schutzziele gefährdet werden könnten. Diese Analyse der Bedrohungslandschaft hilft dem Team, Risiken zu priorisieren und sich auf die wichtigsten Schutzmaßnahmen zu konzentrieren. Anstatt nur zu wissen, dass etwas schiefgehen kann, versteht das Team, *wie* es schiefgehen könnte und was die wahrscheinlichsten Angriffspfade sind.

## Sicherheit ist Teamsport: Wie jeder im Team beitragen kann

Ein weit verbreiteter Irrglaube ist, dass Sicherheit eine Aufgabe für eine kleine Gruppe von hochspezialisierten Expert:innen ist. Markus plädiert leidenschaftlich dagegen. Ein einzelner Security-Experte, der für Hunderte von Entwickler:innen zuständig ist, kann kaum etwas bewirken. Viel wichtiger sei es, ein Sicherheits-Mindset in jedem Team zu etablieren. Oft gibt es in Teams bereits Personen mit einem latenten Interesse am Thema. Diese Security Champions gilt es zu fördern, damit sie das Thema im Alltag präsent halten, etwa indem sie im Refinement auch mal die Sicherheits-Frage stellen.

Um den Einstieg zu erleichtern, empfiehlt Markus spielerische Methoden (Gamification). Ein herausragendes Beispiel sind Threat-Modeling-Kartenspiele wie Elevation of Privilege, das ursprünglich bei Microsoft entwickelt wurde. In einer Art Stichspiel erhalten die Spieler:innen Punkte, wenn sie erklären können, warum ein auf ihrer Karte beschriebenes Angriffsszenario für das eigene System relevant ist. Nebenbei entsteht so eine Liste potenzieller Bedrohungen. Dieser Ansatz macht nicht nur Spaß, sondern senkt auch die Hemmschwelle, über Schwachstellen zu sprechen, und fördert eine kollaborative und kreative Auseinandersetzung mit dem Thema.

## Ein kontinuierlicher Prozess: Wann und warum Sicherheit immer wieder Thema sein muss

Sicherheit ist kein Projekt, das man einmal abschließt, sondern ein fortlaufender Prozess. Markus nennt mehrere Auslöser, die eine erneute Auseinandersetzung mit Sicherheitsanforderungen erfordern:

- **Neue Features oder Daten:** Sobald neue, potenziell schützenswerte Informationen verarbeitet werden, muss deren Schutzbedarf neu bewertet werden.
- **Größere Refactorings:** Umfangreiche Umbauten am Code können unabsichtlich neue Schwachstellen schaffen, selbst wenn die Funktionalität dieselbe bleibt.
- **Aktuelle Sicherheitsvorfälle:** Wenn in den Nachrichten über einen neuen Angriffstyp berichtet wird, sollte sich das Team die Frage stellen: Wären wir davon auch betroffen gewesen?
- **Neue Technologien und Angriffsmuster:** Der Aufstieg von KI bringt völlig neue Bedrohungen mit sich, wie etwa Prompt Injection. Als Reaktion darauf gibt es mittlerweile auch eine OWASP Top Ten speziell für KI-Systeme.

Diese dynamische Natur unterstreicht, warum das Sicherheitsdenken fest in den agilen Alltag, zum Beispiel in Scrum- oder Kanban-Prozesse, integriert werden muss.

## Die Realität der Bedrohungen und die Rolle der Gesetzgebung

Die Bedrohungslage ist real und permanent. Markus stellt klar, dass es sich bei den ständigen Angriffsversuchen weniger um gezielte Angriffe von Hollywood-Hackern handelt, sondern meist um opportunistische, automatisierte Scans von Firmen, die damit Geld verdienen wollen - sei es durch den Verkauf von Informationen über Sicherheitslücken oder durch Ransomware.

In diesem Kontext gewinnt auch die Gesetzgebung an Bedeutung. Der Cyber Resilience Act (CRA) der EU zielt darauf ab, Hersteller zu mehr Sicherheit zu verpflichten. Markus beobachtet, dass die Umsetzung in der Praxis noch langsam anläuft, lobt aber die technischen Richtlinien, die beispielsweise vom BSI veröffentlicht wurden. Diese seien extrem praxisnah und voller Common Sense. Sie fordern unter anderem proaktive Information über Sicherheitslücken, die Bereitstellung von Patches und automatische Update-Mechanismen - alles Dinge, die aus Verbrauchersicht selbstverständlich sein sollten.

## Praktische Schritte für mehr Sicherheit in Deinem Team

1. **Schutzziele definieren:** Führt im Team eine Diskussion zu Vertraulichkeit, Integrität und Verfügbarkeit. Stellt euch konkret die Frage: Was ist der größte anzunehmende Schaden in jedem dieser Bereiche?
2. **Assets identifizieren und bewerten:** Erstellt eine Liste eurer schützenswerten Güter - seien es Kundendaten, Geschäftsprozesse oder kritische Funktionen. Bewertet gemeinsam, wie hoch der Schutzbedarf für jedes Asset ist.
3. **Threat Modeling spielerisch angehen:** Organisiert einen zweistündigen Workshop und probiert ein Kartenspiel wie Elevation of Privilege oder Cornucopia aus. Das ist der perfekte, niederschwellige Einstieg, um über Bedrohungen zu sprechen.
4. **Sicherheit als festen Bestandteil etablieren:** Macht Sicherheit zu einem regelmäßigen Thema in euren Refinements und Retrospektiven. Stellt bei jeder neuen User Story die Frage: Und was bedeutet das für die Sicherheit?
5. **Wissen aufbauen und wachsam bleiben:** Benennt eine Person im Team als Security Champion, die das Thema vorantreibt. Diskutiert aktuelle Sicherheitsvorfälle aus den Nachrichten und nutzt Ressourcen wie die OWASP Top Ten.
6. **Richtlinien als Leitfaden nutzen:** Werft einen Blick in die technischen Richtlinien zum Cyber Resilience Act. Sie bieten eine Fülle von konkreten und verständlichen Anleitungen, die euch direkt weiterhelfen.

---

 version="1.0" encoding="UTF-8"?
      .st0 {
        fill: #010101;
      }

      .st1 {
        fill: #b0c0b3;
      }

      .st2 {
        fill: #3b3a3b;
      }

      .st3 {
        fill: #3a3a3a;
      }

      .st4 {
        fill: #5e7185;
      }

      .st5 {
        fill: #f9eddd;
      }

      .st6 {
        fill: #000100;
      }

      .st7 {
        fill: #aebeb3;
      }

      .st8 {
        fill: #fefefe;
      }

      .st9 {
        fill: #7f93a8;
      }

      .st10 {
        fill: #f8f0df;
      }

      .st11 {
        fill: #fbf0df;
      }

      .st12 {
        fill: #afbfb2;
      }

      .st13 {
        fill: #f7eedd;
      }

      .st14 {
        fill: #fdfdfd;
      }
                                                                                   Botcaster

  **Zusammengefasst von Anja Schirwinski**

Ich beschäftige mich beruflich wie privat mit Künstlicher Intelligenz - von konkreten Tools im Arbeitsalltag bis zu den größeren Fragen, die dabei aufkommen. Viele der Themen, die in Podcasts besprochen werden, begegnen mir in Projekten immer wieder. Deshalb fasse ich hier die für mich interessantesten Podcastfolgen zusammen und ordne sie aus der Praxis ein.

[Mehr über das Projekt Botcaster](/ueber-uns)

##  Themen

 - [  Softwareentwicklung mit KI  ](/podcasts/themen/softwareentwicklung-mit-ki)
- [  Testen und Qualität  ](/podcasts/themen/testen-qualitaet)

**Hinweis:** *Diese Zusammenfassung wurde mit Hilfe von KI aus dem Transkript der Podcast-Episode generiert.*

Alle Inhalte auf Botcaster beruhen auf öffentlich zugänglichen Podcasts rund um Künstliche Intelligenz. Wir fassen die Episoden nach bestem Wissen zusammen, übernehmen jedoch keine Gewähr für Vollständigkeit, Aktualität oder Richtigkeit der Inhalte. Die Rechte an den Original-Podcasts und -Inhalten liegen ausschließlich bei den jeweiligen Urheber:innen.

         ## Shownotes

   Diesmal spreche ich mit Markus Geiger über ein Problem, das viele Tester kennen: Security Requirements sind oft so abstrakt formuliert, dass man damit beim Testen wenig anfangen kann. Markus zeigt, wie man über konkrete Schutzziele wie Vertraulichkeit, Integrität und Verfügbarkeit spricht – und warum Teams ohne Security-Experten mit einfachen Methoden wie Threat-Modeling-Kartenspielen selbst herausfinden können, wo ihre Schwachstellen liegen.