Was Ihr webMethods-Gateway offenlässt – direkt aus dem Export
Eine API-Spezifikation sagt, was eine Schnittstelle tun soll. Der Export Ihres Gateways sagt, was sie tatsächlich tut: welche Policies greifen, wohin weitergeleitet wird, welche Protokolle erlaubt sind. wm-audit liest diesen Export und zeigt die Lücken – auf Ihrem Rechner, ohne Netzwerk und ohne eine einzige Anfrage an Ihre APIs.
$ wm-audit gateway-export.zipwm-audit 0.2.0 · gateway-export.zip (zip)9 APIs gelesen (9 eindeutig) · 1 Dateien übersprungen · 2 gesperrte Einträge nicht geöffnet Befunde: 11 (7 belegt) CRITICAL belegt gw.anonymous_allowed AnonymAPI 1.0 HIGH belegt gw.identify_or OderAPI 1.0 HIGH belegt gw.plaintext_backend RoutingKlartextAPI 2.0 MEDIUM wahrscheinlich gw.no_traffic_limit OhneLimitAPI 1.0 …
Auszug aus einem Lauf gegen unsere Testexporte. Im Browser öffnet sich derselbe Bericht mit Aufgabenliste: was sofort zu beheben ist, mit Schritt-für-Schritt-Anleitung für das Gateway und der Datei im Export, aus der jeder Befund stammt.
Ein Lauf statt 100 Durchgänge
Von Hand prüft man im API Gateway jede API einzeln: öffnen, Reiter Policies, die Policy-Stufen durchsehen. wm-audit prüft den ganzen Katalog auf einmal – und liefert die Aufgabenliste gleich mit.
900
Einzelprüfungen
9 Prüfregeln je API, in einem Lauf über den ganzen Katalog
0,01 s
für 100 APIs
gemessen: 556 Exportdateien; 1.000 APIs in 0,14 s
1 statt 100
Durchgänge
von Hand je API: öffnen, Reiter Policies, bis zu sieben Policy-Stufen prüfen
Beispielrechnung: Bei angenommenen 5 Minuten je API sind 100 APIs von Hand gut 8 Stunden Klickarbeit – nach jeder Änderung von vorn. wm-audit wiederholt die Prüfung in jeder Pipeline und zeigt Product Owner und QA auf einen Blick, was sofort zu tun ist.
Neun Prüfungen auf die Konfiguration, die tatsächlich greift
Belegte Befunde lesen sich direkt aus der Konfiguration ab und fließen in die Bewertung ein. Hinweise sind starke Anzeichen und werden getrennt ausgewiesen.
Identify-Policy lässt anonymen Zugriff zu
Die Policy ist da, hebt sich über allowAnonymous aber selbst auf.
API ohne Identify-and-Authorize-Policy
Das Gateway reicht jeden Aufrufer an das Backend durch.
Identifikationsverfahren ODER-verknüpft
Wo API-Key und Token gemeint waren, genügt der API-Key allein.
Gateway nimmt unverschlüsseltes HTTP an
Zugangsdaten sind auf dem Weg zum Gateway mitlesbar.
Weiterleitung an ein Klartext-Backend
Erkannt am Ziel der Routing-Policy, Aliase aufgelöst.
Nur Anwendungs-, keine Benutzeridentität
Wer handelt, muss dann allein das Backend prüfen.
Security-Header gehen ans Backend
passSecurityHeaders reicht den Authorization-Header weiter.
Keine Mengen- oder Größenbegrenzung
Auf API-Ebene ist keine Traffic-Policy gesetzt.
Anfragen werden protokolliert
Log-Invocation kann Nutzdaten in die Logs schreiben.
Nur zugeordnete Policies zählen
Eine Policy-Aktion zählt nur, wenn sie im Gateway einer Stufe zugeordnet ist. Eine liegengebliebene Datei verdeckt keine Lücke.
Das echte Routing-Ziel
Ob hinter dem Gateway verschlüsselt weitergeleitet wird, entscheidet die Routing-Policy samt Alias, nicht die Serverliste der importierten Spezifikation.
Test und Produktion getrennt
Liegen mehrere Umgebungen in einem Export, prüft wm-audit jede für sich. Eine Policy aus der Produktion verdeckt keine Lücke im Test.
Gebaut, um durch Ihre Freigabe zu kommen
Jede Zusage ist mit einem automatischen Test belegt. Das Datenblatt fasst sie zusammen, das ausführliche Sicherheitsdatenblatt nennt zu jeder Zusage den Test, der sie belegt.
Kein Netzwerk
Keine Netzwerk- oder TLS-Bibliotheken im Programm. Eine Bann-Liste in der Lieferkettenprüfung schließt sie aus.
Zugangsdaten bleiben zu
PassmanData, Keystore, Truststore und Kerberos werden nie geöffnet, nur gezählt. Passwörter in Adressen werden im Bericht geschwärzt.
Nur lesend
Der Export bleibt unverändert, ein ZIP wird nie entpackt. Geschrieben wird nur die Berichtsdatei, die Sie angeben.
Speichersicher
Geschrieben in Rust, ohne unsafe-Code. Programmabbrüche über unwrap und panic sind per Prüfregel ausgeschlossen.
Robust gegen manipulierte Exporte
Feste Grenzen gegen ZIP- und JSON-Bomben. Doppelte ZIP-Einträge werden abgelehnt, Symlinks nicht verfolgt.
Transparent
Jede übersprungene Datei steht mit Grund im Bericht, dazu der SHA-256 der geprüften Datei.
Gleiches Ergebnis bei gleichem Export
Gleicher Export, byte-gleicher Bericht. Ergebnisse lassen sich vergleichen und archivieren.
Gegen eine Referenz geprüft
Identisch mit der Referenzfassung: 13 feste Prüffälle und 10.000 zufällig erzeugte Exporte.
23
Bausteine
alle Abhängigkeiten, nur aus crates.io
3
Lizenzen
MIT, Apache-2.0, Zlib – kein Copyleft
0
bekannte Schwachstellen
cargo-audit gegen RustSec, Stand 09.10.2026
1:1
reproduzierbar
zwei Builds bitgleich, Stückliste als CycloneDX
Diese Fragen nennt wm-audit, statt sie zu bewerten
- ?Wird ein erfundener API-Key abgewiesen?
- ?Wird die JWT-Signatur wirklich geprüft?
- ?Sieht ein Nutzer Daten, die ihm nicht gehören (BOLA)?
- ?Wird die Rollenprüfung durchgesetzt?
Das zeigt erst ein Test gegen die laufende API. sectestx prüft diese Fragen live gegen Ihre Testumgebung, im eigenen Netz.
Was Security-Teams zu wm-audit fragen
Nein. wm-audit läuft auf Ihrem Rechner und braucht keine Netzwerkverbindung. Der Export und der Bericht bleiben bei Ihnen.
Einen Bericht, der sich im Browser öffnet. Oben stehen Ihre Aufgaben: was sofort zu beheben ist und was zu prüfen ist. Zu jeder Aufgabe gibt es eine Schritt-für-Schritt-Anleitung für das webMethods API Gateway mit Verweis auf die IBM-Dokumentation und einen Test, mit dem Sie den Erfolg prüfen. Für Pipelines gibt es denselben Bericht als Text oder als JSON.
Ein Export enthält unter PassmanData und in Keystores Passwörter und Schlüssel. wm-audit öffnet diese Einträge nie, es zählt sie nur. Steht in einer Weiterleitungsadresse ein Passwort, wird es im Bericht geschwärzt.
Geprüft ist das Exportformat von webMethods API Gateway 10.x, mit eigenen Testexporten und öffentlichen Beispielexporten von Software AG. Sie übergeben einen ganzen Export als ZIP-Datei oder als entpackten Ordner.
Nein. wm-audit liest die Konfiguration. Ob ein erfundener API-Key abgewiesen wird oder ein Nutzer fremde Daten sieht, zeigt erst ein Test gegen die laufende API. Diese Fragen nennt der Bericht ausdrücklich, und sectestx testet sie live.
Ja. Mit der Option --fail-on high endet das Programm mit einem Fehlercode, sobald ein belegter Befund mindestens die Schwere „high“ hat. Für Pipelines gibt es den Bericht zusätzlich als Text oder als JSON.
wm-audit ist ein einzelnes Programm ohne Laufzeitumgebung, in Rust geschrieben, ohne Netzwerkfunktionen und mit 23 geprüften Open-Source-Bausteinen. Für das Review gibt es ein Sicherheitsdatenblatt, das zu jeder Zusage den belegenden Test nennt, eine Stückliste (SBOM) und ein Prüfskript, das alle Prüfungen in einem Lauf wiederholt. Der Quelltext ist für das Review einsehbar.
Ihren Gateway-Export prüfen – bei Ihnen, nicht bei uns
Geben Sie Ihrem Security-Team das Datenblatt, oder sprechen Sie mit uns über den Einsatz in Ihrem Haus. Der Export verlässt Ihr Netz dabei nicht.