DefectDojo records an audit trail of changes to its data. Every tracked object automatically
records create, update, and delete events, and relationship
(many-to-many) tables record add and remove events.
Audit tracking is driven by database triggers registered per model. For each
tracked object, three event types can fire:
Event type
When it fires
Action
InsertEvent
A new record is created
Create
UpdateEvent
A record changes — only when a real field value actually changes
Update
DeleteEvent
A record is deleted
Delete
Many-to-many relationship tables (tags, reviewers, firewall IP ranges) track
only add (InsertEvent) and remove (DeleteEvent) — there is no
“update” for a relationship row.
Who — the acting user, taken from the request context.
When — a timestamp.
Source IP — the remote address, honoring X-Forwarded-For proxy chains.
Before/after snapshot — the full field values of the record.
Context / label — groups events originating from the same request. The
label initial_backfill marks historical records imported when tracking was
first enabled.
Events produced by background jobs are stitched back to the
originating request’s context, so an action completed asynchronously is still
attributed to the user who triggered it.
Secrets are never captured. User passwords and notification-webhook header
values are explicitly excluded from event snapshots.
Updates record only on a genuine change. A save that does not alter any
field value produces no update event; auto-managed fields such as
last_updated alone do not trigger one.
Authentication events are not captured here. data
changes only. Login, logout, and failed-login activity are handled separately and are not part of this audit log.
