Produktmanager planen Compliance von null bis Go-live

Ein Produktteam kann wochenlang über Sicherheitsstandards sprechen und trotzdem keinen Release sicher ausliefern. Für einen Product Manager ist deshalb nicht die längste Kontrollliste der richtige Start, sondern ein nachweisbar geschützter Lieferweg für genau ein Produkt. Ich würde den ersten Sicherheits-Sprint erst dann als abgeschlossen akzeptieren, wenn ein Pull Request geprüft wird, ein Deployment kontrolliert erfolgt und ein Vorfall geübt wurde.

Der erste Sprint braucht eine Liefergrenze statt einer vollständigen Richtlinie

Als Arbeitsbeispiel dient eine Webanwendung mit Node.js, PostgreSQL und einem Repository auf GitHub. Sie verarbeitet Benutzerkonten und Bestellungen und läuft auf AWS. Diese Eingrenzung ist für die Planung entscheidend: Ein Sicherheitskonzept für „die Plattform“ lässt sich kaum abnehmen, während sich für einen konkreten Datenfluss Verantwortliche, Risiken und Tests benennen lassen. Ich lese Sicherheit und Compliance in der Softwareentwicklung als Zielbild, nicht als Sprint-Backlog, weil ein Zielbild noch keine überprüfbare Liefergrenze setzt.

Beginnen Sie mit einem Termin, an dem Entwicklung, Betrieb und die für Datenschutz zuständige Person den Weg einer Bestellung aufzeichnen: Browser, API, Datenbank, Protokolle, Backup und externe Dienste. Für jeden Übergang notiert das Team, welche Daten fließen, wer Zugriff hat und was bei einem Fehler sichtbar wird. Ein einfaches Diagramm und eine Tabelle im Repository reichen zunächst aus, weil sie sich bei einer Änderung am Code gemeinsam aktualisieren lassen. Ob eine Datenschutz-Folgenabschätzung oder weitere Pflichten nötig sind, muss die zuständige Fachperson anhand des tatsächlichen Verfahrens entscheiden; die technische Skizze ersetzt diese Prüfung nicht.

Aus dieser Skizze entstehen wenige überprüfbare Akzeptanzkriterien. Beispielsweise darf eine angemeldete Person keine fremde Bestellung über eine geänderte ID abrufen. Ein fehlgeschlagener Login darf kein Passwort ins Log schreiben. Nur der Deployment-Job darf eine neue Anwendungsversion veröffentlichen. Die Kriterien orientieren sich an OWASP ASVS 4.0.3, werden aber als konkrete Produkttests formuliert, weil eine pauschale Aussage wie „ASVS-konform“ ohne festgelegte Prüftiefe nicht abnehmbar ist.

Für die erste Schätzung setze ich 2 Personentage als anpassbare Planungsannahme für Datenfluss, Zugriffsübersicht und Abnahmekriterien an. Dazu kommt ein eigener Termin für offene Entscheidungen: Wer darf Ausnahmen genehmigen? Wer wird bei einem Alarm erreicht? Wer entscheidet, ob ein Release verschoben wird? Diese Zuständigkeiten gehören in das Arbeitspaket, weil ein Scanner zwar einen Befund erzeugt, aber keine Produktentscheidung trifft. Das Ergebnis des Sprints ist eine priorisierte Liste mit Eigentümer und Prüfmethode, keine unterschriebene Behauptung vollständiger Sicherheit.

Ein Pull-Request-Gate liefert früher Nutzen als eine Sammlung von Dashboards

Der zweite Schritt ist ein reproduzierbarer Build. Für das Beispiel liegen package.json und package-lock.json im Repository; lokal und in GitHub Actions wird mit npm ci installiert. Der Lockfile ist nötig, weil die Prüfung sonst nicht zuverlässig denselben Abhängigkeitsstand betrifft wie der Build. Die folgende Datei unter .github/workflows/dependency-gate.yml läuft bei Pull Requests und lässt den Job bei Sicherheitsmeldungen ab Schweregrad „high“ fehlschlagen:

name: dependency-gate
on: [pull_request]
permissions:
  contents: read
jobs:
  audit:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: npm
      - run: npm ci
      - run: npm audit --audit-level=high

