Vs Burpsuite: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Hydra und Burp Suite werden oft gegeneinander gestellt, obwohl beide Werkzeuge in der Praxis unterschiedliche Rollen einnehmen. Hydra ist in erster Linie ein spezialisiertes Tool für Online-Authentifizierungsangriffe gegen klar definierte Protokolle und Login-Endpunkte. Burp Suite ist dagegen eine umfassende Web-Testing-Plattform, die HTTP- und HTTPS-Verkehr sichtbar macht, manipuliert und reproduzierbar testbar macht. Wer beide Werkzeuge auf dieselbe Stufe stellt, trifft häufig falsche Entscheidungen bei der Angriffsvorbereitung und verliert Zeit in der Fehlersuche.

Hydra ist stark, wenn ein Ziel technisch bereits verstanden wurde: Protokoll, Parameter, Fehlermeldung, Erfolgsindikator, Session-Verhalten und Rate Limits sind bekannt. Dann arbeitet Hydra schnell, skriptbar und effizient. Burp Suite ist stark, wenn genau dieses Verständnis erst noch aufgebaut werden muss. Bei Web-Logins mit CSRF-Token, Redirect-Ketten, JavaScript-generierten Requests, versteckten Parametern, Cookie-Abhängigkeiten oder Anti-Automation-Mechanismen ist Burp Suite meist der erste Schritt und Hydra erst später sinnvoll.

In realen Assessments ist die Frage selten „Hydra oder Burp Suite“, sondern eher „an welcher Stelle im Workflow ist welches Werkzeug das richtige“. Für SSH, FTP, SMB oder RDP ist Hydra oft direkt einsatzbereit. Für komplexe Web-Authentifizierung ist Burp Suite fast immer das Analysewerkzeug, bevor überhaupt an Automatisierung gedacht wird. Genau an dieser Stelle entstehen typische Fehler: Ein Login-Formular wird mit Hydra angegriffen, obwohl die Anwendung pro Request ein neues Token erwartet. Oder Burp Intruder wird für einen simplen Basic-Auth-Test verwendet, obwohl Hydra denselben Test schneller und robuster ausführen könnte.

Ein sauberer Workflow trennt deshalb zwischen Protokollangriff und Web-Workflow-Analyse. Für klassische Netzwerkdienste lohnt sich ein Blick auf Anwendungsfaelle und Pentesting. Für HTTP-Formulare ist entscheidend, zuerst den Request vollständig zu verstehen, bevor Last erzeugt wird. Genau dort zeigt sich die Stärke von Burp Suite: Repeater, Proxy, Comparer und Intruder liefern Sichtbarkeit, während Hydra vor allem dann glänzt, wenn das Zielmodell bereits präzise definiert wurde.

Der wichtigste Unterschied liegt also nicht in der reinen Funktion, sondern in der Tiefe der Protokollkontrolle. Hydra erwartet eine korrekte Beschreibung des Login-Prozesses. Burp Suite hilft dabei, diese Beschreibung überhaupt erst zu gewinnen. Wer das verinnerlicht, reduziert Fehlversuche, vermeidet False Positives und baut deutlich stabilere Testketten.

Hydra ist dann überlegen, wenn der Authentifizierungsmechanismus standardisiert, stabil und ohne komplexe Zustandslogik implementiert ist. Das betrifft vor allem Dienste wie SSH, FTP, Telnet, SMB, RDP oder einfache HTTP-Authentifizierung. In solchen Fällen ist der Overhead von Burp Suite unnötig hoch. Hydra kann direkt mit Benutzerlisten, Passwortlisten, Threading und Timeout-Steuerung arbeiten und liefert reproduzierbare Ergebnisse mit geringem manuellen Aufwand.

Ein typisches Beispiel ist ein SSH-Login gegen ein internes Zielsystem. Burp Suite ist hier praktisch bedeutungslos, weil kein browserbasierter Workflow analysiert werden muss. Hydra kann sofort mit Benutzer- und Passwortlisten arbeiten, Verbindungsfehler sauber ausgeben und über Threads die Geschwindigkeit steuern. Dasselbe gilt für FTP oder Telnet. Selbst bei HTTP Basic Auth oder Digest Auth ist Hydra oft die schnellere Wahl, weil keine Formularlogik, keine Token und keine Browser-Session nachgebildet werden müssen.

