# Wechsel des Repository-Besitzers: Zugriff vor der Übergabe prüfen

Ein Wechsel des Repository-Besitzers ist ein Sicherheitsereignis, auch wenn die Übertragung wie gewöhnliche Aufräumarbeit aussieht. Das Repository kann innerhalb eines Nachmittags zu einem neuen Team wechseln. Die damit verbundenen Berechtigungen können aber weiterhin ehemaligen Maintainer, stillgelegten Automatisierungen, alten Cloud-Konten und Zugangsdaten zugeordnet sein, die seit Monaten niemand mehr verwendet hat.

Ich habe erlebt, dass Teams eine Übergabe für abgeschlossen erklärten, nachdem sie den Repository-Besitzer geändert und zwei Personen von der Seite der Mitwirkenden entfernt hatten. Danach veröffentlichte ein vergessenes Deployment weiterhin mit einem persönlichen Token, ein verwaister SSH-Schlüssel konnte immer noch privaten Quellcode lesen oder eine alte Git-Hosting-App durfte Pull Requests ändern. Die Repository-Seite sah sauber aus. Die tatsächliche Kontrollebene war es nicht.

Die praktische Regel ist einfach: Übertrage den Besitz erst, wenn du jede Identität und jeden Dienst benennen kannst, die eine relevante Wirkung auslösen können. «Relevant» bedeutet auch: nicht öffentlichen Code lesen, Commits pushen, Pull Requests öffnen oder genehmigen, Build-Definitionen ändern, auf Geheimnisse zugreifen, Pakete veröffentlichen, Software deployen oder den Zugriff selbst ändern.

## Eine Repository-Übertragung überträgt keine Verantwortung

Ein Repository-Besitzer ist ein administratives Merkmal. Verantwortung bedeutet, dass eine aktuelle Person erklären kann, womit das Repository verbunden ist, warum jede Verbindung existiert, wer sie betreut und wie sie sich im Vorfall widerrufen lässt.

Das sind unterschiedliche Dinge. Git-Hosting-Berechtigungen beschreiben den Zugriff innerhalb eines Dienstes. Moderne Projekte hängen außerdem von CI-Runnern, Paketregistern, Cloud-Rollen, Apps für Code-Scanning, Release-Bots, Dokumentations-Publishern, Chat-Benachrichtigungen, DNS-Anbietern und Artefaktspeichern ab. Jedes System hat eigene Identitäten und ein eigenes Gedächtnis für das Projekt.

Der Unterschied ist besonders wichtig, wenn ein Projekt wegen einer Reorganisation, einer Übernahme, einer internen Plattformmigration oder eines Personalwechsels umzieht. Das neue Team konzentriert sich meist darauf, den Build grün zu halten. Das alte Team will vor allem seine Namen entfernen. Keine dieser Aufgaben beweist, dass die Kontrolle sicher übertragen wurde.

Halte die Verantwortungsgrenze schriftlich fest, bevor jemand Zugriffsrechte ändert. Sie sollte Folgendes benennen:

- den technischen Verantwortlichen im neuen Team, der die operative Verantwortung übernimmt
- den fachlichen Verantwortlichen, der entscheidet, wer auf Code und Releases zugreifen darf
- den Incident-Kontakt, der einen dringenden Widerruf genehmigen kann
- die maßgebliche Quelle für Repository-Mitgliedschaften und Serviceidentitäten
- das Datum, an dem das frühere Team seine Berechtigungen verliert

Verwende kein Gruppenpostfach und keinen vagen Teamnamen als endgültigen Verantwortlichen. Eine Gruppe kann E-Mails empfangen, aber um zwei Uhr morgens keine Entscheidung treffen. Benenne konkrete Personen und prüfe den Eintrag, wenn sich das Team ändert.

Ein weiterer unangenehmer Punkt: Ein Projekt ohne aktuellen Verantwortlichen sollte keinen weitreichenden Produktionszugriff behalten, nur weil es weiterhin Builds erstellt. Wenn niemand die Verantwortung für Deployment-Zugangsdaten sicher übernehmen kann, pausiere Releases oder verringere die Berechtigungen, bis sich jemand darum kümmert. Verfügbarkeit ist kein Grund, unbekannte Berechtigungen zu bewahren.

## Erstelle das Inventar anhand möglicher Wirkungen, nicht anhand der Repository-Seite

Ein brauchbares Zugriffsverzeichnis beginnt mit den möglichen Aktionen und arbeitet sich dann zu den Identitäten zurück, die sie auslösen können. Die Liste der Mitwirkenden ist schneller geprüft, aber sie lässt zu viel aus.

