As a security engineer, I want to forward Passbolt Audit logs to our SIEM for correlation and analysis

Q1. What is the problem that you are trying to solve?
Currently, I can only check audit trail of passwords which I have been granted access to. But for a full coverage of user activities for security event correlation, I need logins, logouts, permission changes, role events, and all audit trail of passwords. I don’t need the passwords themselves.

Q2 - Who is impacted?
All the company as lack of proper security of observability affects everyone.

Q3 - Why is it important and/or urgent?
It is related to the secure usage of the Passbolt itself, along with usage in highly regulated environments.

Q4 - What is your proposed solution? (optional)

As a security professional, I would like to have a specific role to access audit trails within Passbolt, preferably in a dashboard where I can quickly query. Within the same dashboard, I would like to have the ability to set up log forwarding in syslog, json or any other well known format, so that I can use any tool of my own to collect. As an alternative way, I would like to have the ability to log to /var/log/secure socket or a file like /var/log/Passbolt-Audit.log. So that the SIEM agent can collect the structured log from these and forward.


Hello @zbalkan

Welcome to the community!

Please take a look at this link, the feature is coming soon.

1 Like

Hello and welcome to the forum @zbalkan !
I remember that in the past, in v3.12.0, they announced that you can output the action logs in syslog or a file. Maybe this can help you.
Here is the link to the release announcement, so you have to investigate a bit about how it works



The backend is in PHP, IIRC. If I knew PHP, I would try at least implementing or supporting the cause. Yet, I am not capable of it. I saw the report related process but it’s not ready yet. Also, I mentioned a “security admin” role, which allows access to audit trail but not all the passwords. It would add flexibility for managing the secrets with POLA.

I saw the SSO related prioritization. It’s also valuable whoever needs it. We are using pro version and recommending everyone since we are highly satisfied with Passbolt’s capabilities. This is still okay but we need full access to all passwords to be able to ensure we see all the activities. Which is not a good practice.
We are in finance sector and full coverage of our assets, including passwords are important for us, too. Patiently waiting for the update.

:new: The ability to customize Passbolt to output the action logs in syslog or a file

I wasn’t aware of this :open_mouth: I wonder how to customize to output to syslog or file.

Change the env vars to true for a redirection of the logs

We are working on it to create “strategies” to have more rich information because as you will see in the generated logs its very raw


Hi @Termindiego25,

Thanks for the link. I read the link you gave me. But I couldn’t find the blog post they mentioned on how to configure this. Also, I skimmed the documentation but I may have missed that. Do you happen to have the link to the article on how to configure this?

We are looking for pro customers to tailored audit logs please DM me to book a call if you are interested.


1 Like

There is no blog article out on this yet. However the specifications are available here:


Hi @max ,

I am interested but I am going for a vacation. I’ll get in touch when I am back. Until then, I will enable syslog and let it collect real data which I can work on. Thanks!

Please do, we were looking for admin like you who can help us shape default “strategies”. As @max mentioned the engine is there but we need to shape the data to meet real use cases :slight_smile:

1 Like

Hi @remy,

Thanks for the update. I will get in touch. I read the document and saw a couple of points.

  • Logs include UUID values and in SIEM context the meaningful context can be degraded without proper resolution of usernames and resources.
  • When somebody removes a resource, we lose the ability to resolve to the resource name. It applies to users too.
  • In the risk part, I saw ‘N/A’, but there is a risk of accidental leaking of sensitive data. With a well-intended commit can accidentally send passwords into the logs. And, to mitigate the risk, proper checks on QA side can be involved to prevent these kind of leaks, either with technical capabilities or human aspects like mentioning in the code review guide, etc.
1 Like

Hi all,

I am back from vacation and open for testing the logging capabilities. As I commented above, it’s better to have the log with all the details needed without a translation/enrichment phase. So ideally, all UUIDs should be resolved to assets earlier. Then, you can just pass the whole log object as a valid JSON string. It’s preferable to have both UUID and asset name -not the action- as it provides more context.

What can I do to test it out?

1 Like

Hi all,

It has been a while but I wanted to remind myself that I am able to try some features.

Hi all. Anything I can do?


Hey @zbalkan apologies in the delay. Just to summarize my understanding of where you are currently:

  • you have the logs being output to syslog
  • you have these being picked up by your SIEM
  • it is all UUIDs and you’d prefer resource names

Were you looking to do some tinkering here to get it working that way or just asking for a status update on this?

Hi. It’s been a while. Yes, the logs in and of itself should be meaningful. UUIDs belong to Passbolt’s internals and forwarding them into logs is a leaky abstraction at best. It is meaningless for the consumer of the logs. Though UUIDs are needed for troubleshooting and name conflict prevention, the best case would be adding resource name along with UUIDs so that both parties can benefit from it. Secrets are valuable and we’d like to audit all the actions on secrets, then be able to correlate them, create them, finding anomalies, etc. That would improve the workflow a lot.