API-Discovery und Inventarisierung

Warum ein API-Bestand die Grundlage jeder Verteidigung ist

Schutz beginnt mit Sichtbarkeit. Was eine Organisation nicht kennt, kann sie weder patchen noch überwachen noch abschalten. Das NIST hält in SP 800-228 fest, dass die meisten Organisationen Lücken in ihrem API-Bestand haben, selbst wenn ihr übriges Asset-Management ausgereift ist, und dass ohne genaues Inventar die Absicherung des Bestands gar nicht erst beginnen kann. Sicherheitsvorfälle können sich dann auf API-Ebene abspielen, ohne dass das Security-Team davon überhaupt erfährt.

Genau diese Lücke beschreibt das OWASP API Security Project als Improper Inventory Management (API9:2023): Alte Versionen, vergessene Hosts und ungeprüfte Datenflüsse zu Dritten vergrößern die Angriffsfläche. Discovery und Inventarisierung sind das Verteidigungs-Gegenstück dazu. Sie ordnen sich der Identify-Funktion des NIST Cybersecurity Framework unter: erst erkennen, was existiert, dann schützen.

Wichtig ist die Abgrenzung der Begriffe. Discovery ist der Vorgang, APIs aufzuspüren. Das Inventar ist das gepflegte Verzeichnis, das daraus entsteht. Ein einmal erstelltes Inventar veraltet sofort wieder, weil neue Endpunkte entstehen und alte sich verändern. Deshalb sind beide nur als kontinuierlicher Prozess sinnvoll, nicht als einmaliges Projekt.

Auffällige Endpunkte und woran Discovery sie erkennt

Quellen korrelieren: woher der Bestand kommt

Keine einzelne Quelle kennt alle APIs. Ein belastbares Inventar entsteht erst, wenn mehrere Sichten zusammengeführt und gegeneinander abgeglichen werden. Jede Quelle hat blinde Flecken, die eine andere schließt.

• Code und Repositories: Route-Definitionen, Controller, Annotationen und Spezifikationsdateien (etwa openapi.yaml) zeigen, was Teams gebaut haben. Sie verraten aber nicht, ob ein Endpunkt produktiv erreichbar ist.
• Infrastruktur und Gateways: API-Gateways, Load Balancer, Ingress-Regeln, DNS-Einträge und Service-Meshes zeigen, was tatsächlich exponiert und geroutet wird. Endpunkte, die am Gateway vorbei laufen, fehlen hier jedoch.
• Dokumentation und Spezifikationen: OpenAPI-, gRPC- oder GraphQL-Definitionen beschreiben den Soll-Zustand. NIST empfiehlt in REC-API-1, dass jede API überhaupt eine Spezifikation besitzt, idealerweise in einer maschinenlesbaren IDL.
• Asset- und CMDB-Register: Bestehende Verzeichnisse liefern Owner, Geschäftskontext und Sensitivität, sind bei APIs aber oft unvollständig.

Die Korrelation dieser Quellen deckt Widersprüche auf: Ein Endpunkt im Code ohne Gateway-Route, ein Host im DNS ohne Eintrag in der Doku, eine Spezifikation ohne laufenden Dienst. Diese Diskrepanzen sind die eigentlichen Funde.

Laufzeit-Discovery: realer Verkehr gegen die Spezifikation

Statische Quellen beschreiben Absichten. Erst der reale Verkehr zeigt, was tatsächlich läuft. Laufzeit-Discovery beobachtet den produktiven Datenstrom und leitet daraus die Menge der aktiven Endpunkte, Parameter und Datentypen ab. NIST verweist in REC-API-21.1 ausdrücklich auf semantische Datenerkennung zur Laufzeit, die hilft, den Typ der durch ein System fließenden Informationen (etwa eine E-Mail-Adresse) zu erkennen und den Bestand initial aufzubauen.

Der entscheidende Schritt ist der Abgleich: beobachteter Verkehr gegen die freigegebene Spezifikation. Daraus ergeben sich zwei Arten von Abweichungen:

• Verkehr ohne Spezifikation: ein Endpunkt empfängt Anfragen, ist aber in keiner Spec erfasst. Das ist der typische Hinweis auf eine nicht erfasste oder am Prozess vorbei gebaute Schnittstelle.
• Spezifikation ohne Verkehr: ein dokumentierter Endpunkt erhält keine Anfragen. Das deutet auf eine tote Route oder eine ungenutzte Version hin.

Hinzu kommt Spec-Drift: Felder, Statuscodes oder Parameter, die im Verkehr auftauchen, in der Spezifikation aber fehlen oder anders typisiert sind. NIST formuliert in REC-API-3 und REC-API-5, dass Anfrage- und Antwort-Schema samt Validierungsregeln Teil der Spezifikation sein sollen, damit Laufzeit-Werkzeuge genau diesen Abgleich automatisiert leisten können.

Shadow, Zombie, Orphan und Phantom erkennen