Frage, was mit diesem Projekt geschehen kann, ohne dass ein Entwickler auf der Git-Hosting-Seite sitzt. Ein Commit kann von einem Bot kommen. Ein CI-Workflow kann ein Cloud-Token erhalten. Ein Paket kann veröffentlicht werden, sobald ein Tag erscheint. Ein Webhook-Empfänger kann ein Produktions-Deployment auslösen. Eine App für Code-Reviews kann Kommentare schreiben oder Checks ändern. Jede Wirkung weist auf eine Berechtigung hin, für die es einen Verantwortlichen geben muss.

Verwende eine Arbeitstabelle mit fünf Spalten: Fähigkeit, Identität, Speicherort der Zugangsdaten, aktueller Verantwortlicher und Widerrufsverfahren. Das Widerrufsverfahren verdient eine eigene Spalte, denn «Token löschen» ist oft nicht der tatsächliche Ablauf. Vielleicht musst du eine App deinstallieren, eine Cloud-Vertrauensregel entfernen, einen Deploy-Schlüssel löschen, ein Registry-Token ungültig machen oder ein Webhook-Geheimnis an beiden Enden ändern.

Eine erste Prüfung sollte diese Kategorien abdecken:

- Menschliche Identitäten, darunter direkte Mitwirkende, Organisationsteams, externe Mitwirkende und Organisationsadministratoren.
- Nicht menschliche Identitäten, darunter Maschinenbenutzer, Servicekonten, CI-Runner-Identitäten und App-Installationen.
- Zugangsdaten, darunter SSH-Deploy-Schlüssel, persönliche Zugriffstoken, private App-Schlüssel, Webhook-Geheimnisse, Registry-Token und Cloud-Zugangsdaten.
- Ausführungspfade, darunter Workflow-Dateien, wiederverwendbare Workflow-Referenzen, Runner-Gruppen, Deployment-Umgebungen, Release-Skripte und geplante Jobs.
- Wege, auf denen Daten das System verlassen, darunter Webhooks, Paketveröffentlichungen, Dokumentationsveröffentlichungen, Backups, Spiegel, Issue-Integrationen und Benachrichtigungsdienste.

Das Inventar sollte den Zweck jeder Zugangsdaten in einfacher Sprache beschreiben. «CI-Token» reicht nicht. «Liest Quellcode und veröffentlicht das interne Kommandozeilenpaket, wenn ein signiertes Release-Tag gepusht wird» sagt dem nächsten Maintainer, was getestet werden muss und welches Risiko ein Fehler mit sich bringt.

Du wirst Einträge finden, die niemand erkennt. Lass sie nicht wegen eines plausiblen Namens bestehen. Verlange Belege: Wo ist der Eintrag konfiguriert? Welcher Job hat ihn zuletzt verwendet? Was kann er tun? Wer übernimmt ihn nach der Übertragung? Bleibt die Antwort unklar, plane die Entfernung. Unbekannte Zugangsdaten werden oft erst nach einem Vorfall bekannt.

## Persönliche Zugangsdaten machen eine Übergabe brüchig

Jeder Produktions- oder Release-Pfad, der vom persönlichen Token eines Maintainers abhängt, muss ersetzt werden. Ein Projektwechsel macht diese Schwäche lediglich sichtbar.

Persönliche Zugangsdaten führen zu zwei Problemen. Das erste ist offensichtlich: Der frühere Maintainer kann nach seinem Ausscheiden aus dem Projekt weiterhin Zugriff haben. Das zweite kommt häufiger vor: Sein Konto wird deaktiviert oder sein Token läuft ab, und ein Release-Pfad fällt genau dann aus, wenn das neue Team ihn dringend braucht. Teams bitten den früheren Maintainer dann oft, ein weiteres Token zu erstellen. Das behebt den unmittelbaren Fehler und verfestigt zugleich die Abhängigkeit.

Ersetze persönliche Zugangsdaten nur dann durch eine Serviceidentität, wenn der Dienst tatsächlich eine dauerhafte Identität benötigt. Gib ihr die kleinste Berechtigungsmenge, mit der sie ihre dokumentierte Aufgabe erledigen kann. Ein Publisher für Releases darf vielleicht ein Paket veröffentlichen. Er braucht keinen umfassenden Zugriff auf die Organisation und keinen Zugriff auf jedes Repository.