Auch in automatisierten Prüfketten hat Hydra klare Vorteile. Das Tool lässt sich leicht in Shell-Skripte, CI-nahe Prüfungen oder interne Red-Team-Workflows integrieren. Ausgabeformate, Exit-Verhalten und Kommandozeilenlogik sind für Automatisierung deutlich besser geeignet als interaktive GUI-Workflows. Wer regelmäßig wiederkehrende Prüfungen gegen bekannte Dienste fährt, profitiert von dieser Vorhersagbarkeit. Für operative Details sind Befehle, Syntax und Optionen relevant.

• Standardisierte Netzwerkprotokolle ohne Browser-Logik sprechen klar für Hydra.
• Hohe Wiederholbarkeit und Skriptbarkeit machen Hydra stark in Routine- und Massenprüfungen.
• Wenn Erfolg und Misserfolg eindeutig an Protokollantworten erkennbar sind, arbeitet Hydra besonders zuverlässig.

Ein weiterer Punkt ist die Performance. Burp Intruder kann zwar ebenfalls große Mengen Requests erzeugen, ist aber im Kern auf Web-Workflows und Request-Manipulation ausgerichtet. Hydra ist für Authentifizierungsversuche gebaut. Das zeigt sich bei Threading, Timeout-Verhalten und der Art, wie Verbindungsfehler behandelt werden. Gerade bei langsamen Diensten oder instabilen Zielen lässt sich Hydra oft präziser abstimmen. Themen wie Threads, Timeout und Performance sind dabei nicht nur Tuning-Fragen, sondern entscheiden direkt über die Qualität der Ergebnisse.

Hydra ist außerdem dann im Vorteil, wenn ein Test nicht explorativ, sondern zielgerichtet ist. Wenn bereits bekannt ist, dass ein bestimmter Dienst erreichbar ist, welche Benutzer in Frage kommen und welche Passwortstrategie geprüft werden soll, liefert Hydra mit minimalem Setup sehr schnell belastbare Resultate. Burp Suite wäre in diesem Szenario eher ein Umweg als ein Gewinn.

Burp Suite ist die bessere Wahl, sobald ein Login nicht nur aus Benutzername und Passwort besteht, sondern aus einem vollständigen Web-Workflow. Moderne Anwendungen arbeiten mit CSRF-Tokens, dynamischen Hidden Fields, JavaScript-generierten Parametern, Single-Sign-On-Weiterleitungen, Session-Rotation, Captcha, Device Fingerprinting oder API-basierten Login-Flows. In solchen Umgebungen scheitert Hydra nicht an fehlender Geschwindigkeit, sondern an unvollständigem Kontext.

Burp Proxy zeigt den echten Request, nicht den vermuteten. Das ist entscheidend. Viele Fehlschläge entstehen, weil ein Formular visuell einfach aussieht, der Browser aber zusätzliche Header, Cookies oder JSON-Felder sendet. Burp Repeater erlaubt, einzelne Requests kontrolliert zu variieren und die Reaktion des Servers exakt zu beobachten. Erst dadurch wird klar, woran Erfolg oder Misserfolg tatsächlich erkennbar sind: Statuscode, Redirect, Set-Cookie, Response-Länge, DOM-Änderung oder eine unscheinbare Textpassage.

Besonders wertvoll ist Burp Suite bei Anwendungen, die auf den ersten Blick trivial wirken, intern aber mehrere Requests auslösen. Ein Login kann etwa zuerst ein CSRF-Token laden, dann einen Preflight-Request senden, anschließend Credentials an eine API schicken und danach ein Session-Cookie setzen. Hydra sieht standardmäßig nur den Endpunkt, den man ihm vorgibt. Burp Suite zeigt die gesamte Kette. Ohne diese Transparenz wird ein Angriff schnell unzuverlässig oder komplett wirkungslos.

Auch bei Fehlersuche ist Burp Suite oft überlegen. Wenn ein Login mit Hydra nicht funktioniert, liegt das Problem häufig nicht an Hydra selbst, sondern an einer falschen Annahme über den Request. Burp macht diese Abweichung sichtbar. Deshalb ist bei Web-Logins die Reihenfolge sinnvoll: erst Analyse mit Burp, dann Übertragung in ein Hydra-Kommando, falls der Workflow statisch genug ist. Für die praktische Umsetzung bei Formularen sind Http Login, Form Login und Post Request als Anschlusswissen relevant.

