scc_findings_mail — version 1.0
Source: presets
Purpose
Security Command Center findings, delivered to a mailbox — the answer to "who gets told", for a customer who has no SIEM reading the topic.
NEEDS presets: this fragment attaches to the topic
that pack creates and takes the same project. Used without it, the compile stops
with unknown param 'scc_notification_project'.
WHAT THE MAIL SAYS. "Security Command Center published findings", with the count and a link to the alert — not the finding itself. Cloud Monitoring alerts on a metric, and the metric here is how many messages reached the topic; the finding's text lives in the topic, in the console and in the BigQuery export. A customer who wants the finding in the body of the mail needs code — a subscriber that formats it — and code is not a resource, so it is not in this library.
THREE RESOURCES.
- a subscription on the topic, because a topic with no subscription drops every message it receives: the findings would be published to nothing. It keeps seven days, so a Friday finding survives the weekend;
- an e-mail notification channel;
- an alert policy that fires when messages reach the topic at all.
The mailbox must exist and accept mail from alerting-noreply@google.com. A group
whose members have no mailboxes drops every alert and nothing in the estate can
see that happening — a group, never a person, because people leave.
NO CLAIM. No catalog control covers Security Command Center, so this pack witnesses nothing.
Use it
params {
// the pack's own defaults — copy only the lines you change
scc_findings_email = cis_central_email
scc_findings_subscription_name = "{customer_shortname}-scc-findings-retain"
scc_findings_retention = "604800s"
scc_findings_channel_name = "SCC findings"
scc_findings_alert_window = "300s"
}
use "presets/scc/scc-findings-mail.satz"
Needs from outside the pack:
cis_central_email— declared bymonitoring; use one of them alongside, or declare it in the estate..organization _cis _log _alerts _central customer_shortname— declared byestate_core; use one of them alongside, or declare it in the estate.scc_notification_project— declared byscc_notifications; use one of them alongside, or declare it in the estate.
Params
| param | default |
|---|---|
scc_findings_email |
cis_central_email |
scc |
"{customer |
scc_findings_retention |
"604800s" |
scc_findings_channel_name |
"SCC findings" |
scc_findings_alert_window |
"300s" |
Questions
What to ask before this pack is configured, and what changing the answer costs.
| asks about | prompt | reversal | blast | recommends |
|---|---|---|---|---|
scc_findings_email |
Where should Security Command Center findings be delivered — the mailbox that is told a finding arrived | edit | high | — |
scc_findings_email — The mail says findings were published and links to them; the finding itself stays in the topic, the console and the export. The mailbox must exist and accept mail from alerting-noreply@google.com — a group whose members have no mailbox drops every alert silently. A group, never a person. The default is the address the organisation's CIS alerts already go to.
Contributes
| resource type | labels |
|---|---|
google |
scc_findings_published |
google |
scc_findings_mail |
google_pubsub_subscription |
scc_findings |
Claims
None — this pack proves no control by itself.
History
| version | date | change |
|---|---|---|
| 1.0 | 2026-09-12 | first version: who gets told, for an organisation with no SIEM on the topic — a subscription (a topic without one drops every message), an e-mail channel and an alert policy that fires when findings reach the topic. Asks the address; its default is the central alert pack's cis_central_email by reference, and without that pack the compile stops rather than mailing a guessed address. The mail says findings arrived and links to them: the finding's text stays in the topic, the console and the export |
The whole library's history: the changelog in presets/CHANGELOG.md.
Notes
No notes yet.