Verwechsle einen Maschinenbenutzer nicht mit einer gut verwalteten Serviceidentität. Ein Maschinenbenutzer ist lediglich ein Konto, das von einer Automatisierung verwendet wird. Es kann weiterhin ein unbekanntes Passwort, eine persönliche Wiederherstellungsadresse, weitreichende Mitgliedschaften und keinen Verantwortlichen haben. Behandle es wie jede andere Identität mit einem Lebenszyklus: Richte es bewusst ein, dokumentiere seinen Besitzer, prüfe seine Mitgliedschaften und entferne es, wenn seine Aufgabe endet.

Hier scheitert der beliebte Rat, «einfach ein gemeinsames Automatisierungskonto zu verwenden». Er ist beliebt, weil die Automatisierung schnell läuft und niemand jede Integration verstehen muss. Gleichzeitig bündelt er unabhängige Berechtigungen in einer Identität. Wenn ein Projekt das Team wechselt, kann niemand dessen Zugriff widerrufen, ohne alle anderen Projekte zu gefährden, die von demselben Konto abhängen.

Trenne Identitäten nach ihrem betrieblichen Zweck. Ein Build-Leser, ein Release-Publisher und ein Produktions-Deployer brauchen oft unterschiedliche Rechte und unterschiedliche Verantwortliche. Diese Trennung macht Widerrufe weniger riskant und die Untersuchung von Vorfällen eindeutiger.

Prüfe benutzergebundene Token auch außerhalb des Git-Hosts. Ein Deployment-Skript kann ein Token aus einem CI-Geheimnis lesen, aber dieses Token kann zum Cloud-Konto einer ausgeschiedenen Person gehören. Der Speicherort des Geheimnisses sagt nichts über seine Berechtigungen aus. Verfolge es bis zum Aussteller und prüfe dort die Rechte.

## Deploy-Schlüssel und App-Installationen brauchen getrennte Prüfungen

Deploy-Schlüssel, Git-Hosting-Apps und OAuth-Integrationen ermöglichen alle Repository-Zugriff, funktionieren aber auf unterschiedliche Weise. Wenn du sie in einer einzigen Liste behandelst, werden Widerrufe schnell unsauber.

Ein Deploy-Schlüssel ist meist ein öffentlicher SSH-Schlüssel, der an ein Repository gebunden ist. Je nach Konfiguration kann er Lese- oder Schreibzugriff gewähren. Seine Stärke ist die enge Bindung. Seine Schwäche ist die unklare Identität: Der Schlüssel sagt wenig über das System aus, das den privaten Teil besitzt. Wenn ein Kommentar «Build-Server» lautet und dieser Server zweimal den Besitzer gewechselt hat, hilft dir der Repository-Eintrag nicht weiter.

Prüfe für jeden Deploy-Schlüssel vier Fakten: Wo liegt der private Schlüssel? Welcher Prozess verwendet ihn? Benötigt er Schreibrechte? Wer ist für den Host oder den Tresor verantwortlich, in dem der Schlüssel liegt? Entferne Schreibrechte von Schlüsseln, die nur Quellcode abrufen. Entferne jeden Schlüssel, den du keinem aktiven System und keiner benannten verantwortlichen Person zuordnen kannst.

Bei einer App-Installation liegt das Problem meist umgekehrt. Sie hat in der Regel eine bessere Identität, klarere Berechtigungen und eine Ereignishistorie, kann aber über viele Repositories installiert sein. Wenn du sie aus einem Projekt entfernst, wird ein verwandter Dienst an anderer Stelle möglicherweise nicht beendet. Prüfe die angeforderten Berechtigungen der App, den Installationsumfang, den Prozess zur Rotation privater Schlüssel, Callback-Adressen und das Organisationskonto, das die Installation ändern kann.

Die Dokumentation von GitHub trennt Deploy-Schlüssel aus gutem Grund von GitHub Apps. Deploy-Schlüssel werden an Repositories gebunden, während eine App ihre Berechtigungen über eine Installation erhält und eigene Zugangsdaten verwendet. Gehe nicht davon aus, dass das Löschen eines Deploy-Schlüssels den App-Zugriff beeinflusst oder dass die Deinstallation einer App einen SSH-Schlüssel ungültig macht. Es sind voneinander unabhängige Berechtigungspfade.

OAuth-Integrationen verdienen denselben kritischen Blick. Sie handeln möglicherweise im Namen eines Benutzers statt im Namen einer eigenen App-Identität. Kläre bei einer Übertragung, ob die Autorisierung der Integration von einem früheren Maintainer abhängt. Wenn das so ist, übertrage sie auf eine unterstützte Serviceidentität oder entferne sie. Darauf zu warten, dass jemand das Unternehmen verlässt, ist kein Widerrufsplan.