Burp Suite ist außerdem dort stark, wo nicht nur Credentials getestet werden, sondern die gesamte Authentifizierungslogik bewertet werden soll. Dazu gehören Username Enumeration, inkonsistente Fehlermeldungen, Lockout-Verhalten, MFA-Bypass-Pfade, Session Fixation oder unsaubere Logout-Mechanismen. Hydra kann Credentials testen. Burp Suite kann die Anwendung verstehen. Dieser Unterschied ist im Pentest-Alltag fundamental.

Ein professioneller Workflow beginnt nicht mit Last, sondern mit Modellbildung. Zuerst wird der Login-Prozess vollständig beobachtet. Dazu gehören Request-Methode, Zielpfad, Parameter, Cookies, Header, Redirects, Token-Handling, Antwortmuster und serverseitige Schutzmechanismen. Burp Suite ist dafür das primäre Werkzeug. Erst wenn klar ist, welche Teile des Requests statisch und welche dynamisch sind, lässt sich entscheiden, ob Hydra überhaupt geeignet ist.

Der nächste Schritt ist die Definition eines belastbaren Erfolgs- und Misserfolgskriteriums. Genau hier passieren die meisten Fehler. Viele verlassen sich auf Statuscodes oder offensichtliche Fehltexte, obwohl die Anwendung in beiden Fällen denselben HTTP-Status liefert. Manche Anwendungen antworten immer mit 200 OK und unterscheiden sich nur in einer Redirect-Location, einer Cookie-Änderung oder einer minimalen Längendifferenz. Wer diese Signale nicht sauber identifiziert, produziert False Positives oder übersieht gültige Treffer. Für diese Problematik lohnt sich ein Blick auf False Positive und Debugging.

Erst danach wird entschieden, ob Hydra eingesetzt wird. Wenn der Request ohne wechselnde Token reproduzierbar ist und Erfolg oder Misserfolg an einem stabilen Merkmal erkennbar sind, kann Hydra den eigentlichen Credential-Test übernehmen. Wenn pro Versuch neue Tokens erzeugt werden, Sessions eng gekoppelt sind oder JavaScript zwingend beteiligt ist, bleibt Burp Suite meist das geeignetere Werkzeug. In manchen Fällen ist auch eine eigene Automatisierung sinnvoller als beide Standardwege.

• Login manuell im Browser durchführen und den vollständigen Traffic mitschneiden.
• Mit Repeater einzelne Parameter isoliert verändern und Erfolgsindikatoren verifizieren.
• Erst danach entscheiden, ob Hydra den Workflow stabil nachbilden kann.

Ein sauberer Workflow berücksichtigt auch die Infrastruktur. Reverse Proxies, WAFs, CDN-Schutz, IP-basierte Limits und Session-Bindung beeinflussen das Ergebnis massiv. Hydra kann technisch korrekt konfiguriert sein und trotzdem scheitern, weil die Anwendung nach wenigen Versuchen Antworten künstlich vereinheitlicht oder Verbindungen drosselt. Burp Suite hilft, diese Veränderungen sichtbar zu machen, etwa wenn Response-Zeiten steigen, Header sich ändern oder zusätzliche Challenge-Seiten erscheinen.

In der Praxis ist die Kombination beider Werkzeuge oft am stärksten: Burp Suite für Analyse, Hydra für skalierte Ausführung. Genau diese Trennung sorgt für saubere, nachvollziehbare Ergebnisse und verhindert, dass Zeit in blindes Probieren investiert wird.

Der häufigste Fehler ist eine unvollständige Beschreibung des Requests. Bei Web-Formularen reicht es nicht, Benutzername und Passwort aus dem HTML abzulesen. Entscheidend ist, was der Browser tatsächlich sendet. Dazu gehören oft zusätzliche Hidden Fields, Referer, Origin, Cookies oder Content-Type-Details. Wenn nur die sichtbaren Formularfelder übernommen werden, schlägt der Test fehl oder liefert irreführende Resultate.

