DefectDojo zeichnet einen Audit-Trail der Änderungen an seinen Daten auf. Jedes verfolgte Objekt zeichnet automatisch Ereignisse für Erstellen, Aktualisieren und Löschen auf, und Beziehungstabellen (many-to-many) zeichnen Ereignisse für Hinzufügen und Entfernen auf.
Die Audit-Verfolgung wird durch Datenbank-Trigger gesteuert, die pro Modell registriert sind. Für jedes
verfolgte Objekt können drei Ereignistypen ausgelöst werden:
Ereignistyp
Wann es ausgelöst wird
Aktion
InsertEvent
Ein neuer Datensatz wird erstellt
Erstellen
UpdateEvent
Ein Datensatz ändert sich — nur wenn sich ein tatsächlicher Feldwert wirklich ändert
Aktualisieren
DeleteEvent
Ein Datensatz wird gelöscht
Löschen
Many-to-many-Beziehungstabellen (Tags, Reviewer, Firewall-IP-Bereiche) verfolgen
nur Hinzufügen (InsertEvent) und Entfernen (DeleteEvent) — für eine Beziehungszeile gibt es kein
„Update“.
Wer — der handelnde Benutzer, entnommen aus dem Request-Kontext.
Wann — ein Zeitstempel.
Quell-IP — die Remote-Adresse, unter Berücksichtigung von X-Forwarded-For-Proxy-Ketten.
Vorher-/Nachher-Snapshot — die vollständigen Feldwerte des Datensatzes.
Context / Label — gruppiert Ereignisse, die aus derselben Anfrage stammen. Das
Label initial_backfill kennzeichnet historische Datensätze, die importiert wurden, als die Verfolgung
erstmals aktiviert wurde.
Ereignisse, die von Hintergrundjobs erzeugt werden, werden dem Kontext
der ursprünglichen Anfrage wieder zugeordnet, sodass eine asynchron abgeschlossene Aktion weiterhin
dem Benutzer zugeschrieben wird, der sie ausgelöst hat.
Geheimnisse werden niemals erfasst. Benutzerpasswörter und die Header-Werte von Benachrichtigungs-Webhooks
sind ausdrücklich von Ereignis-Snapshots ausgeschlossen.
Updates werden nur bei einer echten Änderung aufgezeichnet. Ein Speichervorgang, der keinen
Feldwert ändert, erzeugt kein Update-Ereignis; automatisch verwaltete Felder wie
last_updated allein lösen keines aus.
Authentifizierungsereignisse werden hier nicht erfasst. Nur
Datenänderungen. Login-, Logout- und fehlgeschlagene Login-Versuche werden separat behandelt und sind nicht Teil dieses Audit-Protokolls.