## Workflow-Dateien können mehr Berechtigungen gewähren, als ihr Name vermuten lässt

Ein Workflow, der scheinbar nur Tests ausführt, kann trotzdem Zugangsdaten erhalten, wiederverwendbare Workflows aufrufen, in das Repository schreiben oder Deployment-Systeme anstoßen. Lies die Datei, bevor du ihren Zugriff als harmlos einstufst.

Prüfe die gesamte ausführbare Repository-Konfiguration, nicht nur den Workflow für Releases. Dazu gehören CI-Definitionen, von diesen Definitionen aufgerufene Skripte, Konfigurationen für Abhängigkeitsupdates, Deployment-Manifeste, Infrastrukturcode, Einstellungen für Paketveröffentlichungen und Skripte, die durch Kommentare oder Pull Requests ausgelöst werden.

Achte auf Stellen, an denen ein Job eine Vertrauensgrenze überschreitet. Typische Beispiele sind ein Workflow, der ein Identitätstoken gegen eine Cloud-Rolle eintauscht, ein Job, der Code aus einem Pull Request mit Schreibrechten für das Repository ausführt, oder ein wiederverwendbarer Workflow aus einem anderen Repository. Der Workflow kann «Lint» heißen. Seine Berechtigungen zeigen die Wahrheit.

Die Actions-Dokumentation von GitHub weist darauf hin, dass `pull_request_target` im Kontext des Basis-Repositorys läuft und auf Berechtigungen zugreifen kann, die ein gewöhnlicher Pull-Request-Workflow nicht besitzt. Dieses Ereignis ist nicht automatisch falsch. Falsch wird es, wenn es mit nicht vertrauenswürdigem Pull-Request-Code oder Skripten kombiniert wird, die Außenstehende beeinflussen können. Finde diese Workflows während der Übergabe und lass das neue Team sie ausdrücklich akzeptieren.

Eine einfache Repository-Suche findet viele offensichtliche Verweise. Führe sie lokal aus, nachdem du die benötigte vollständige Repository-Historie abgerufen hast:

```sh
git grep -nE '(AWS_|AZURE_|GCP_|TOKEN|SECRET|DEPLOY|PUBLISH|ssh |curl |webhook)' -- \
  '.github' '.gitlab-ci.yml' 'scripts' 'infra' 'package.json' 2>/dev/null
```

Die Ausgabe kann zum Beispiel so aussehen:

```text
.github/workflows/release.yml:42:  id-token: write
scripts/publish.sh:18: curl -H "Authorization: Bearer $REGISTRY_TOKEN"
infra/deploy.sh:9: ssh -i "$DEPLOY_KEY" "$DEPLOY_HOST"
```

Der Befehl beweist nicht, dass ein Geheimnis existiert oder ein Job gefährlich ist. Er liefert eine Prüfliste. Verfolge jeden Treffer bis zum Aussteller der Zugangsdaten, zum Berechtigungsumfang und zum Fehlerpfad. Suche auch nach Workflow-Referenzen, die außerhalb des Repositorys liegen. Code kann Berechtigungen über einen wiederverwendbaren Workflow erben, den dieses Repository nicht kontrolliert.

Gewähre keine weitreichenden Standardrechte, nur damit ein geerbter Workflow funktioniert. Korrigiere die im Job deklarierten Berechtigungen und teste genau die eine Aktion, die er ausführen muss. Eine Übergabe ist ein guter Zeitpunkt, um Rechte zu entfernen, die nur deshalb überlebt haben, weil niemand eine alte Pipeline stören wollte.

## Widerrufe in einer Reihenfolge, die Beweise erhält und Ausfälle vermeidet

Widerrufe brauchen eine Reihenfolge. Wenn du zuerst alles löschst, gehen möglicherweise die Beweise verloren, die zum Erkennen einer aktiven Abhängigkeit nötig sind. Wenn du auf perfekte Dokumentation wartest, bleibt alter Zugriff womöglich dauerhaft bestehen.

Friere während der Prüfung nicht zwingend erforderliche Änderungen ein. Der neue Verantwortliche sollte erkennen können, ob eine neue App-Installation, ein neuer Deploy-Schlüssel oder ein neuer Organisationsadministrator auftaucht, bevor die Ausgangsbasis vollständig erfasst ist. Das bedeutet nicht, dass die normale Entwicklung stoppen muss. Änderungen müssen aber sichtbar bleiben.