Ein zweiter klassischer Fehler ist die falsche Definition des Failure-Strings. Viele Anwender konfigurieren Hydra so, dass ein bestimmter Fehlertext als Misserfolg gilt. Das funktioniert nur, wenn dieser Text in jeder Fehlantwort stabil vorhanden ist. In realen Anwendungen ändern sich Fehltexte je nach Sprache, Lockout-Zustand, Rate Limit oder vorgeschaltetem Proxy. Noch problematischer wird es, wenn Erfolg und Misserfolg denselben Text enthalten, aber sich nur in Redirects oder Cookies unterscheiden.

Drittens werden dynamische Tokens unterschätzt. CSRF-Token, Nonces oder One-Time-Parameter machen einen statischen Hydra-Request unbrauchbar. Ein einmal aus Burp kopierter Request funktioniert dann vielleicht genau einmal und danach nie wieder. Das ist kein Randfall, sondern bei modernen Anwendungen normal. Wer diesen Punkt ignoriert, verbringt viel Zeit mit vermeintlicher Syntax-Fehlersuche, obwohl das eigentliche Problem im Zustandsmodell der Anwendung liegt.

Viertens wird die Wirkung von Threading falsch eingeschätzt. Mehr Threads bedeuten nicht automatisch bessere Ergebnisse. Gegen Web-Logins können zu viele parallele Requests Sessions zerstören, Token invalidieren, WAF-Regeln triggern oder serverseitige Delays aktivieren. Ein langsamer, kontrollierter Test mit wenigen Threads ist oft aussagekräftiger als ein aggressiver Lauf mit hoher Parallelität. Dazu passen Themen wie Speed, Optimierung und Fehler.

Fünftens wird die Antwortauswertung nicht validiert. Ein professioneller Test prüft immer mit bekannten gültigen und bekannten ungültigen Credentials, ob die Erkennungslogik tatsächlich stimmt. Ohne diese Kalibrierung ist jedes Ergebnis fragwürdig. Gerade bei Web-Logins ist es essenziell, die Response-Merkmale vorab mit kontrollierten Testdaten zu verifizieren.

hydra -l testuser -P passwords.txt target.example https-post-form "/login:user=^USER^&pass=^PASS^:F=Invalid credentials"

Ein Kommando wie dieses wirkt plausibel, ist aber ohne Voranalyse oft wertlos. Es sagt nichts über CSRF, Cookies, Redirects, Header-Abhängigkeiten oder alternative Fehlermuster aus. Genau deshalb sollte ein Hydra-Kommando nie der Ausgangspunkt sein, sondern das Ergebnis einer sauberen Request-Analyse.

Auch Burp Suite wird häufig falsch eingesetzt. Ein verbreiteter Fehler ist, direkt Intruder zu starten, ohne den Request vorher in Repeater zu validieren. Wenn bereits ein einzelner modifizierter Request nicht sauber reproduzierbar ist, skaliert Intruder nur einen Fehler. Das Ergebnis sind tausende Requests ohne Aussagekraft. Gerade bei Login-Tests muss zuerst klar sein, welche Parameter stabil sind und welche pro Versuch neu erzeugt werden.

Ein weiteres Problem ist die falsche Interpretation von Burp-Ergebnissen. Viele konzentrieren sich ausschließlich auf Statuscodes oder Response-Längen. Moderne Anwendungen liefern jedoch oft absichtlich uniforme Antworten, um Enumeration und Credential-Angriffe zu erschweren. Unterschiede liegen dann in Headern, Cookies, Redirect-Zielen, Timing oder nachgelagerten Requests. Wer nur die Standardspalten betrachtet, übersieht die eigentlichen Signale.

Burp Suite verleitet außerdem dazu, komplexe Workflows zu lange manuell zu halten, obwohl eine Überführung in Hydra oder ein Skript sinnvoller wäre. Wenn ein Login technisch einfach ist und keine dynamischen Abhängigkeiten hat, ist Burp Intruder oft unnötig schwergewichtig. In solchen Fällen ist ein fokussiertes Tool effizienter. Der Vergleich mit Vs Medusa, Vs Ncrack und Alternativen zeigt denselben Grundsatz: Das beste Werkzeug ist nicht das umfangreichste, sondern das passendste.

