S3
Store cside security alerts in AWS S3 buckets for archival, compliance, and integration with SIEM systems.
Storing notifications in S3
Use an AWS S3 bucket as a notification destination to archive alerts as CSV files. This is useful for long-term storage, compliance requirements, and integration with SIEM or log aggregation systems.
cside uploads one CSV per hour, named alerts-team-<team_id>-<from>-<to>.csv, under the path prefix you configure. An hour with no alerts produces no file.
Setting up an S3 destination
- Open the dashboard and navigate to Team Settings > Notifications
- Create a new notification config or edit an existing one
- Under Send To, click Add destination and select S3
- In the Configuration panel, enter your S3 bucket details:
- S3 Bucket Name: your AWS S3 bucket name
- Region: the AWS region where your bucket is located
- Path (optional): a prefix path within the bucket to organize files
- Click Save or Save & Test
S3 bucket policy
You need to grant cside permission to write to your S3 bucket. Apply the following bucket policy to your S3 bucket settings:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCsideNotificationExport",
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::<your-bucket>/*",
"Principal": {
"AWS": ["arn:aws:iam::590183952644:role/prod-cside-notifications-engine-sa-role"]
}
}
]
}
Replace <your-bucket> with your own bucket name. The grant is write-only: s3:PutObject lets cside add objects and nothing else, so cside cannot list, read, or delete anything in your bucket.
This is the same IAM role and the same grant the Device Intelligence S3 export uses, so one statement covers both. The two are separate destinations with their own bucket, region, and prefix, and their files never collide: alerts land as alerts-team-<team_id>-<from>-<to>.csv, evaluations as fingerprints-team-<team_id>-<from>-<to>.jsonl.
Alert format
Each file is a CSV with a header row and one row per alert, in these 17 columns:
| Column | Description |
|---|---|
domain_id | cside ID of the domain the alert fired on. |
timestamp | When the alert fired. |
trigger_type | The trigger that produced the alert. |
domain | The domain the alert fired on. |
target_type | What target holds, either URL or HASH. |
target | The subject of the alert: a script URL or a script hash. |
action | The action recorded for the alert. |
ruleset_id | ID of the ruleset that matched. |
ruleset_name | Name of the ruleset that matched. |
script_url_1, script_url_2, script_url_3 | The first three triggering script URLs. A fourth or later URL is not exported. |
vuln_cve_id | CVE ID, for vulnerability alerts. |
vuln_package | Affected package. |
vuln_version | Affected version. |
vuln_severity | Reported severity. |
vuln_reference_url | Reference URL for the vulnerability. |
Alert files carry metadata only. They contain no fingerprint or Device Intelligence data, and no raw script bodies.
Save & Test writes a small JSON connectivity probe named test-alert-<destination_id>-<timestamp>.json, not a CSV. It confirms cside can write to your bucket; it is not an alert, and real alerts never use that shape.
Thanks for your feedback!