So, SaaS Connector Customizers. They’re pretty cool. However, new customizers or updates to existing customizers don’t seem to show up in the audit logs. You also can’t pull down a customizer’s code, because it’s compiled and minified into Javascript and thus becomes unreadable.
This is untenable from a compliance perspective. We have sources set up that could be in-scope for SOX compliance or other audit frameworks, and no way to show that the customizers that control these sources aren’t being modified.
We just recently had this solved for Transforms with their addition to the Audit Logs, so it’s really disappointing to see this crop up all over again on a brand new feature. For a product that’s supposed to make compliance easier, there sure are a lot of auditability gaps.
For your auditors, I would have as part of your control testing to produce a screenshot of the version history for a given connector each audit period so they can compare it to the last.
It won’t tell them what changed, but it will tell them that something did change and that might be good enough to get by
But that feels insufficient. If we can see that changes were made, but can’t see what those changes were, that doesn’t do anything to prove that the changes were what we say they were. A malicious actor could, in theory, say they were making one change, but actually make a different change, and there would be no way to catch that, even while the customizer is still in place. This is a terrible design, from the security/compliance perspective.
Agreed it’s not ideal there are no audit events being recorded for new versions of SaaS customizers being deploy, but even if there were, I’m not sure how SailPoint would represent those changes in an audit event given there could be mass code changes, etc. If they did allow you to download specific versions from history maybe that is something, but feels tedious.
Are your customizers being stored in version control? In my opinion, the ideal approach here would be to have a version control repository which is following decent practices around committing code changes, following some branching strategy, approvals on PRs, etc. so you have full audit in version control of changes. In addition to that, you could build out a CI/CD pipeline to package the customizer and deploy it to a target tenant. You could do this by invoking the SailPoint CLI or calling the customizer endpoints directly (which aren’t really documented but do exist). It would be hard to stop people from manually deploying new versions of a customizer, but hopefully you could enforce this process to make compliance teams happy in your scenario.
Sure, but that only solves half the problem. To your point, the same problem still exists with Transforms (the audit event doesn’t show what changed, or even the full before/after), but at least there we can see when changes were made and by whom.
