Audit Logging

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.

How it works#

Audit tracking is driven by database triggers registered per model. For each tracked object, three event types can fire:

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.

What is captured with every event#

• 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.

Core (Open Source) — tracked actions#

Core — relationship (add / remove) events#

Pro — tracked actions#

Pro — RBAC / permissions#

Pro — relationship (add / remove) events#

Configuration & retention (On-Premise Controls)#

Notes and limitations#

• 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.