Begrenzen Sie Bypass policies in Azure DevOps richtig, indem Sie die Rechte „Bypass policies when completing pull requests“ und „Bypass policies when pushing“ nur einem kleinen, benannten Administrationskreis geben. Halten Sie normale Maintainer, Build-Identitäten und Servicekonten daraus heraus, solange es keinen klar geregelten Ausnahmefall gibt. So bleiben Branch Policies der Standard und Bypass die seltene Ausnahme.
Das ist die saubere Grundeinstellung für geschützte Branches. Branch Policies sind die Regeln, die vor einem Merge oder Push erfüllt sein müssen.
Microsoft empfiehlt in seiner Sicherheits-Baseline für Hauptbranches, beide Bypass-Berechtigungen auf eine kleine Admin-Gruppe zu beschränken. Zusätzlich nennt Microsoft unter anderem mindestens zwei Reviewer, verknüpfte Work Items, Build Validation und Kommentarauflösung als sinnvolle Standards (Microsoft Learn, „Securely use Git repos and pull requests in Azure Repos“, gelesen am 01.11.2026).
Praktisch heißt das:
- Bypass nicht als bequemeren Regelweg behandeln
- Ausnahmen vorher festlegen und verantwortlich zuordnen
- Hochprivilegierte Rechte regelmäßig prüfen
Wenn Bypass breit vergeben ist, verlieren Ihre Branch Policies an Wirkung schon auf Berechtigungsebene.
Die zwei Bypass-Berechtigungen
Diese beiden Rechte sollten Sie getrennt betrachten. „Bypass policies when completing pull requests“ erlaubt, einen Pull Request abzuschließen, obwohl vorgeschriebene Richtlinien noch nicht erfüllt sind. „Bypass policies when pushing“ erlaubt dagegen den direkten Push auf einen Branch trotz der dort geltenden Richtlinien. Dieser Unterschied ist operativ wichtig, weil Pull-Request-Abschluss und Direkt-Push zwei verschiedene Kontrollpfade sind.
Was dabei überhaupt umgangen werden kann, ist breiter, als es im Alltag oft wirkt. Zu den Branch Policies in Azure Repos gehören unter anderem:
- eine Mindestzahl an Reviewern
- verknüpfte Work Items
- Kommentarauflösung
- erlaubte Merge-Typen
- Build Validation
- Status Checks
- automatisch eingeschlossene Reviewer
Alle diese Richtlinien sind standardmäßig ausgeschaltet (Microsoft Learn, „Branch policies and settings“ sowie „Branch policies overview“, gelesen am 01.11.2026).
Bypass ist deshalb keine kleine Abkürzung, sondern eine Umgehung des vorgesehenen Schutzmodells. Wer diese Rechte besitzt, kann Kontrollen außer Kraft setzen, die sonst für alle Änderungen gelten sollen.
Ein häufiger Fehlgriff in Organisationen: Es werden saubere, strenge Policies definiert, aber parallel erhalten Projektadministratoren, Release-Identitäten oder erfahrene Entwickler weitreichende Bypass-Rechte. Dann verlagert sich Sicherheit von überprüfbaren Regeln zurück auf Einzelfallentscheidungen.
Wenn Sie die einzelnen Richtlinien kurz auffrischen möchten, finden Sie eine kompakte Einordnung in unserem Beitrag zu Branch Policies in Azure DevOps.
Wer diese Rechte haben sollte – und wer besser nicht
Für die Praxis gilt: Halten Sie den Kreis so klein wie möglich. Gemeint sind namentlich bekannte Personen aus Plattform-, DevOps- oder Repository-Administration, die ausdrücklich für Ausnahmen zuständig sind. Maßstab ist nicht die Größe des Teams, sondern die Zahl der Personen, die solche Ausnahmen tatsächlich entscheiden und verantworten müssen.
Normale Maintainer brauchen diese Rechte in der Regel nicht. Für den üblichen Änderungsweg reichen Pull Requests mit den bestehenden Policies. Wenn ein Team regelmäßig Bypass benötigt, spricht das meist eher für ein Prozess- oder Richtlinienproblem als für ein Berechtigungsproblem.
Bei Build- und Automatisierungsidentitäten lohnt eine besonders strenge Prüfung. Servicekonten sollten diese Rechte nur erhalten, wenn ein konkreter, dokumentierter Ausnahmefall technisch nicht anders lösbar ist. Andernfalls werden aus selten gedachten Notfallrechten unauffällige Dauerprivilegien.
Wichtig ist auch: Vergeben Sie die beiden Bypass-Rechte nicht automatisch gemeinsam. Wer in Ausnahmen einen Pull Request abschließen darf, muss nicht zwangsläufig direkt auf den geschützten Branch pushen dürfen. Der Direkt-Push ist in vielen Umgebungen das schärfere Recht, weil er den Pull-Request-Pfad ganz verlässt.
Als Gegengewicht sollten Ihre normalen Branch Policies bewusst stark bleiben. Microsoft empfiehlt für main unter anderem mindestens zwei Reviewer, automatisch eingeschlossene Reviewer für sensible Pfade, verknüpfte Work Items, Build Validation und Kommentarauflösung; Bypass ist dabei gerade nicht als Normalweg um diese Kontrollen herum gedacht (Microsoft Learn, „Securely use Git repos and pull requests in Azure Repos“, gelesen am 01.11.2026). Wenn Sie Rollen und Rechte rund um Push, Merge und Regelumgehung systematisch ordnen wollen, finden Sie dazu eine passende Einordnung in unserem Beitrag zu Rollen und Rechten in Azure Repos.
Noch ein technisches Detail zur Einordnung: „Limit merge types“ steuert die Historie, ist aber keine direkte Sicherheitskontrolle. Squash erzeugt eine kompaktere Zielhistorie, fasst aber die Quell-Commits zusammen. Wenn Ihr Audit-Modell von der genauen Commit-Reihenfolge abhängt, nennt Microsoft Merge-Commit-Strategien als passender (Microsoft Learn, „Securely use Git repos and pull requests in Azure Repos“, gelesen am 01.11.2026).
Notfalländerungen ohne bleibenden Schaden
Behandeln Sie den Ausnahmefall als Verfahren, nicht als spontane Einzelaktion. Legen Sie vorher fest, wer entscheidet, in welchen Lagen ein Bypass zulässig ist, wie der Grund dokumentiert wird und wer die Nachprüfung übernimmt. Unter Druck hilft ein klarer Ablauf mehr als ein weit gefasstes Sonderrecht.
Für eilige Änderungen ist ein bypasster Pull Request meist besser nachvollziehbar als ein Direkt-Push. Diskussion, Diffs und Status laufen dann an einem Ort zusammen. Das ist keine Besonderheit von Azure DevOps, sondern allgemeine Git- und Review-Praxis.
Wichtig ist auch die Rückkehr in den Normalzustand. Nach einer Ausnahme sollten Sie
- die eigentliche Ursache beheben,
- temporär vergebene Rechte wieder entziehen,
- ausgelassene Prüfungen nachholen,
- und den Vorfall als Lerneingang für Policies oder Betriebsabläufe auswerten.
Wie belastbar Ihr Standardprozess unter Zeitdruck ist, hängt auch von den Reviewer-Einstellungen ab. In der Reviewer-Policy gibt es unter anderem Optionen für die Selbstfreigabe des Requestors, das Verbot der Freigabe durch den zuletzt Pushenden, den Abschluss trotz „wait“ oder „reject“ sowie das Zurücksetzen von Stimmen bei neuen Pushes. Diese Schalter verändern, wie leicht sich ein Verfahren in einer Stresslage aufweicht oder stabil bleibt (Microsoft Learn, „Branch policies and settings for Git repositories in Azure Repos“, gelesen am 01.11.2026).
Für den Betrieb nützlich: Policies lassen sich auch über „az repos policy“-Befehle oder die REST API setzen. Das erleichtert eine standardisierte Wiederherstellung und konsistente Projekteinstellungen, wenn Sie Ausnahmen sauber zurückbauen wollen (Microsoft Learn, „Branch policies and settings for Git repositories in Azure Repos“, gelesen am 01.11.2026).
Wenn Sie Ausnahmen lieber über zusätzliche maschinenlesbare Signale statt über breitere Rechte absichern wollen, ist das oft der passendere nächste Schritt.
Bypass sauber prüfen und nachhalten
Prüfen Sie Bypass nicht nur als Berechtigung, sondern auch als Ausnahmeereignis. Entscheidend ist, ob sich ein Fall später aus Repository, Pull Request und Berechtigungsstand sauber rekonstruieren lässt. Das hilft intern bei Nachfragen und hält Ausnahmen von verdeckten Normalwegen fern.
Sinnvoll ist ein fester Prüfblick auf zwei Ebenen:
- Vergabe: Wer hat „Bypass policies when completing pull requests“ und wer „Bypass policies when pushing“?
- Nutzung: In welchen konkreten Fällen wurde der Standardpfad verlassen?
- Begründung: Ist der Anlass im Vorgang selbst verständlich festgehalten?
- Folgearbeit: Wurden ausgelassene Kontrollen nachgezogen oder das Grundproblem behoben?
Gerade bei geschützten Branches ist die zweite Frage oft aufschlussreicher als die erste. Eine kleine Admin-Gruppe kann trotzdem zu breit handeln, wenn Ausnahmen nicht sichtbar begründet werden.
Hilfreich ist außerdem die Trennung von Policy-Arten. „Limit merge types“ steuert vor allem die Commit-Historie und ist keine direkte Sicherheitskontrolle; Microsoft ordnet diese Einstellung entsprechend ein (Microsoft Learn, „Securely use Git repos and pull requests in Azure Repos“, gelesen am 01.11.2026). Für die Nachhaltung heißt das: Merge-Typen erklären nicht, warum Reviewer-, Build- oder Statusvorgaben umgangen wurden.
Wenn Sie auf sensiblen Pfaden den Normalweg enger fassen wollen, sind automatisch eingebundene Reviewer oft der passendere Hebel als zusätzliche Sonderrechte.
Bei KI-gestützten Reviews sollten Sie die Prüfspur ebenfalls nüchtern bewerten. Laut Microsoft Learn, „Review pull requests“ und „Use Copilot code reviews in Azure Repos“, gelesen am 01.11.2026, hinterlässt die Funktion nur ein Comment Review. Sie erfüllt damit keine Pflicht-Reviewer-Richtlinie und blockiert keinen Merge. Für Datenschutz, DORA, NIS2 und Mitbestimmung geht es um die konkrete Verarbeitung und den Einsatzkontext; prüfen Sie das mit Rechtsberatung oder Datenschutzbeauftragten.
Häufige Fragen aus dem Betrieb
Wie prüfen Sie, ob ein Bypass wirklich die Ausnahme bleibt?
Nicht nur die Berechtigung zählt, sondern das Muster. Wenn dieselben Teams, Repositories oder Uhrzeiten immer wieder auftauchen, ist das oft kein Einzelfall mehr, sondern ein Betriebsproblem. Schauen Sie deshalb regelmäßig auf drei Punkte:
- wer das Recht hat,
- wer es tatsächlich nutzt,
- und ob der Grund im Vorgang erkennbar festgehalten ist.
Für spätere Rückfragen ist wichtig, dass Entscheidung, Anlass und betroffener Branch zusammen nachvollziehbar bleiben.
Was ist bei Vorschau- und KI-Funktionen für die Bewertung wichtig?
Trennen Sie Funktionsnutzen, Prüfspur und Datenverarbeitung. Microsoft ordnet Vorschaufunktionen als veränderlich ein; sie haben keine SLA und können sich ändern (Microsoft Learn, „Use Copilot code reviews in Azure Repos“, gelesen am 01.11.2026). Ob ein Kommentar entsteht, ein Merge blockiert wird oder Daten außerhalb der Datenresidenz Ihrer Azure-DevOps-Organisation verarbeitet werden, sind verschiedene Fragen. Den aktuellen Stand zu Sicherheits- und Datenpunkten sollten Sie auf der Sicherheits- und Datenseite prüfen.
Worauf sollten Sie bei internen Vorgaben zusätzlich achten?
Bei Datenschutz, DORA, NIS2 und Mitbestimmung geht es nicht nur um das Repository, sondern auch um Rollen, Auswertung und Verhaltensbezug. Klären Sie solche Fragen mit Rechtsberatung oder Datenschutzbeauftragten, nicht aus einer Tool-Einstellung heraus. Produktstände ändern sich; dafür ist ein öffentlicher Änderungsverlauf hilfreicher als Annahmen.
Gibt es dafür schon belastbare Produktwerte oder eine Anmeldung?
Zu Polier von ballmüller solutions gilt am 01.11.2026: in Entwicklung, nicht verfügbar, nur gegen Test-Doubles getestet, kein Real-Run gegen eine Azure-DevOps-Organisation, kein Kunde, keine Zertifizierung, kein Penetrationstest. Spätere Messergebnisse würden auf der Proof-Seite stehen; der vorgesehene Anmeldeweg steht bei Anmeldung und Paketen.
Nächster Schritt
Gehen Sie in einer kurzen, festen Reihenfolge vor:
- beide Bypass-Rechte vollständig inventarisieren,
- den berechtigten Personenkreis auf wenige, benannte Zuständige verkleinern,
- den Notfallprozess schriftlich festhalten,
- die tatsächliche Nutzung regelmäßig prüfen.
Danach gleichen Sie Ihre Hauptbranches bewusst mit Microsofts Baseline ab: mindestens zwei Reviewer, automatisch eingeschlossene Reviewer für sensible Pfade, verknüpfte Work Items, Build Validation, Kommentarauflösung und eng begrenzte Bypass-Rechte (Microsoft Learn, „Securely use Git repos and pull requests in Azure Repos“, gelesen am 01.11.2026).
Wenn Sie dabei auch auf geplante Sicherheits- und Datenaspekte eines Coding-Agenten für Azure DevOps schauen möchten: Polier von ballmüller solutions ist ein Entwurf für einen Coding-Agenten für Azure DevOps Services, befindet sich am 01.11.2026 in Entwicklung und ist noch nicht verfügbar; vorgesehen ist, dass die Branch Policies des Kunden gelten und der Agent selbst nie merged.