Skip to main content
Storing notifications in S3
Language

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

  1. Open the dashboard and navigate to Team Settings > Notifications
  2. Create a new notification config or edit an existing one
  3. Under Send To, click Add destination and select S3
  4. 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
  5. 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"]
      }
    }
  ]
}
Important

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.

Sharing a bucket with the Device Intelligence export

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:

ColumnDescription
domain_idcside ID of the domain the alert fired on.
timestampWhen the alert fired.
trigger_typeThe trigger that produced the alert.
domainThe domain the alert fired on.
target_typeWhat target holds, either URL or HASH.
targetThe subject of the alert: a script URL or a script hash.
actionThe action recorded for the alert.
ruleset_idID of the ruleset that matched.
ruleset_nameName of the ruleset that matched.
script_url_1, script_url_2, script_url_3The first three triggering script URLs. A fourth or later URL is not exported.
vuln_cve_idCVE ID, for vulnerability alerts.
vuln_packageAffected package.
vuln_versionAffected version.
vuln_severityReported severity.
vuln_reference_urlReference 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 different file

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.

Was this page helpful?