Ein dritter Fehler ist das Ignorieren von Session-Kopplung. Manche Anwendungen akzeptieren Login-Versuche nur innerhalb einer frischen Session, die zuvor bestimmte Seiten besucht hat. Burp kann das sichtbar machen, aber nur wenn der gesamte Ablauf beobachtet wird. Wer nur den finalen POST-Request isoliert, verpasst möglicherweise den eigentlichen Zustand, den der Server erwartet. Das betrifft besonders Frameworks mit Anti-CSRF-Mechanismen und Login-Flows, die vor dem Submit bereits serverseitige Session-Daten erzeugen.

Burp Suite ist also nicht automatisch überlegen, nur weil es mehr Funktionen bietet. Ohne disziplinierte Analyse wird auch Burp zu einem Werkzeug, das viel Verkehr erzeugt und wenig Erkenntnis liefert. Die Stärke liegt in der Präzision, nicht in der Menge der Features.

Fall eins: Ein interner SSH-Dienst soll mit einer freigegebenen Benutzerliste geprüft werden. Hier ist Hydra die natürliche Wahl. Der Dienst ist standardisiert, Erfolg und Misserfolg sind protokollseitig klar erkennbar, und es gibt keine Browser- oder Session-Logik. Burp Suite bringt keinen Mehrwert. Ein sauberer Test konzentriert sich auf Benutzerliste, Passwortstrategie, Threading und Timeouts. Für solche Szenarien sind Ssh, Ssh Bruteforce und Ssh Wordlist die relevanten Anschlussbereiche.

Fall zwei: Ein klassisches Web-Login mit statischem POST-Request, ohne CSRF und mit stabiler Fehlermeldung. Hier beginnt der Test mit Burp Suite, um Request und Antwort exakt zu erfassen. Danach kann Hydra sehr effizient übernehmen. Der Burp-Mitschnitt dient nur zur Modellbildung. Sobald klar ist, welche Parameter gesendet werden und welcher String einen Fehlschlag markiert, ist Hydra meist schneller und besser automatisierbar als Burp Intruder.

Fall drei: Eine moderne Web-Anwendung mit Login über JSON-API, CSRF, Session-Cookie, Redirect nach erfolgreicher Anmeldung und zusätzlichem JavaScript-State. In diesem Szenario ist Burp Suite das Hauptwerkzeug. Hydra kann nur dann sinnvoll werden, wenn der Ablauf auf einen stabilen Kern reduziert werden kann. Oft ist das nicht möglich, weil Token und Session pro Versuch neu erzeugt werden. Dann bleibt Burp oder eine maßgeschneiderte Automatisierung die realistische Option.

• Netzwerkdienst ohne Web-Logik: Hydra direkt einsetzen.
• Einfaches Formular mit stabilem Request: Burp zur Analyse, Hydra zur Ausführung.
• Komplexe Web-App mit dynamischen Zuständen: Burp Suite oder eigene Automatisierung bevorzugen.

Diese drei Fälle zeigen, dass Werkzeugwahl keine Glaubensfrage ist. Sie hängt davon ab, wie viel Zustandslogik zwischen Eingabe und Authentifizierungsentscheidung liegt. Je näher ein Ziel an einem standardisierten Protokoll ist, desto stärker wird Hydra. Je stärker ein Ziel an Browser-, Session- und Token-Verhalten gekoppelt ist, desto wichtiger wird Burp Suite.

In der Praxis lohnt es sich, jeden Login zunächst in diese Kategorien einzuordnen. Das spart Zeit, reduziert Fehlersuche und verhindert, dass ein ungeeignetes Werkzeug mit immer mehr Workarounds künstlich passend gemacht wird.

Die Qualität eines Login-Tests steht und fällt mit der Validierung der Ergebnisse. Ein vermeintlicher Treffer ist wertlos, wenn er auf einer falsch interpretierten Antwort basiert. Besonders bei Web-Logins treten False Positives auf, wenn Anwendungen bei Erfolg und Misserfolg ähnliche Inhalte liefern oder Schutzmechanismen Antworten absichtlich vereinheitlichen. Deshalb muss jede Erkennungslogik mit bekannten Testdaten gegengeprüft werden: mindestens ein sicher ungültiger Satz und, falls freigegeben, ein sicher gültiger Satz.