Ubuntu 24.04 und Node.js 22 sind hier festgelegte Versionen des Beispielprojekts, keine allgemeinen Empfehlungen für jedes Team. Die Workflow-Datei muss zur tatsächlich unterstützten Node-Version passen. npm audit prüft bekannte Meldungen zu Abhängigkeiten; es erkennt weder einen Berechtigungsfehler im eigenen Code noch beweist ein grüner Lauf, dass die Anwendung sicher ist. Lassen Sie den ersten Lauf deshalb gegen den vorhandenen Lockfile ausführen, bevor Sie die Regel als verpflichtenden Branch-Check aktivieren. Andernfalls kann Altlasten-Triage ungeplant jeden Pull Request blockieren.

Im selben Arbeitspaket richtet das Team Branch Protection für den Hauptzweig ein: Review und erfolgreicher Workflow werden vor dem Merge verlangt, direkte Pushes untersagt. Danach folgt ein gezielter Test für die fremde Bestell-ID. Semgrep kann ergänzend mit einem kleinen, versionierten Regelsatz nach riskanten Code-Mustern suchen; sein Nutzen hängt von passenden Regeln ab, weshalb ein großer ungeprüfter Regelsatz zum Start eher Triage erzeugt. Dependabot öffnet Updates für Abhängigkeiten, doch jedes Update durchläuft dieselben Tests, weil eine behobene Sicherheitsmeldung auch eine inkompatible Änderung mitbringen kann.

Nicht tun würde ich, am ersten Tag jeden Befund automatisch zum Release-Blocker erklären: Ohne Baseline und zuständige Person kann das Team weder Fehlalarme noch bestehende Risiken geordnet abbauen. Stattdessen bekommt jeder bestätigte Befund einen Eigentümer, eine Entscheidung und ein Fälligkeitsdatum. Für neue Änderungen gilt das Gate sofort; für den bereits vorhandenen Bestand beschließt das Team einen sichtbaren Abbauplan. Eine Ausnahme bleibt befristet und nennt ihren Grund, weil „später beheben“ ohne Termin faktisch eine dauerhafte Freigabe ist.

Ein Deployment ist erst kontrolliert, wenn Zugriff und Rückweg getestet sind

Nach dem Pull-Request-Gate folgt eine Testumgebung, die denselben Deployment-Weg wie Produktion nutzt. Die Anwendung erhält nur die Datenbankrechte, die sie benötigt; Migrationen laufen mit einer getrennten Identität, weil ein Prozess mit dauerhaften Schema-Rechten bei einer Kompromittierung mehr Schaden anrichten kann. Für PostgreSQL werden Verbindungen verschlüsselt und Berechtigungen als Konfiguration überprüft. Terraform kann Infrastrukturänderungen im Review sichtbar machen, ersetzt aber keine Prüfung der tatsächlich vergebenen Rechte. Bei jedem Deployment hält das Team Commit, ausführende Identität und Ergebnis fest.

Für den Zugriff eines GitHub-Actions-Jobs auf AWS gibt es zwei konkrete Optionen. GitHub OIDC mit einer AWS-IAM-Rolle gewinnt bei regelmäßigem Deployment: Der Job erhält zeitlich begrenzte Anmeldedaten, und die Trust Policy lässt sich auf Repository und Branch eingrenzen. Das kostet anfänglich Konfiguration und einen Test der Vertrauensregeln. Ein dauerhaft gespeicherter AWS Access Key ist schneller eingerichtet und kann bei einem vorübergehenden Job ohne OIDC-Unterstützung praktikabel sein; er kostet danach Rotation, Überwachung und zusätzliche Arbeit bei einem möglichen Leak. Für den regulären Release-Weg würde ich OIDC wählen, weil ein gespeicherter Langzeitschlüssel sonst zum dauerhaften Betriebsrisiko wird.

Auch ein erfolgreiches Deployment braucht einen Rückweg. Als justierbares Freigabekriterium soll das Team im Testsystem eine vorherige Anwendungsversion innerhalb von 15 Minuten wieder bereitstellen können. Das ist ein Ziel für dieses Produkt, kein Branchenmesswert. Getestet wird außerdem, ob eine neue Datenbankmigration den Rückweg zulässt; falls nicht, muss der Release-Plan die Änderung in kompatible Schritte teilen. Ein Rollback-Knopf hilft wenig, wenn die alte Anwendung das neue Schema nicht mehr lesen kann.