Die problematischen Endpunkte sind selten neu und korrekt dokumentiert. Sie fallen durch das Raster, weil sie in mindestens einer der korrelierten Quellen fehlen. Die Branche benennt sie uneinheitlich; entscheidend ist nicht das Etikett, sondern entlang welcher Frage ein Endpunkt auffällt.

• Shadow / Schatten: läuft produktiv, ist aber in keinem Inventar erfasst und der Governance unbekannt. Findbar über Verkehr ohne Spezifikation. NIST nennt solche oft für Debugging, Tests oder Ad-hoc-Lösungen gebauten APIs, die Sicherheits-Reviews umgehen.
• Zombie: eine abgelöste, eigentlich veraltete Version, die nie abgeschaltet wurde und weiter Verkehr empfängt. Findbar über alte Versionspfade im Gateway-Verkehr neben der aktuellen Version.
• Orphan / verwaist: läuft weiter, aber das verantwortliche Team existiert nicht mehr. Findbar über fehlende Owner-Zuordnung im Inventar, nicht über fehlende Sichtbarkeit.
• Phantom: ein Endpunkt, der nie in Spec, Ticket oder Review auftauchte, zunehmend von KI-Codegeneratoren mitgebaut. Findbar nur über Laufzeit-Verkehr, da er in keiner Planungsquelle existiert.

NIST nennt als Treiber dieser Lücken organisatorische Silos, hohe Entwicklungsgeschwindigkeit (je schneller entwickelt wird, desto schneller veralten Inventare) sowie Zombie- und Deprecated-APIs, deren Aufrufer noch nicht migriert sind.

Kontinuierlich statt einmalig: Inventarpflege und Lifecycle

Ein Inventar ist nur so gut wie sein Aktualisierungsmechanismus. NIST formuliert in REC-API-4, dass ein organisationsweites Verzeichnis aller internen und externen APIs zu pflegen ist und je Eintrag enthalten sollte:

• die Spezifikation der API (das Inventar muss nicht die Dokumentation selbst sein),
• Owner-Informationen, um Laufzeitprobleme einer organisatorischen Verantwortung zuzuordnen,
• Laufzeitinformationen wie Service-Instanzen, IP-Adressen, Verkehrsvolumen, Anfrage- und Fehlerraten sowie den Status der Policy-Durchsetzung.

Damit der Bestand nicht wieder veraltet, gehört Discovery in den Lebenszyklus eingebettet. OWASP empfiehlt, Dokumentation automatisch über offene Standards zu erzeugen und den Build der Doku in die CI/CD-Pipeline aufzunehmen. Ein verbreiteter Governance-Hebel ist, eine annotierte Spezifikation zur Bedingung für das Deployment zu machen (das von NIST beschriebene ticket to the platform): Wer keine Spec liefert, kommt nicht in Produktion.

Für das geordnete Abschalten alter Versionen existiert ein eigener Standard. RFC 8594 definiert den Sunset-HTTP-Header, der signalisiert, ab wann eine URI voraussichtlich nicht mehr erreichbar ist. Ein dokumentierter Deprecated-Status mit Sunset-Termin verhindert, dass aus einer abgelösten Version eine Zombie-API wird. Laufzeit-Discovery überwacht parallel, ob der Verkehr auf der alten Version tatsächlich auf null sinkt, bevor abgeschaltet wird.

Venedys Discovery-Kern

Diesen Abgleich von realem Verkehr gegen die freigegebene Spezifikation bildet Venedy als Kernfunktion ab. Die Plattform korreliert beobachteten Verkehr mit den vorhandenen Spezifikationen und macht Abweichungen sichtbar: Endpunkte mit Verkehr ohne Spec, dokumentierte Routen ohne Verkehr sowie Drift in Feldern, Typen und Statuscodes. So werden Shadow-, Zombie-, Orphan- und Phantom-Endpunkte als konkrete Befunde an der eigenen Schnittstelle benannt, statt nur abstrakt als Risiko zu gelten.

Weil neue Endpunkte laufend entstehen, ist die Discovery kontinuierlich angelegt: Der Bestand wird fortlaufend gegen die Realität abgeglichen, nicht in einem einmaligen Scan eingefroren. Venedy wird als Plattform betrieben und nicht selbst gehostet; der konzeptionelle Discovery-Kern bleibt davon unberührt und folgt den hier beschriebenen Prinzipien aus OWASP API9 und NIST SP 800-228.

Quellen

• API9:2023 Improper Inventory Management - OWASP API Security Top 10 OWASP API Security Project, 2023
• NIST SP 800-228: Guidelines for API Protection for Cloud-Native Systems National Institute of Standards and Technology (NIST), 2025
• OpenAPI Specification v3.2.0 OpenAPI Initiative / Linux Foundation, 2025
• RFC 8594: The Sunset HTTP Header Field IETF, 2019
• OWASP API Security Project OWASP, 2023