Lockout-Mechanismen sind ein weiterer kritischer Punkt. Viele Anwendungen sperren Benutzerkonten, IPs oder Sessions nach wenigen Fehlversuchen. Hydra kann solche Zustände durch hohe Parallelität schnell auslösen. Burp Suite macht die Veränderung oft früher sichtbar, etwa durch zusätzliche Header, geänderte Fehltexte oder Challenge-Seiten. Ein professioneller Test dokumentiert deshalb nicht nur Treffer, sondern auch den genauen Punkt, an dem Schutzmechanismen aktiv werden.

Timing spielt ebenfalls eine große Rolle. Manche Systeme reagieren bei falschen Passwörtern schneller oder langsamer als bei gültigen Benutzern. Andere führen bei bestimmten Zuständen künstliche Delays ein. Solche Unterschiede können Hinweise auf Enumeration oder Schutzlogik liefern, aber auch Messungen verfälschen. Wer Timing nicht beobachtet, interpretiert langsame Antworten schnell als Netzwerkproblem, obwohl der Server bereits aktiv gegen Automatisierung arbeitet.

Sauberes Logging ist unverzichtbar. Jeder Test sollte nachvollziehbar festhalten, welche Parameter, Listen, Threads, Timeouts, Header und Erfolgskriterien verwendet wurden. Nur so lassen sich Ergebnisse reproduzieren und Fehler später sauber eingrenzen. Für diese operative Ebene sind Output, Logs und Best Practices besonders relevant.

Ein oft unterschätzter Punkt ist die Trennung zwischen Transportfehler und Authentifizierungsfehler. Connection resets, TLS-Probleme, Proxy-Abbrüche oder WAF-Interferenzen dürfen nicht als Login-Misserfolg gewertet werden. Gerade bei aggressiven Tests verschwimmen diese Kategorien schnell. Burp Suite hilft, HTTP-seitige Störungen sichtbar zu machen, während Hydra bei Netzwerkdiensten oft die klarere Fehlerausgabe liefert. Beide Werkzeuge müssen deshalb mit Blick auf ihre jeweilige Ebene interpretiert werden.

In realen Assessments sollte die Werkzeugwahl an Zieltyp, Freigabeumfang, Schutzmechanismen und gewünschter Nachvollziehbarkeit ausgerichtet werden. Hydra ist kein Ersatz für Web-Analyse, und Burp Suite ist kein Ersatz für effiziente Protokolltests. Wer diese Rollen sauber trennt, arbeitet schneller und produziert belastbarere Ergebnisse.

Für interne Infrastrukturprüfungen mit bekannten Diensten ist Hydra oft das primäre Werkzeug. Für Web-Anwendungen mit unbekannter Login-Logik ist Burp Suite fast immer der Einstieg. In Red-Team-Szenarien kommt zusätzlich die Frage nach Sichtbarkeit und Signaturverhalten hinzu. Ein Werkzeug, das technisch funktioniert, kann operativ ungeeignet sein, wenn es zu auffällige Muster erzeugt oder Schutzsysteme früh triggert. Deshalb gehören auch Proxy-Nutzung, Verbindungsraten und Request-Charakteristik in die Planung. Je nach Szenario können Proxy, Vpn oder Red Team relevant werden.

Eine robuste Entscheidungsregel lautet: Wenn der Login-Prozess in einem einzigen stabilen Request beschrieben werden kann und Erfolg oder Misserfolg eindeutig erkennbar sind, ist Hydra meist die effizientere Wahl. Wenn der Prozess mehrere Zustände, dynamische Werte oder browsernahe Logik enthält, ist Burp Suite das geeignetere Werkzeug zur Analyse und oft auch zur Ausführung. Wenn beides nicht ausreicht, ist eine eigene Automatisierung der saubere Weg.

Wichtig ist auch die fachliche Disziplin, Tests nicht zu früh zu skalieren. Erst wenn ein einzelner Versuch vollständig verstanden und reproduzierbar ist, sollte Last erhöht werden. Das gilt unabhängig vom Werkzeug. Viele Probleme, die später als Tool-Limitierung erscheinen, sind in Wahrheit Analysefehler aus der frühen Phase des Workflows.

Am Ende ist der Vergleich nicht als Konkurrenz zu verstehen, sondern als Arbeitsteilung. Hydra liefert Geschwindigkeit, Fokus und Automatisierbarkeit. Burp Suite liefert Transparenz, Kontrolle und Kontext. Wer beide Stärken korrekt einsetzt, baut saubere Workflows statt unsauberer Workarounds.