Ein Sicherheits-Audit, das das Behobene erneut prüft – und wer was sieht

Zunächst einmal: ADRI auditiert nur Eigenes oder Autorisiertes. Bevor ADRI ein aktives Audit gegen eine Website startet, verlangt es im Chat ein ausdrückliches Ja mit einer Erklärung: dass du Inhaber dieses Ziels bist oder eine schriftliche Genehmigung des Inhabers hast. Die Anfrage und deine Antwort werden protokolliert. Standardmäßig können die Geschäftsführung, die Verwaltung und der Super-Administrator Audits anfordern, und jede Anfrage – auch die abgelehnten – bleibt im Audit-Bildschirm der Scans erhalten.

Was ist ein Re-Test von Schwachstellen?

Es bedeutet, einen Fehler erneut zu testen, nachdem jemand sagt, er habe ihn behoben. Das klingt offensichtlich, aber genau hier geht am meisten schief: Der Patch wurde auf einem Server eingespielt und nicht auf einem anderen, eine Route wurde repariert und die daneben sieht weiterhin gleich aus, oder ein späteres Update hat ihn wieder geöffnet.

Mit ADRI ist ein „Re-Test“ so einfach wie ein weiteres Audit desselben Ziels anzufordern. Der Unterschied ist, dass ADRI sich nun merkt, was zu jedem Fund entschieden wurde.

Jeder Fund hat sein Datenblatt und seinen Status

Jeder Fund erhält eine stabile Kennung der Art H-1a2b3c4d, die von einem Audit zum nächsten gleich bleibt. Und er durchläuft diese Zustände:

• Verdacht. Der Scan hat es gefunden, und es ist noch nicht bestätigt.
• Verifiziert. Es gibt einen Beleg, dass es real ist: ADRI hält ihn mit seiner Notiz fest, oder der Scan selbst hat es bewiesen.
• Behoben. Das sagt ein Mensch, mit der Kennung des Fundes in seiner Nachricht. ADRI kann es nicht von sich aus als behoben einstufen.
• Geschlossen. Beim nächsten Audit erscheint es nicht mehr, und der Test, der es erkannte, lief ordnungsgemäß.
• Wieder geöffnet. Du hast es als behoben eingestuft, und es taucht weiterhin auf.

Es gibt außerdem zwei Entscheidungen, die nur ein Mensch trifft: falsch positiv (kein echtes Problem) und akzeptiert (es ist real, aber du nimmst das Risiko in Kauf). Beide bleiben mit ihrer Notiz stehen.

Wann kann eine Schwachstelle als geschlossen gelten?

Erst wenn der neue Test es belegt. Die Regeln sind bewusst streng:

• Wenn der Test, der es hätte erkennen sollen, gar nicht ausgeführt wurde oder fehlgeschlagen ist, wird der Re-Test als nicht schlüssig markiert, und das wird dir gesagt. Es wird nichts abgeschlossen, nur weil man nicht hingeschaut hat.
• Wenn ein offener Befund einfach nicht erscheint, wird er nicht automatisch geschlossen: Möglicherweise wurde dieser Teil diesmal nicht geprüft.
• Wenn etwas Geschlossenes wieder auftaucht, wird es als Regression markiert, und genau das ist am wichtigsten zu sehen.

Die Zusammenfassung dieser Änderungen steht oben im Bericht: was geschlossen wurde, was wieder geöffnet wurde und was zurückkam.

Was ist eine rollenbasierte Zugriffsmatrix?

Viele schwerwiegende Fehler sind von außen nicht sichtbar. Ein anonymer Scan erkennt nicht, dass ein Mitarbeiter den Datensatz eines anderen öffnen kann oder dass ein Portal-Kunde Rechnungen sieht, die ihm nicht gehören. Dafür gibt es die rollenbasierte Zugriffsmatrix.

So funktioniert es: Du deklarierst in einer Datei die Rollen deiner Anwendung, mit Testkonten aus deiner Testumgebung, und welche Rollen jede Route sehen können sollten. ADRI bereitet dir die Ausgangsvorlage vor, wenn du ihm den Code gibst. Danach fragt ADRI jede Route mit jeder Rolle ab und vergleicht:

• 🔴 Unberechtigter Zugriff: eine Rolle, die die Route nicht sehen sollte, sieht sie.
• ⚠️ Unerwartete Blockierung: eine Rolle, die sie sehen sollte, kann nicht darauf zugreifen.
• ❔ Unbestimmt: ein Serverfehler oder eine mehrdeutige Antwort, die manuell geprüft werden muss.

Um keine Schäden zu verursachen, führt ADRI nur Lesezugriffe aus, folgt keinen Weiterleitungen, verlässt die von dir angegebene Domain nicht und hat ein Limit für Routen und Rollen, mit Pausen zwischen den Anfragen. Im Bericht erscheinen weder die Inhalte der Seiten noch die Test-Cookies: nur der Status, die Größe und ein Fingerabdruck zum Vergleichen. Die Testkonten stellst du bereit; ADRI erfindet sie nicht und fragt dich auch nicht im Chat danach.

Wenn du den Code hast, zeigt das Audit auf die Zeile

Wenn du ADRI den Pfad zum Code deiner Anwendung angibst, erstellt ADRI vorher eine statische Übersicht: welche Routen es gibt, welche eine Anmeldung verlangen und welche zu heiklen Vorgängen führen. Durch den Abgleich mit dem Scan erscheint ein durch den Code bestätigter Befund mit seiner Ursache: Datei und Zeile. Was der Code andeutet, aber der Scan nicht berührt hat, bleibt ein Hinweis, nie ein Befund.

Beurteilt, repariert nicht

Das Audit zeigt Befunde auf und priorisiert sie; es wendet keine Patches eigenmächtig an. Wenn im Code etwas repariert werden muss, bereitet ADRI es vor, und die Umsetzung erfolgt mit deiner Zustimmung. Danach schließt ein weiteres Audit den Kreis.

Mehr unter Sicherheit und Compliance und unter automatisches Pentesting mit KI-Agenten. Wenn dich interessiert, wie ADRI vor dem Handeln um Erlaubnis bittet, erklären wir das unter wann ADRI dich um Erlaubnis bittet, oder fordere eine Demo an.

Häufige Fragen

• Sicherheit
• Audit
• Rollen
• ADRI