Skip to main content

Specific Changes in Stack Update Audit Events

Feature RequestsAccess ControlLogsStacks

Stack update audit events are currently missing an important piece of context for audits in that they only include the state of the stack after the update. With the current info we can see that a user updated a stack, but not the specific change to the stack that the user made. My team would like to see the specific change made to the stack in the audit log event, for instance on setting a new branch for the code source, the before and after branch name. More broadly this seems applicable to any resource that can be changed in an update action.

Workaround
Problem
Status: ⬆️ Gathering votes1 comment

Log in to comment and vote

Comments1

  • Jonah Kowall

    Team•

    Jul 20

    Hello there Jesse, hope you are well and thanks for the feature request. Can you answer a few questions either here or feel free to email me jonahk at spacelift.io

    Have you considered Audit trail webhooks: you can stream audit events to your own endpoint or SIEM with signature verification, giving you a durable external timeline of stack-configuration events. See https://docs.spacelift.io/integrations/audit-trail.


    Configuration as code: if you manage stacks via the Spacelift Terraform provider (or keep stack config in VCS), the before/after of any setting change, including the code source branch in your example, is captured in your version control history and PR reviews, which many auditors accept as the authoritative record of "who changed what."

    To make sure we scope the native before/after diff around what auditors actually need, it would help to understand:

    • Which specific stack fields matter most for your audits (branch, worker pool, env vars, integrations, etc.)?

    • Is this driven by a specific compliance framework (SOC 2, ISO 27001, FedRAMP, internal controls)?

    • How often do you need to reconstruct a specific change, and what's the impact when you can't today?