Backups werden nicht durch ein grünes Job-Symbol abgenommen. Das Team stellt eine PostgreSQL-Sicherung in einer isolierten Umgebung wieder her, meldet sich mit einem Testkonto an und prüft einen vorher festgelegten Datensatz. Als konfigurierbarer Ausgangswert können Backups 30 Tage aufbewahrt werden; die endgültige Dauer richtet sich nach Wiederherstellungsbedarf und Löschpflichten. AWS CloudTrail liefert Ereignisse zu Änderungen an AWS-Ressourcen, während Anwendungslogs eine Bestellung oder einen fehlgeschlagenen Login erklären müssen. Beide Quellen sind nötig, weil keine allein den gesamten Vorfall rekonstruiert.

Compliance wird erst planbar, wenn Nachweise aus dem Betrieb entstehen

Im vierten Schritt wird aus einzelnen Prüfungen eine kleine Nachweiskette. Ein Release verweist auf den genehmigten Pull Request, dessen Testläufe, die verwendete Version und das Deployment-Protokoll. Ein Sicherheitsbefund verweist auf die Entscheidung und gegebenenfalls die Korrektur. Diese Verknüpfung ist aussagekräftiger als ein Ordner voller Screenshots, weil sich damit eine konkrete Änderung vom Vorschlag bis zur Auslieferung verfolgen lässt. Auch Sicherheit und Compliance in der Softwareentwicklung kann diese Zuordnung nicht stellvertretend für ein Produkt herstellen, weil Nachweise aus dessen tatsächlichen Änderungen entstehen müssen.

Ergänzend kann Syft eine Software-Stückliste im Format CycloneDX erzeugen. Die Stückliste hilft bei der Frage, welche Releases eine betroffene Bibliothek enthalten; sie ist kein Beleg dafür, dass diese Releases frei von Schwachstellen sind. Trivy kann Container-Images prüfen, sofern das Team überhaupt Images ausliefert. Product Manager sollten solche Prüfungen an eine konkrete Reaktion koppeln: Wer bewertet einen Fund, welches Release ist betroffen, und wie erreicht die Entscheidung den Verantwortlichen? Ohne diese Antworten wächst die Zahl der Berichte schneller als die Fähigkeit, Risiken zu schließen.

Für den Betrieb genügen anfangs wenige Signale. OpenTelemetry kann Anfragen über Dienste hinweg kennzeichnen; Prometheus und Grafana können Fehlerrate und Antwortzeit sichtbar machen. Sicherheitsrelevant wird die Beobachtung erst mit einem vereinbarten Alarmweg, etwa bei wiederholten fehlgeschlagenen Logins oder unerwarteten Zugriffsverweigerungen. Als zu testender Zielwert bekommt ein Alarm innerhalb von 60 Minuten eine verantwortliche Person zugewiesen. Ob das realistisch ist, zeigt ein Probelauf außerhalb eines sorgfältig vorbereiteten Demo-Termins, nicht die Existenz eines Dashboards.

Planen Sie schließlich eine kurze Übung: Ein Testzugang wird als kompromittiert gemeldet, das Team sperrt ihn, sucht betroffene Ereignisse, entscheidet über weitere Schritte und dokumentiert die Zeitpunkte. Die für Datenschutz zuständige Person bewertet anhand des tatsächlichen Vorfalls, ob Meldepflichten nach DSGVO bestehen; Entwicklung sollte diese Rechtsentscheidung nicht aus einem Log-Eintrag ableiten. Für die laufende Arbeit reserviere ich 1 Personentag pro Sprint als verhandelbaren Kapazitätsansatz für Befund-Triage, Updates und die Pflege der Nachweise. Wird diese Zeit nicht eingeplant, konkurriert Sicherheitsarbeit bei jedem Sprint erneut mit sichtbaren Produktfunktionen.

Der nächste Schritt ist ein prüfbarer Auftrag, keine neue Policy

Beauftragen Sie als Erstes einen gemeinsamen Termin für genau einen produktiven Datenfluss und lassen Sie am Ende drei Dinge festhalten: seinen Eigentümer, den riskantesten Zugriff und einen Test, der diesen Zugriff absichert. Erst danach schätzen Sie Pull-Request-Gate, Deployment und Wiederherstellungsprobe. So kann das Team Aufwand und Abnahme besprechen, bevor aus einem gut gemeinten Sicherheitsziel ein unbegrenztes Projekt wird.