Erstelle einen Export oder einen aufgezeichneten Snapshot von Mitgliedschaften, Listen externer Mitwirkender, Deploy-Schlüsseln, App-Installationen, Webhooks, Metadaten zu CI-Geheimnissen, Cloud-Vertrauensbeziehungen und aktuellen Audit-Ereignissen. Speichere keine Geheimniswerte in diesem Datensatz. Speichere Identifikatoren, Umfänge, Verantwortliche, den Einrichtungskontext, falls verfügbar, und den Zeitpunkt der Prüfung.

Gehe anschließend in dieser Reihenfolge vor:

1. Entferne den direkten Zugriff ehemaliger Maintainer und reduziere frühere Organisationsadministratoren, soweit es die Übertragung erfordert.
2. Deaktiviere oder deinstalliere unbekannte Integrationen und widerrufe Deploy-Schlüssel ohne aktiven Verantwortlichen.
3. Ersetze bekannte persönliche Zugangsdaten durch Serviceidentitäten und teste anschließend genau den betreffenden Build-, Veröffentlichungs- oder Deployment-Pfad.
4. Rotiere gemeinsam genutzte Geheimnisse wie Webhook-Geheimnisse, private App-Schlüssel und Registry-Zugangsdaten, sobald der Ersatz funktioniert.
5. Prüfe Audit-Ereignisse und fehlgeschlagene Jobs über einen Zeitraum, der zum Release-Rhythmus des Projekts passt, und entferne anschließend vorübergehende Ausnahmen.

Diese Reihenfolge trennt unbekannte Berechtigungen von bekannten Abhängigkeiten. Ein unbekannter Deploy-Schlüssel erfüllt keine unterstützte Funktion und kann deshalb früh entfernt werden. Für eine bekannte Release-Zugangsdaten brauchst du dagegen zuerst einen Ersatz, sonst machst du aus einer notwendigen Sicherheitskorrektur einen vermeidbaren Ausfall.

Richte für einen fehlgeschlagenen Ersatz einen bewussten Notfallzugang ein. Er sollte benennen, wer den Dienst wiederherstellen darf, wie lange die Ausnahme gilt und wie das Team sie dokumentiert. Stelle wegen eines verspäteten Releases nicht das weitreichende Token eines ausgeschiedenen Maintainers wieder her. Erstelle stattdessen eine zeitlich begrenzte, eng begrenzte Zugangsdaten unter der Verantwortung des neuen Teams, dokumentiere die Ausnahme und entferne sie nach der Reparatur.

## Der Zugriff von Agents muss derselben Verantwortungsgrenze folgen

Autonome Coding-Agents können Code bearbeiten, APIs aufrufen, SSH verwenden, Artefakte veröffentlichen und über ihre verbundenen Werkzeuge Infrastruktur beeinflussen. Eine Repository-Übertragung, die den Agent-Zugriff ignoriert, lässt eine große Lücke in der Prüfung.

Frage nicht nur, welche Personen einen Agenten starten können. Frage auch, welche Agent-Prozesse für das Repository handeln können, welche Werkzeuge sie aufrufen dürfen, welche Zugangsdaten diese Werkzeuge verwenden und ob ein Prüfer eine bestimmte Aktion später nachvollziehen kann. Ein Agent in der Shell eines Entwicklers, in einem CI-Job oder auf einem entfernten Runner kann unterschiedliche Berechtigungen haben, selbst wenn er dasselbe Modell nutzt.

Bewahre langlebige Zugangsdaten außerhalb des Agent-Prompts und seiner Arbeitsdateien auf. Wenn du ein Geheimnis über Umgebungsvariablen oder eine Tool-Ausgabe weitergibst, kann es in Logs, Unterprozessen, versehentlichen Commits und im Kontext des Agents auftauchen. Dass ein Wert in einer einzelnen Log-Ansicht maskiert wird, macht die Prozessgrenze nicht sicher.

Für Teams, die Sallyport verwenden, kann die Mac-App HTTP- und SSH-Zugangsdaten in ihrem verschlüsselten Tresor aufbewahren, während ein MCP-fähiger Agent über seinen lokalen Shim eine Aktion anfordert, statt die Zugangsdaten selbst zu erhalten. Sitzungs- und Aktivitätsjournale liefern dem neuen Verantwortlichen getrennte Aufzeichnungen über Agent-Läufe und einzelne Aufrufe. Das ist bei einer prüfungsbedürftigen Übergabe nützlicher als ein Transkript.

