Feature for auditing all changes to Dependency track

[Gss123123]

Hi, I'm wondering if a critical system like dependency track should have an audit log of all changes made to the data, or at least a table with a high level list of api calls made to it.
Usecase - We have multiple systems interacting with dependency track, most of them publishing boms to the service with one job purging older versions of projects. At times the need is felt for maintaining an audit trail of all changes being made to DT.

The details of the implementation can be worked upon, wanted to know if its worth adding this as a feature.

[stevespringett]

I think its worth discussing, yes. But I think it needs to be framed in the context of properly setting up database servers to perform the audit and change control logging. The application only has partial visibility into database operations. It can only keep track of the changes that it was responsible for making. Changes made to the database outside of the application (via another process, a DBA, etc) would be invisible to the app, therefore audit and change control should likely be implemented on the server. Postgres can do this with audit triggers for example, where a change to a field would result in a change control record being created. Another reason for keeping this closer to the database server is performance.

Has anyone successfully implemented audit triggers or any other mechanism for tracking changes to the underlying dependency-track database?

[Gss123123]

Thats a good idea. With POST triggers in the db, we can ease off the load off the server without slowing down db write operations (since it will be a POST trigger). I had setup a similar audit mechanism before for mysql, I remember there were 2 main difficulties we came across :-

1. Recording the author of the operation is a problem, since mysql cannott provide any authorization data implemented in the service.
2. The trigger queries were slightly lengthy and needed a mechanism to make sure, they were modified to account for new column/table additions to db.
3. Systematic purging of older records in this table.

Other than this, it worked pretty well. Recording old_value,new_value,column_name,timestamp for all changes. Any other issues you see ?