To help administrators keep track of various events, Security for Jira Cloud has an audit log. Due to Atlassian policies, we cannot write to the Atlassian audit log.
Audit log entries are retained for 90 days.
Accessing the audit log
From the Soteri settings page, click on Audit Log in the top right of the page.
Viewing events
The audit log page shows events ordered from most to least recent.
The “Show more” column on the right can be clicked to show the details of individual events, including the Atlassian user ID of the author. (Events with no associated user, such as scans starting and completing, use “System” as the author)
The search boxes at the top of the page can be used to filter events by a substring of the Atlassian user ID, event type, or event details (which are stored as JSON). Click the search icon or press enter in one of the search boxes to filter. For example, the above event matches each of these filters:
Exporting events
The export button on the top right exports events matching the current filters as a CSV file.
Who can view the audit log?
The audit log is available to Jira administrators, plus any users and groups granted access under App Access on the Soteri settings page.
The audit log covers the entire instance. In order to ensure traceability, it is not filtered to particular spaces like the Dashboard. As such, an App Administrator will be able to see every event recorded for the instance, including events for spaces they cannot browse in Jira.
Audit events record identifiers and metadata only. This includes things like:
-
space and work item IDs and keys
-
finding counts
-
rule names
-
timestamps
-
author names
-
links to Soteri pages
They never include scanned content or the matched text of a finding. Viewing the text content of findings themselves still requires Read permission on the space.
Grant App Access only to people you trust with instance-wide visibility into scanning activity.
List of audited events
|
Event |
Detail fields |
|---|---|
|
Global setting events |
|
|
Updated app access configuration
|
|
|
Updated instance settings
|
|
|
Sent settings to Soteri Support
|
This event carries no detail fields. |
|
Rule setting events |
|
|
Toggled built-in rule
|
|
|
Updated email rule settings
|
|
|
Updated generic password rule settings
|
|
|
Created custom rule
|
|
|
Updated custom rule
|
|
|
Deleted custom rule
|
|
|
Custom rule was automatically disabled
|
|
|
Globally reviewed finding events |
|
|
Added globally reviewed false positives
|
|
|
Deleted globally reviewed false positives
|
|
|
Deleted all globally reviewed false positives
|
|
|
Exported globally reviewed false positives
|
This event carries no detail fields. |
|
Reviewed finding events |
|
|
Reviewed a finding
|
|
|
Deleted a reviewed finding
|
|
|
Remediation events |
|
|
Labeled content containing a finding
|
|
|
Removed the label from content containing a finding
|
|
|
Space scan events |
|
|
Queued full instance rescan
|
This event carries no detail fields. |
|
Scheduled space scan
|
|
|
Scheduled content scan
|
|
|
Started space scan
|
|
|
Finished space scan
|
|
|
Error while running space scan
|
|
|
Findings in content version
|
|
|
Could not access space
|
|
|
Webhook events |
|
|
Added webhook
|
|
|
Updated webhook
|
|
|
Deleted webhook
|
|
|
Webhook was disabled
|
|
|
Export events |
|
|
Exported findings
|
|
|
Exported reviewed findings
|
|
|
Exported dashboard
|
This event carries no detail fields. |
|
Exported audit log
|
|
|
Model rule events |
|
|
Created model rule
|
|
|
Updated model rule
|
|
|
Deleted model rule
|
|
|
API key events |
|
|
Issued API key
|
|
|
Revoked API key
|
|
Field conventions
Change summary fields
An event that reports an update records a summary of what changed rather than a snapshot of the new state. Within such a summary:
-
An unchanged single value appears under its own name, with its unchanged value.
-
A changed single value appears under its own name with the new value, and its previous value appears under
previous<Field>(for examplenameandpreviousName). The presence of theprevious<Field>key is what marks the value as changed. -
A list never appears under its own name. Its difference appears as
<field>Addedand<field>Removed, each holding only the entries on that side, and a side with no entries is omitted. A list that did not change is absent altogether.
Naming
Some fields are named for a model shared with Security for Confluence Cloud rather than for Jira's own vocabulary. spaceId and spaceKey identify a project, and contentTitle holds the key of a work item. The fields named for Jira's own vocabulary, such as issueId, issueKey, and projectKey, mean what they say. The event display names and their groupings follow the same shared model, so several of them say "space" where they mean a project. The app's Audit Log page shows them in that form as well.Field conventions
Change summary fields
An event that reports an update records a summary of what changed rather than a snapshot of the new state. Within such a summary:
-
An unchanged single value appears under its own name, with its unchanged value.
-
A changed single value appears under its own name with the new value, and its previous value appears under
previous<Field>(for examplenameandpreviousName). The presence of theprevious<Field>key is what marks the value as changed. -
A list never appears under its own name. Its difference appears as
<field>Addedand<field>Removed, each holding only the entries on that side, and a side with no entries is omitted. A list that did not change is absent altogether.
Naming
Some fields are named for a model shared with Security for Confluence Cloud rather than for Jira's own vocabulary. spaceId and spaceKey identify a project, and contentTitle holds the key of a work item. The fields named for Jira's own vocabulary, such as issueId, issueKey, and projectKey, mean what they say. The event display names and their groupings follow the same shared model, so several of them say "space" where they mean a project. The app's Audit Log page shows them in that form as well.