Widerrufe während des Übergangs Agent-Sitzungen, die an alte Arbeitsplätze oder Prozesse gebunden sind, und lass den neuen Verantwortlichen neue Läufe genehmigen. Prüfe danach die Nutzung jeder Zugangsdaten: Ein schreibgeschützter Abruf von Quellcode sollte nicht dieselben Genehmigungsregeln wie ein Produktions-Deployment haben. Es geht nicht darum, jeden Befehl mühsam zu machen. Mächtige Aufrufe sollen für die Person sichtbar sein, die ihre Folgen verantwortet.

Ein schriftliches Agent-Inventar sollte Repository-Umfang, Ausführungsort, Tool-Kanäle, Verantwortlichen für die Zugangsdaten, Verantwortlichen für die Aktion und den Notfall-Widerruf enthalten. Wenn du diese Felder nicht ausfüllen kannst, hat der Agent Zugriff, den das Projekt nicht verantwortungsvoll übertragen kann.

## Audit-Aufzeichnungen müssen zeigen, wer die Kontrolle geändert hat

Ein Log-Eintrag «Token verwendet» reicht nach einem Besitzerwechsel nicht aus. Du musst feststellen können, wem das Token gehörte, welcher Prozess es verwendet hat, was er getan hat, auf welches Repository er gezielt hat und ob die Aktion unter den neuen Besitzverhältnissen erlaubt war.

Bewahre Repository-Audit-Ereignisse, CI-Ausführungsprotokolle, Cloud-Audit-Aufzeichnungen, Paketregister-Ereignisse und Agent-Aktionsaufzeichnungen gemeinsam in der Übergabedatei oder im Incident-System auf. Sie werden kein einheitliches Format haben, und das ist in Ordnung. Wichtig sind eine gemeinsame Zeitreferenz und genügend Identifikatoren, um ein Ereignis systemübergreifend zu verfolgen.

Teste die Aufzeichnungen, bevor du die Übergabe für abgeschlossen erklärst. Führe über jeden unterstützten Weg eine harmlose Änderung aus: einen normalen Entwickler-Push, ein automatisiertes Pull-Request-Ereignis, einen geplanten Job, falls vorhanden, eine Paketveröffentlichung an ein Nichtproduktionsziel, falls verfügbar, und eine Agent-Aktion, die eine Genehmigung benötigt. Vergewissere dich, dass das neue Team die Nachweise ohne Hilfe der früheren Maintainer findet.

Manipulationsnachweise sind nützlich, ersetzen aber weder Aufbewahrungsfristen noch Zugriffskontrollen. Ein nur erweiterbares Log zeigt, ob jemand einen Datensatz verändert hat. Es hilft dir nicht, wenn die Ereignisquelle den Aufruf nie aufgezeichnet hat, die Aufbewahrungsfrist abgelaufen ist oder während eines Vorfalls niemand im aktuellen Team die Aufzeichnung lesen kann.

Lege nach der Übertragung einen Prüftermin fest. Die erste Prüfung findet Automatisierung, die nur wöchentlich oder monatlich läuft. Die zweite Prüfung findet Personen, die eine Ausnahme beantragen, weil etwas nicht mehr funktioniert. Diese Ausnahmen sind diagnostisch wertvoll. Jede zeigt eine Abhängigkeit, die beim ersten Inventar übersehen wurde.

## Das neue Team sollte jeden Zugriffsweg selbst entfernen können

Eine Übergabe ist abgeschlossen, wenn das neue Team jeden relevanten Zugriffsweg widerrufen kann, ohne das alte Team um die Erklärung eines Geheimnisses, das Auffinden eines Rechners oder die Genehmigung einer Änderung bitten zu müssen. Dieser Maßstab ist strenger als ein Dialog zur Repository-Übertragung. Er verhindert den immer wiederkehrenden Fehler: Der Codebesitz wechselt auf dem Papier, während die Kontrolle an anderer Stelle verstreut bleibt.

Beginne mit dem unspektakulärsten Dokument, dem Zugriffsverzeichnis. Notiere neben jedem verbundenen Dienst einen Verantwortlichen und ein Widerrufsverfahren. Entferne anschließend die Einträge, bei denen beides fehlt. Die Arbeit wirkt mühsam, bis die erste dringende Rotation von Zugangsdaten ansteht. Dann entscheidet das Inventar darüber, ob eine Reparatur begrenzt bleibt oder eine Woche lang geraten werden muss.