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.
Quelltext offen: jede Regel nachlesbar
Der Quelltext von wm-audit liegt öffentlich auf GitHub: das Rust-Programm mit allen Prüfregeln, Berichtsformaten, Prüffällen und Tests – und die vollständige Dokumentation der Kommandozeile. Ihr Security-Team kann jede Aussage im Code prüfen und das Programm selbst bauen.
github.com/cehlert9999/wm-audit
NIS2 verlangt, die Wirksamkeit zu bewerten – auch am API-Gateway
wm-audit prüft die Konfiguration Ihres Gateways bei jeder Änderung automatisch und macht daraus eine Aufgabenliste mit Anleitung und Test je Aufgabe. Jeder Bericht lässt sich als Nachweis archivieren.
Ton per Klick einschalten · Gezeigt: echter Bericht aus einem Lauf gegen unseren Testexport
$ wm-audit gateway-export.zipwm-audit 1.0.0 · gateway-export.zip (zip)10 APIs gelesen (10 eindeutig) · 1 Dateien übersprungen · 2 gesperrte Einträge nicht geöffnet Befunde: 12 (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.
1.000
Einzelprüfungen
10 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,15 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.
Zehn 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.
Kontingent über einen Tag oder länger
Laut IBM wird es erst nach Ablauf des Intervalls aufgefüllt – Spitzen bremst es nicht.
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.
Was eine Rate-Limit-Policy bei einer Lastspitze wirklich tut
wm-audit liest die Traffic-Optimization-Policies jeder API aus. Im Bericht spielt der Lastrechner damit Ihre Lastprofile durch: was das Backend erreicht, was das Gateway mit 429 ablehnt und was der Bulkhead mit 503.
Echter Bericht · Grenze aus dem Testexport: 50.000 Aufrufe je Tag
Ein Kontingent, kein Glätter
Laut IBM zählt das Gateway nach dem Token-Bucket-Verfahren und füllt erst nach Ablauf des Intervalls auf. Ein Tageskontingent lässt die ganze Spitze durch.
Danach 429 für alle
Ist das Kontingent leer, lehnt das Gateway bis zum Ende des Intervalls ab – je nach Einstellung auch Anwendungen, die sich normal verhalten.
Annahmen offen ausgewiesen
Knoten, Bulkhead und Antwortzeit stehen nicht im Export. Der Rechner fragt sie ab und nennt zu jeder Modellaussage die IBM-Quelle.
Läuft in jeder Pipeline – als Testbericht
Mit --junit wird jede API zur Testsuite und jede Prüfregel zum Testfall. Jenkins, GitLab und Azure DevOps zeigen das Ergebnis wie Ihre übrigen Tests; mit --fail-on stoppt ein belegter Befund die Pipeline.
steps {
sh 'wm-audit gateway-export.zip --html -o wm-audit-bericht.html'
sh 'wm-audit gateway-export.zip --junit -o wm-audit-junit.xml --fail-on high'
}
post {
always { junit 'wm-audit-junit.xml' }
}Kein Zeitstempel im Bericht: Derselbe Export ergibt dieselbe Datei, Verläufe je Regel und API bleiben über die Läufe vergleichbar. Alle Optionen und Beispiele für GitLab und Azure DevOps →
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.
Öffnet keine Passwörter und Schlüssel
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: 15 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 13.10.2026; wöchentlich neu geprüft
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, das Werkzeug für Laufzeittests von Leanofy, 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.
Auf Windows, macOS (Apple Silicon und Intel) und Linux – jeweils als ein einzelnes Programm mit Startdatei: Export auf die Datei ziehen, der Bericht öffnet sich im Browser. Eine Installation oder Laufzeitumgebung ist nicht nötig.
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 --junit schreibt wm-audit einen JUnit-Bericht, den Jenkins, GitLab und Azure DevOps als Testergebnis anzeigen: je API eine Testsuite, je Prüfregel ein Testfall. Mit --fail-on high endet das Programm mit einem Fehlercode, sobald ein belegter Befund mindestens die Schwere „high“ hat. Alle Optionen und Beispiel-Pipelines stehen in der Dokumentation.
Der HTML-Bericht liest die Traffic-Optimization-Policies jeder API aus und spielt damit ein Lastprofil durch: Was erreicht das Backend, was lehnt das Gateway mit 429 ab, was der Bulkhead mit 503? Das Modell stützt sich nur auf Aussagen der IBM-Dokumentation. Werte, die nicht im Export stehen – etwa die Zahl der Gateway-Knoten oder die Antwortzeit des Backends –, geben Sie als Annahme ein.
NIS2 verlangt von betroffenen Einrichtungen, die Wirksamkeit ihrer Sicherheitsmaßnahmen zu bewerten (§ 30 Abs. 2 Nr. 6 BSIG). Für die Konfiguration Ihres webMethods API Gateway übernimmt wm-audit diesen Teil automatisch: Mit --fail-on high läuft die Prüfung bei jeder Änderung in der Pipeline, und jeder Bericht nennt den SHA-256 der geprüften Datei und lässt sich als Nachweis archivieren. NIS2 insgesamt deckt wm-audit nicht ab; ob die Policies im Betrieb greifen, zeigt erst ein Test gegen die laufende API.
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 öffentlich auf GitHub (github.com/cehlert9999/wm-audit, Apache-2.0) und liegt zusätzlich dem Lieferpaket bei.
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.