# Security Alerting Digest

- Public routes: 12
- Gates: 5
- Blocked gates: 3
- Alert outbox: 0
- Feed smoke ok: 1
- Severity policies: 4
- Escalation steps: 5
- Dry-run drills: 5
- Impact triage: 4
- Communication templates: 4
- Receiver contract controls: 5
- Scheduled scan plans: 4
- Routing matrix rows: 4
- Schedule acceptance criteria: 5
- Canary activation steps: 6
- Retention reviews: 5
- Kill-switch rollback steps: 5
- Delivery signoff receipt items: 6
- Receiver approval rows: 5
- Delivery pause policies: 5
- Delivery incident drill steps: 5
- Parity acceptance: 3/6 ready, blocked 3
- Parity closure plan: 0/3 done, waiting 3
- Alerting claim lane: 2/5 public-ready, gated 1, blocked-live 2
- Security alert drill evidence: 4/6 passed, blocked 2

## Operator actions
- **hoch** IT/Security: Feed-Credentials nur serverseitig setzen; danach Credential-Preflight und Security-Feed-Smoke erneut ausführen. (https://saferpage.de/sicherheit/feed-credential-preflight-json?host=anrufer.info)
- **hoch** DB-Owner/Datenschutz: Storage-Migration, Retention-Entscheidung und Storage-Canary vor echten Feed-Treffern abschließen. (https://saferpage.de/sicherheit/feed-storage-readiness-json)
- **hoch** Delivery Owner: Webhook/Slack/Teams/Jira/E-Mail-Zielsysteme mit HMAC, Idempotency und Empfängerfreigabe prüfen. (https://saferpage.de/integrationen/delivery-credential-preflight-json)
- **mittel** Programm-Owner: Launch-Board, Operator-Go-live und beide No-Secret-Smokes als Go/No-Go-Abnahme verwenden. (https://saferpage.de/sicherheit/feed-launch-board-json)

## Severity SLA
- **critical** 15 Minuten nach bestätigtem Treffer: Malware, Phishing, aktive Blocklist oder kompromittierter Download mit hoher Sicherheit. Owner: Security Lead
- **high** 4 Stunden innerhalb der Betriebszeit: Verdächtige Drittanbieter, neue riskante Weiterleitung oder sicherheitsrelevante Header-/TLS-Verschlechterung. Owner: Webbetrieb/Security
- **medium** 2 Arbeitstage: Neue Privacy-/Security-Warnung ohne akute Blocklist-Bestätigung. Owner: Datenschutz/Webbetrieb
- **low** 30 Tage: Hygiene-, Dokumentations- oder Verbesserungshinweis ohne akuten Schaden. Owner: Programm-Owner

## Escalation
- 1. Triage - innerhalb der Severity-SLA (https://saferpage.de/sicherheit/anrufer.info/alerts-json)
- 2. Owner-Ack - nach Triage sofort dokumentieren (https://saferpage.de/betreiber/go-live-json)
- 3. Containment - critical sofort, high am selben Arbeitstag (https://saferpage.de/fix-guides/anrufer.info)
- 4. Datenschutz-/Legal-Review - bei Personenbezug oder Meldepflichtverdacht unverzueglich (https://saferpage.de/risiko/anrufer.info)
- 5. Closeout und Re-Scan - nach Fix oder Entscheidung (https://saferpage.de/anrufer.info)

## Dry-run drills
- **No-Secret-Smokes ausführen**: failed_check_count=0, blocked_expected_count transparent. (https://saferpage.de/evidence/alert-delivery-readiness-smoke.json)
- **Dry-run-Dispatch prüfen**: Keine externe Zustellung, keine echten Empfänger, keine Ziel-URLs im Public Export. (https://saferpage.de/alarme/dispatch-runner-json)
- **Critical-Alert-Tabletop**: Triage, Ack, Containment, Datenschutzreview und Closeout zeitlich durchgespielt. (https://saferpage.de/sicherheit/alerting-digest-json)
- **Receiver-Vertrag validieren**: HMAC, Idempotency, Retry, Dedupe und Approval-Gate dokumentiert. (https://saferpage.de/integrationen/delivery-credential-preflight-json)
- **Go/No-Go festhalten**: Produktivblocker, Verantwortliche und nächster Freigabeschritt sichtbar. (https://saferpage.de/betreiber/go-live-json)

## Impact triage
- **Besucherrisiko**: Können Besucher durch die Website auf Malware, Phishing, betruegerische Weiterleitungen oder kompromittierte Downloads treffen? Entscheidung: Bei bestätigtem Risiko sofort technische Eindämmung, sichtbaren Hinweis und Re-Scan planen. (https://saferpage.de/sicherheit/anrufer.info/alerts-json)
- **Personenbezug und Datenschutz**: Kann der Treffer personenbezogene Daten, Tracking, Formulare, Loginbereiche oder Drittanbieter mit Personenbezug betreffen? Entscheidung: Datenschutz/Legal bewertet DSFA-, Breach- und Kommunikationspflichten. (https://saferpage.de/risiko/anrufer.info)
- **Betriebsfähigkeit**: Beeinflusst der Treffer zentrale Kontakt-, Checkout-, Termin-, Bewerbungs- oder Supportfunktionen? Entscheidung: Business Owner bestätigt Workaround, Prioritaet und Kundenauswirkung. (https://saferpage.de/agentur/anrufer.info/deepscan-json)
- **Regulatorisches Signal**: Gibt es Hinweise auf NIS2-, Datenschutz-, Branchen- oder Meldepflichtrelevanz? Entscheidung: Meldepflichtverdacht frueh im Legal-/Security-Review dokumentieren. (https://saferpage.de/nis2/anrufer.info/export)

## Communication templates
- **Interne Erstmeldung** für Security, Datenschutz, Webbetrieb: [SaferPage] Security-Alert für anrufer.info - Triage erforderlich (https://saferpage.de/sicherheit/alerting-digest-json?host=anrufer.info)
- **Provider-/Agentur-Eskalation** für Hosting, Agentur, CMS-/Shop-Dienstleister: Bitte Security-Hinweis für anrufer.info prüfen (https://saferpage.de/fix-guides/anrufer.info/tickets)
- **Besucherhinweis-Entwurf** für Website-Besucher: Sicherheitshinweis zu anrufer.info (https://saferpage.de/sicherheit/anrufer.info)
- **Abschlussnotiz** für Programm-Owner, Datenschutz, Security: [SaferPage] Security-Alert für anrufer.info abgeschlossen (https://saferpage.de/anrufer.info)

## Receiver contract
- **HMAC-Signatur**: Jede produktive Zustellung muss eine serverseitige Signatur oder gleichwertige Authentisierung nutzen.
- **Idempotency-Key**: Receiver dedupliziert identische Alerts und bestätigt Wiederholungen ohne Doppel-Tickets.
- **Retry und Backoff**: Retries sind begrenzt, jittered und erzeugen keine Alert-Flut.
- **Empfängergrenze**: Public Exports enthalten Rollen und Zwecke, aber keine echten E-Mail-Adressen, Webhooks oder Tokens.
- **Ack/Closeout**: Receiver liefert Ack, Statuswechsel und Closeout-Referenz für Audit und Re-Scan.

## Scheduled scans
- **Taegliche registrierte Domain-Prüfung**: täglich nach Betreiberfreigabe, Scope: registrierte Betreiber-Domains mit aktivem Feed-/Storage-/Delivery-Gate, Evidence: https://saferpage.de/sicherheit/feed-runner-json
- **Schneller Re-Check bei kritischem Treffer**: innerhalb 60 Minuten nach Eindämmung, Scope: betroffene Domain und direkt verlinkte Nachweise, Evidence: https://saferpage.de/anrufer.info
- **Woechentlicher Rollen-Digest**: woechentlich, Scope: alle offenen Security-/Privacy-Hinweise nach Rolle, Evidence: https://saferpage.de/sicherheit/anrufer.info/alerts-json
- **Monatliches Evidence-Archiv**: monatlich, Scope: Smokes, Launch-Board, Runner-State, Badge, Report und Go-live-Entscheidung, Evidence: https://saferpage.de/evidence-hub-json

## Alert routing
- **critical**: Security Lead / Datenschutz/Legal - Webhook/Slack/Teams plus E-Mail nur nach Delivery-Freigabe, public=role_only
- **high**: Webbetrieb/Security / Programm-Owner - Rollen-Digest und Zielsystem nach Freigabe, public=role_only
- **medium**: Datenschutz/Webbetrieb / Programm-Owner - Wochen-Digest, public=role_only
- **low**: Programm-Owner / Webbetrieb - Monatsreport, public=role_only

## Schedule acceptance
- [ ] Daily, critical re-check, weekly digest and monthly archive cadences are visible in JSON/CSV/Markdown. (https://saferpage.de/sicherheit/alerting-digest-json)
- [ ] Daily feed runner remains gated until credentials, storage approval and no-secret smokes are green. (https://saferpage.de/betreiber/go-live-json)
- [ ] Routing matrix publishes roles and policies only, not real recipients or webhook URLs. (https://saferpage.de/sicherheit/anrufer.info/alerts-json)
- [ ] Retry/backoff and escalation are documented before external delivery is activated. (https://saferpage.de/integrationen/delivery-credential-preflight-json)
- [ ] Critical alerts have a fast re-check path after containment and closeout. (https://saferpage.de/sicherheit/alerting-digest-json)

## Canary activation
- **Fixture / Security Lead**: Einen synthetischen, nicht öffentlichen Canary-Indikator mit Testdomain, Test-Hash und erwarteter Severity definieren. Status: ready_blueprint (https://saferpage.de/sicherheit/feed-storage-canary-json)
- **Storage / DB-Owner/Datenschutz**: Canary nur nach Migration, Retention-Review und Storage-Approval schreiben; keine echten Feed-Treffer verwenden. Status: blocked_until_storage_approval (https://saferpage.de/sicherheit/feed-storage-canary-json)
- **Routing / Delivery Owner**: Canary-Alert durch Routing-Matrix, Rollen-Digest, Idempotency und Dedupe laufen lassen, aber nicht extern senden. Status: ready_blueprint (https://saferpage.de/sicherheit/anrufer.info/alerts-delivery-json)
- **Receiver / Integration Owner**: Receiver nur gegen lokalen Sink/Testticket prüfen; HMAC, Retry, Ack und Closeout ohne echte Ziel-URL validieren. Status: blocked_until_delivery_approval (https://saferpage.de/alarme/dispatch-runner-json)
- **Audit / Programm-Owner**: Canary aus Evidence-Link, Alert-ID, Manifest, Ack, Closeout und Re-Scan rekonstruieren. Status: ready_blueprint (https://saferpage.de/evidence/security-feed-readiness-smoke.json)
- **Go/No-Go / Security/Datenschutz/Delivery**: Produktiven Tageslauf erst freigeben, wenn Feed, Storage, Delivery, Retention, Rollback und Smokes abgenommen sind. Status: blocked_until_all_gates_green (https://saferpage.de/betreiber/go-live-json)

## Retention review
- **Public Evidence**: nur sanitisierte Status-, Hash- und Rollenfelder Review: monatlich. alte Evidence archivieren, keine Rohpayloads nachziehen
- **Canary Observation**: kurzlebiger Testdatensatz bis Abnahme plus Auditnotiz Review: nach jedem Canary-Lauf. nach Closeout löschen oder als synthetischen Nachweis markieren
- **Bestätigter Alert**: nach Betreiber-Policy und Legal-Review Review: bei Severity high/critical sofort. nach Fix und Re-Scan minimieren, personenbeziehbare Daten entfernen
- **Delivery Event**: Ack, Idempotency-Key und Status ohne Secret oder Empfängerwert Review: woechentlich im Pilot. fehlgeschlagene Zielsystemdaten bereinigen, keine Webhook-URLs speichern
- **Besucher-/Viewer-Grenze**: keine Besucherlogs, keine IPs, keine Roh-HARs im Public Digest Review: bei jedem neuen Exportfeld. Export stoppen, wenn personenbezogene Rohdaten auftauchen

## Kill-switch rollback
- **Feed-Runner stoppen**: unerwarteter externer Feed-Call, Fehlerquote oder falscher Scope -> Timer deaktivieren, Queue einfrieren, Runner-State sichern und Dry-run-Smoke erneut ausführen.
- **Storage-Write sperren**: Retention unklar, Migration fehlerhaft oder Observation enthält unerwartete Rohdaten -> Storage-Approval zurücknehmen, Write-Flag sperren, Canary/Observation isolieren und DB-Owner einbinden.
- **Dispatch stoppen**: falscher Empfänger, fehlende HMAC-Prüfung oder Zielsystemfehler -> SAFERPAGE_ALERT_DISPATCH_APPROVED deaktivieren, Outbox halten, Idempotency-Key sperren und Receiver informieren.
- **Alert neu klassifizieren**: False Positive, falsche Severity oder fehlende Quelle -> Severity zurückstufen, Kommentar und Evidence-Link schreiben, Kommunikation stoppen und Re-Scan planen.
- **Public Export einfrieren**: Secret, Empfänger, private URL, Besucherlog oder Rohpayload im Export entdeckt -> Route aus Nginx/PHP blockieren, Evidence neu erzeugen, Forbidden-Pattern-Smoke ausführen und Ursache dokumentieren.

## Delivery signoff receipt
- **Receiver Owner bestätigt** (required_before_dispatch): Rolle, Zielsystem, Zweck und Eskalationskontakt sind intern dokumentiert; Public Export zeigt nur Rollen. Owner: Delivery Owner
- **HMAC und Idempotency abgenommen** (required_before_dispatch): https://saferpage.de/integrationen/delivery-credential-preflight-json Owner: Integration Owner
- **Empfängergrenze geprüft** (required_before_dispatch): Keine E-Mail-Adressen, Webhook-URLs, Tokens oder private Zielsystempfade in Public Evidence. Owner: Datenschutz/Legal
- **Dry-run-Receipt vorhanden** (required_before_dispatch): https://saferpage.de/evidence/alert-delivery-readiness-smoke.json Owner: Webbetrieb
- **Rollback Owner benannt** (required_before_dispatch): Kill-Switch, Outbox-Hold, Receiver-Info und Re-Enable-Entscheidung sind einem Owner zugeordnet. Owner: Programm-Owner
- **First-live-Watch geplant** (required_before_dispatch): Erster produktiver Alert wird eng auf Ack, Retry, Dedupe, Severity und Empfängergrenze beobachtet. Owner: Security Lead

## Receiver approval matrix
- **webhook**: HMAC, TLS, IP-/Auth-Policy, Idempotency und Dedupe im Zielsystem abgenommen Public boundary: keine Webhook-URL, kein Token, kein Secret Fallback: local sink / Outbox Hold
- **slack**: App/Bot oder Incoming Webhook nur serverseitig, Channel Owner und Retention geprüft Public boundary: nur Rollenname, kein Channel, kein Webhook Fallback: Rollen-Digest
- **teams**: Connector/Workflow signiert oder serverseitig geschützt, Owner und Retry-Regeln bestätigt Public boundary: kein Tenant-/Webhook-Pfad Fallback: Rollen-Digest
- **jira_ticket**: Projekt, Issue-Type, Dedupe-Feld, Priority-Mapping und Closeout-Status getestet Public boundary: keine Projekt-Keys mit privatem Kontext Fallback: manuelles Ticket mit Evidence-Link
- **email**: Nur Rollenverteiler oder Betreiberziel nach Freigabe, keine Besucher- oder Rohpayloaddaten Public boundary: keine echten Empfängeradressen Fallback: monatlicher Report/Digest

## Delivery pause policy
- **recipient_bounce_or_4xx**: Kanal pausieren, Owner benachrichtigen, Outbox halten und keine alternativen Empfänger raten. Resume: Receiver Owner bestätigt Ziel, HMAC/Dedupe erneut getestet.
- **retry_storm_or_429**: Backoff erhöhen, Dispatch-Gate deaktivieren und Dry-run-Smoke ausführen. Resume: Retry-After/Rate-Limit-Verhalten im Zielsystem bestätigt.
- **wrong_severity_or_duplicate**: Alert neu klassifizieren, Dedupe-Key prüfen, bestehendes Ticket aktualisieren statt neu zu senden. Resume: Severity-Mapping und Dedupe-Feld korrigiert.
- **secret_or_recipient_leak_detected**: Public Export einfrieren, Dispatch stoppen, Evidence neu erzeugen und Forbidden-Pattern-Smoke ausführen. Resume: Leak entfernt, Ursache dokumentiert, Smoke grün.
- **operator_revokes_approval**: SAFERPAGE_ALERT_DISPATCH_APPROVED entfernen, Zielsysteme nicht mehr ansprechen, Rollen-Digest behalten. Resume: Neue Betreiberfreigabe und aktueller No-Secret-Smoke.

## Delivery incident drill
- 1. **Canary-Alert vorbereiten**: Synthetischer Alert nutzt Testdomain/Test-ID und keine externen Feed-Rohdaten. (https://saferpage.de/sicherheit/feed-storage-canary-json)
- 2. **Receiver-Dry-run ausführen**: Payload, HMAC, Idempotency und Dedupe werden gegen lokalen Sink oder Testticket geprüft. (https://saferpage.de/alarme/dispatch-runner-json)
- 3. **Ack und Eskalation simulieren**: Owner-Ack, Severity-SLA, Datenschutzreview und Closeout werden ohne echte Empfänger dokumentiert. (https://saferpage.de/sicherheit/alerting-digest-json?host=anrufer.info)
- 4. **Pause testen**: Dispatch-Gate lässt sich entfernen; Outbox sendet nicht extern; Rollback-Owner bestätigt. (https://saferpage.de/betreiber/go-live-json)
- 5. **Re-Enable entscheiden**: Freigabe erfolgt nur nach grünem Alert-Delivery-Smoke und Receiver-Approval. (https://saferpage.de/evidence/alert-delivery-readiness-smoke.json)

## Parity acceptance
- **Tägliche Security-Scans** (blocked_expected): Feed-Credentials, Storage-Approval, Timer, Retention und No-Secret-Smoke sind grün. Entscheidung: Produktiv erst nach serverseitigen Feed-Credentials und Storage-Freigabe aktivieren. (https://saferpage.de/sicherheit/feed-launch-board-json)
- **Automatische Benachrichtigung bei kritischen Treffern** (blocked_expected): Receiver-Approval, HMAC/Idempotency, Zielsystemfreigabe, Pause Policy und Alert-Delivery-Smoke sind grün. Entscheidung: Externe Zustellung bleibt blockiert; Rollen-Digest und Dry-run reichen bis zur Freigabe. (https://saferpage.de/integrationen/delivery-credential-preflight-json)
- **Security-Report, Badge und öffentliche Nachweise** (ready_blueprint): Kurzreport, Security Evidence Index, Badge, Smoke-Evidence und Claim-Grenze sind öffentlich verlinkt. Entscheidung: Als öffentlicher Statusnachweis nutzbar, solange er keine Zertifizierung oder Live-Monitoring ohne Freigabe behauptet. (https://saferpage.de/security-evidence-json)
- **Canary vor Live-Betrieb** (blocked_expected): Synthetischer Canary schreibt keine echten Feed-Treffer, sendet keine Alerts und ist im Audit rekonstruierbar. Entscheidung: Canary bleibt bis Storage-Approval blockiert. (https://saferpage.de/sicherheit/feed-storage-canary-json)
- **Closeout, Re-Scan und Betreiberkommunikation** (ready_blueprint): Ack, Owner, Datenschutz-/Legal-Review, Containment, Re-Scan und Closeout-Notiz sind als Ablauf vorhanden. Entscheidung: Ablauf ist als Betreiber-Runbook verwendbar; echte Incident-Kommunikation bleibt Betreiberentscheidung. (https://saferpage.de/sicherheit/alerting-digest-json?host=anrufer.info)
- **Keine Produktivbehauptung ohne Freigabe** (passed): Digest, Smokes und Go-live-Center nennen Blocker und Grenzen sichtbar. Entscheidung: Öffentlich nur Readiness und Grenzen behaupten, bis Betreiberfreigaben, Secrets und Zielsysteme aktiv sind. (https://saferpage.de/vergleich/aktionsplan-json)

## Parity-Schließplan
### Feed-Credentials serverseitig freigeben
- Status: waiting_for_operator_secret
- Owner: IT/Security
- Schaltet frei: ["tägliche registrierte Domain-Prüfung","URLhaus-/Safe-Browsing-Abgleich","Security-Feed-Runner"]
- Betreiberinput: URLhaus-/Safe-Browsing-Keys als Server-Secrets setzen, Rotation dokumentieren und Credential-Preflight erneut ausführen.
- Abnahme: ["ready_for_external_feed_run=true","missing_required_secret_reference_count=0","external_probe_executed nur nach Freigabe"]
- Wettbewerbswirkung: Schließt den Abstand zu Scannern mit wiederkehrender Malware-/Blocklist-Prüfung, ohne Feed-Keys offenzulegen.
- Nicht behaupten bis erledigt: Keine produktive Malware-, Safe-Browsing- oder tägliche Feed-Abfrage behaupten.
- Evidence: https://saferpage.de/sicherheit/feed-credential-preflight-json?host=anrufer.info
### Feed-Storage, Retention und Canary freigeben
- Status: waiting_for_storage_approval
- Owner: DB-Owner/Datenschutz
- Schaltet frei: ["Observation-Historie","Canary vor Live-Betrieb","Review-/Suppress-/Retention-Audit"]
- Betreiberinput: Migration ausführen, Retention/DPIA-Kontrollen bestätigen, Storage-Canary trocken prüfen und Rollback-Rehearsal dokumentieren.
- Abnahme: ["ready_for_write=true","missing_database_artifact_count=0","Canary schreibt nur synthetische Testindikatoren"]
- Wettbewerbswirkung: Macht wiederkehrende Befunde auditierbar wie bei Monitoring-Produkten, ohne Rohpayloads oder Besucherlogs zu publizieren.
- Nicht behaupten bis erledigt: Keine gespeicherten Feed-Observations, historischen Malware-Treffer oder Canary-Live-Läufe behaupten.
- Evidence: https://saferpage.de/sicherheit/feed-storage-readiness-json
### Receiver-Approval und Dispatch-Freigabe abschließen
- Status: waiting_for_receiver_approval
- Owner: Delivery Owner
- Schaltet frei: ["automatische Benachrichtigung","Ack/Closeout im Zielsystem","First-live-Watch"]
- Betreiberinput: Zielsysteme intern freigeben, HMAC/Idempotency/Dedupe prüfen, Pause Policy bestätigen und Dispatch-Approval setzen.
- Abnahme: ["SAFERPAGE_ALERT_DISPATCH_APPROVED=yes","Receiver prüft HMAC und Idempotency","keine echten Empfänger im Public Export"]
- Wettbewerbswirkung: Schließt die Lücke zu automatischen Schwachstellen-Benachrichtigungen, ohne Webhooks, Tokens oder Empfänger zu veröffentlichen.
- Nicht behaupten bis erledigt: Keine automatische externe Alert-Zustellung, Slack-/Teams-/Jira-Tickets oder E-Mail-Alerts behaupten.
- Evidence: https://saferpage.de/integrationen/delivery-credential-preflight-json

## Security-Alerting-Claim-Lane
Security-/Alerting-Claims für Betreiberkommunikation: belegbare Readiness zeigen, geplante Scans gated formulieren und produktive Monitoring-/Delivery-Claims bis Feed-, Storage- und Receiver-Freigabe sperren.
> Diese Claim-Lane ist eine Kommunikationsfreigabe, kein Produktivbetrieb. Sie setzt keine Feed-Secrets, ruft keine externen Feeds auf, speichert keine echten Observations und sendet keine Alerts.
### Security-Evidence und Alerting-Readiness
- Status: public_ready
- Erlaubte Aussage: Betreiber können Security-Evidence, Alert-Digest, Rollenrouting, SLA, Dry-run und Go-live-Gates als öffentliche Readiness zeigen.
- Betreiberinput: Geprüften Host, Evidence-Routen, Rollenmodell und Claim-Grenze freigeben.
- Nicht behaupten: Nicht behaupten: laufende externe Malware-/Safe-Browsing-Feeds, gespeicherte Live-Observations oder automatische Zustellung.
- Abnahme: Alerting-Digest, Security-Evidence-Index und Go-live-Center sind öffentlich erreichbar.
- Abnahme: Security- und Delivery-Smokes laufen ohne failed_check_count.
- Abnahme: Public Exports zeigen keine Empfänger, Webhook-URLs, Tokens, Rohpayloads oder Besucherlogs.
- Evidence: ["https://saferpage.de/sicherheit/alerting-digest-json?host=anrufer.info","https://saferpage.de/security-evidence-json","https://saferpage.de/betreiber/go-live-json"]
### Geplante Security-Scans
- Status: gated_readiness
- Erlaubte Aussage: SaferPage kann geplante Security-Scan-Abläufe, Canaries, Retention-Review und Rollback als Betreiber-Blueprint zeigen.
- Betreiberinput: Feed-Credentials, Storage-Approval, Retention-Regeln und Canary-Freigabe setzen.
- Nicht behaupten: Nicht behaupten: tägliche externe Feed-Abfrage, produktive Malware-Historie oder gespeicherte echte Feed-Treffer.
- Abnahme: Credential-Preflight zeigt erforderliche Secret-Refs ohne Secret-Ausgabe.
- Abnahme: Storage-Readiness und Canary-Freigabe sind abgenommen.
- Abnahme: Runner bleibt bis Freigabe guarded und speichert keine echten Observations.
- Evidence: ["https://saferpage.de/sicherheit/feed-credential-preflight-json?host=anrufer.info","https://saferpage.de/sicherheit/feed-storage-readiness-json","https://saferpage.de/sicherheit/feed-runner-json","https://saferpage.de/sicherheit/feed-storage-canary-json"]
### Alert-Zustellung und Receiver-Approval
- Status: blocked_live
- Erlaubte Aussage: Nur als Delivery-Preflight kommunizieren: Receiver-Vertrag, HMAC, Idempotency, Pause Policy und Incident-Drill sind vorbereitet.
- Betreiberinput: Zielsysteme, Empfängergruppen, HMAC-Secret, Dispatch-Approval und Stop-Bedingungen freigeben.
- Nicht behaupten: Nicht behaupten: produktive Webhook-/Slack-/Teams-/Jira-/E-Mail-Zustellung oder aktive Empfänger.
- Abnahme: Delivery-Preflight und Alert-Delivery-Smoke sind grün.
- Abnahme: Receiver-Approval-Matrix und Signoff-Receipt sind Betreiber-abgenommen.
- Abnahme: Public Export enthält keine Ziel-URLs, Empfänger, HMAC-Secrets oder Payload-Rohdaten.
- Evidence: ["https://saferpage.de/integrationen/delivery-credential-preflight-json","https://saferpage.de/evidence/alert-delivery-readiness-smoke.json","https://saferpage.de/alarme/dispatch-runner-json"]
### Alert-SLA, Eskalation und Betreiberworkflow
- Status: public_ready
- Erlaubte Aussage: SLA, Eskalationspfad, Impact-Triage, Betreibertexte und Dry-run-Drills sind als öffentliche Abnahmeakte verfügbar.
- Betreiberinput: Owner, Reaktionszeiten, Datenschutzreview und Closeout-Regeln gegen Betreiberpraxis prüfen.
- Nicht behaupten: Nicht behaupten: echte Incident-Bearbeitung, interne Tickets, personenbezogene Alert-Fälle oder externe Empfängerketten.
- Abnahme: Severity-Policy, Eskalation, Impact-Triage und Kommunikationsvorlagen sind vollständig.
- Abnahme: Dry-run beschreibt Ack, Containment, Datenschutzreview und Closeout.
- Abnahme: Betreibertexte bleiben generisch und enthalten keine Kundendaten oder echten Vorfälle.
- Evidence: ["https://saferpage.de/sicherheit/alerting-digest-json?host=anrufer.info","https://saferpage.de/evidence/alert-delivery-readiness-smoke.json","https://saferpage.de/vergleich/aktionsplan-json"]
### Produktive Security-Monitoring-Parität
- Status: blocked_live
- Erlaubte Aussage: Nur als Parity-Schließplan kommunizieren: Feed-Credentials, Storage/Retention und Receiver-Approval sind getrennte Betreiberfreigaben.
- Betreiberinput: Alle drei Schließplan-Freigaben signieren, Smokes erneut ausführen und ersten produktiven Lauf überwachen.
- Nicht behaupten: Nicht behaupten: vollständige Monitoring-Parität, Live-Alerts, externe Feed-Läufe oder automatische Security-Benachrichtigung.
- Abnahme: Parity-Closure-Plan steht auf done für Feed-Credentials, Storage und Receiver-Approval.
- Abnahme: Go-live-Center gibt den Security-/Delivery-Claim frei.
- Abnahme: First-live-Watch, Kill-Switch und Rollback sind Betreiber-abgenommen.
- Evidence: ["https://saferpage.de/sicherheit/alerting-digest-json?host=anrufer.info","https://saferpage.de/sicherheit/feed-launch-board-json","https://saferpage.de/betreiber/go-live-json"]

## Security Alert Drill Evidence
No-Secret-Drill für Security-Feed und Alert-Zustellung: öffentlich belegbare Readiness, erwartete Produktivblocker und klare Nicht-Claims vor Live-Monitoring.
### Security-Feed-Smoke ohne Fehler
- Status: passed
- Betreiberinput: Feed-Smoke nach jeder Änderung an Credential-, Storage- oder Runner-Gates erneut ausführen.
- No-Secret-Grenze: Public Evidence zeigt nur Status, Zähler, Rollen und sichere Env-Refs, keine Feed-Keys oder Rohpayloads.
- Abnahme: ["ok=true","failed_check_count=0","blocked_expected_count bleibt sichtbar"]
- Stop: ["failed_check_count > 0","Secret-/Payload-Feld im Export","unerwarteter externer Feed-Run"]
- Evidence: https://saferpage.de/evidence/security-feed-readiness-smoke.json
### Alert-Delivery-Smoke ohne Fehler
- Status: passed
- Betreiberinput: Delivery-Smoke nach jeder Zielsystem-, HMAC-, Receiver- oder Dispatch-Änderung erneut ausführen.
- No-Secret-Grenze: Public Evidence zeigt keine echten Empfänger, Webhook-URLs, Channel-Namen, Tokens oder Payload-Rohdaten.
- Abnahme: ["ok=true","failed_check_count=0","dry_run_sent_count=0"]
- Stop: ["sent_count > 0 ohne Approval","Ziel-URL im Public Export","Empfänger oder Token sichtbar"]
- Evidence: https://saferpage.de/evidence/alert-delivery-readiness-smoke.json
### Runtime-Control-Manifeste für Feed und Delivery grün
- Status: passed
- Betreiberinput: Execute-, Storage-, Dispatch-, HMAC-, Dry-run- und No-Secret-Gates als verpflichtende Runtime-Kontrollen beibehalten.
- No-Secret-Grenze: Manifeste dürfen Kontrollnamen und sichere Referenzen zeigen, aber keine Secret-Werte, privaten Zielsysteme oder Besucherlogs.
- Abnahme: ["Feed controls ok","Delivery controls ok","missing_control_count=0"]
- Stop: ["Runtime-Control fehlt","No-Secret-Policy rot","Direkter Execute-Pfad ohne Gate"]
- Evidence: https://saferpage.de/evidence-hub-json
### Feed-Runs und Observation-Storage bis Betreiberfreigabe blockiert
- Status: blocked_expected
- Betreiberinput: Feed-Credentials, Storage-Migration, Retention-Review und synthetischen Canary erst intern freigeben.
- No-Secret-Grenze: Bis zur Freigabe keine produktive Malware-/Safe-Browsing-Abfrage, keine gespeicherten echten Observations und keine Malware-Frei-Aussage.
- Abnahme: ["ready_for_external_feed_run=true","ready_for_write=true","Canary erfolgreich ohne Rohpayloads"]
- Stop: ["missing_required_secret_reference_count > 0","storage_approved=false","Canary schreibt echten Feed-Treffer"]
- Evidence: https://saferpage.de/sicherheit/feed-launch-board-json
### Externe Alert-Zustellung bis Receiver-Approval blockiert
- Status: blocked_expected
- Betreiberinput: Receiver, Empfängergruppe, HMAC, Idempotency, Pause Policy und First-live-Watch privat freigeben.
- No-Secret-Grenze: Bis zur Freigabe keine automatische Slack-/Teams-/Jira-/Webhook-/E-Mail-Zustellung behaupten.
- Abnahme: ["SAFERPAGE_ALERT_DISPATCH_APPROVED=yes","Receiver prüft HMAC/Idempotency","Alert-Delivery-Smoke bleibt grün"]
- Stop: ["native_ready_channel_count=0","dispatch_approved=false","Public Export enthält Empfänger oder Ziel-URL"]
- Evidence: https://saferpage.de/integrationen/delivery-credential-preflight-json
### Claim-Grenze für Wettbewerbs-Parity sichtbar
- Status: passed
- Betreiberinput: Öffentlich nur Readiness, Gates, Signoff-Pfad und Grenzen kommunizieren, bis Feed, Storage und Receiver freigegeben sind.
- No-Secret-Grenze: Kein Live-Monitoring-, Zertifizierungs-, Malware-Clean-, Safe-Browsing-Clean- oder Zustellungsclaim ohne Operator-Signoff.
- Abnahme: ["Claim-Lane vorhanden","Parity-Closure-Plan vorhanden","Nicht-behaupten-Grenzen je Freigabe sichtbar"]
- Stop: ["Live-Parity-Claim trotz blocked_expected","fehlende Nicht-Claims","fehlender Korrektur-/Go-live-Pfad"]
- Evidence: https://saferpage.de/sicherheit/alerting-digest-json?host=anrufer.info

## Claim boundary
Dieser Digest aggregiert öffentliche Readiness-Evidence. Er setzt keine Feed-Credentials, ruft keine externen Malware-/Safe-Browsing-Feeds auf, speichert keine echten Observations und sendet keine Alerts.