# Security-Feed-Launch-Board anrufer.info: Security-Feed-Launch ist blockiert; 4/7 Gate(s) offen. > Launch-Board aggregiert öffentliche Evidence-Pakete. Es ruft keine externen Malware-Feeds auf, speichert keine Treffer und veröffentlicht keine Secret-Werte. ## Letzter Security-Feed-Readiness-Smoke - Status: passed - Ziele: 17, Failed Checks: 0, Erwartete Blocker: 2 - Dry-run: externe Runs 0, gespeicherte Observations 0 - Evidence: https://saferpage.de/evidence/security-feed-readiness-smoke.json ## Gates - **Produktive Feed-Credentials**: blocked - anrufer.info: Security-Feed-Secrets mit 4 Secret-Referenz(en), 0 konfiguriert, 4 fehlend. Aktion: SAFERPAGE_URLHAUS_AUTH_KEY und SAFERPAGE_GOOGLE_SAFE_BROWSING_API_KEY serverseitig setzen und Rotation dokumentieren. - **Storage-Tabellen, Indizes und Trigger**: passed - Security-Feed-Storage ist noch nicht schreibbereit: 0 Datenbank-Artefakt(e) fehlen oder die Serverfreigabe ist nicht aktiv. Aktion: Keine Aktion im Launch-Gate offen; weiterhin überwachen. - **Betreiberfreigabe für Speicherung**: blocked - Ohne Serverfreigabe bleibt Speicherung deaktiviert, selbst wenn Tabellen vorhanden sind. Aktion: SAFERPAGE_SECURITY_FEED_STORAGE_APPROVED=yes erst nach Retention-, Review- und Alert-Routing-Freigabe setzen. - **Signierte Delivery**: blocked - Signatursecret fehlt; Payloads bleiben Dry-Run. Aktion: SAFERPAGE_WEBHOOK_SECRET oder SAFERPAGE_OPERATOR_WEBHOOK_SECRET setzen und HMAC-Dry-Run dokumentieren. - **systemd Runner operational**: passed - Security-Feed-Runner: 50 Domain(s) geprüft, 0 aktivierungsbereit, 0 externe Feed-Run(s), 0 Observation(s) gespeichert, 5 durch Gates blockiert, 45 ohne Reportseite, 0 technische Fehler. Aktion: Keine Aktion im Launch-Gate offen; weiterhin überwachen. - **Keine ungeprüften externen Runs oder Speicherungen**: passed - Security-Feed-Runner: 50 Domain(s) geprüft, 0 aktivierungsbereit, 0 externe Feed-Run(s), 0 Observation(s) gespeichert, 5 durch Gates blockiert, 45 ohne Reportseite, 0 technische Fehler. Aktion: Keine Aktion im Launch-Gate offen; weiterhin überwachen. - **Launch-Aktivierung**: blocked - anrufer.info: Security-Feed-Aktivierung mit 5 Gate(s), 4 blockiert, Delivery ohne Secret. Aktion: Alle blockierten Activation-Gates nacheinander schließen und danach Einzeltest ausführen. ## Konsolidierungsstand und Grenzen - **Oeffentliche Security-Evidence** (erreicht): 8/8 Coverage-Punkte sind oeffentlich belegbar; passives Sicherheitsprofil, Badge, Delivery-Vertrag, Feed-Vertrag und Runner-Status sind verlinkt. Grenze: Oeffentliche Evidence ist kein Penetrationstest, kein Malwarefrei-Zertifikat und kein Nachweis ausgefuehrter externer Feed-Abfragen. Naechster Schritt: Coverage-Routen in Evidence-Health und Launch-Board weiter pruefen; Claims nur aus belegten Evidence-Paketen ableiten. - **Security-Feed-Go-live** (blockiert): 3/7 Launch-Gates passed; 4 Gate(s) blockieren externe Feeds, Speicherung oder Alerts. Grenze: Nicht behaupten: taegliche Malware-/Blacklist-/Phishing-Feeds laufen produktiv, solange Launch-Gates blockiert sind. Naechster Schritt: Credentials, Storage-Approval, Delivery-Signatur, Runner-Status und Aktivierung nacheinander schliessen; danach Smoke erneut veroeffentlichen. - **Dry-run- und No-Secret-Grenzen** (erreicht): Letzter Smoke: external_runs=0, stored_observations=0, failed_checks=0. Grenze: Smokes pruefen oeffentliche Verträge und Guardrails; sie starten keine echten Feed-Jobs, speichern keine echten Observations und versenden keine Alerts. Naechster Schritt: Nach jeder Änderung am Runner, Credential-Preflight oder Storage zuerst Dry-run-Smoke, dann Launch-Board-Smoke ausfuehren. - **Storage-Canary** (offen): Canary stored_observation_count=0; Storage ready=no. Grenze: Canary ist synthetisch und privat; er ersetzt keine externen Feed-Credentials und darf nie als echter Treffer erscheinen. Naechster Schritt: Nach Storage-Migration und Freigabe den synthetischen Canary kontrolliert ausfuehren. - **Wettbewerbs-Claims** (begrenzt): 3/7 Parity-Punkte sind ohne offenen Produktivblocker belegbar. Grenze: Nicht behaupten: automatische Security-Feeds, produktive Alerts oder Malwarefreiheit sind live, solange Parity-Punkte blockiert/offen sind. Naechster Schritt: Marketing-/Betreibertexte nur aus erlaubten Claim-Grenzen ableiten und blockierte Parity-Punkte im Go-live-Board offen zeigen. ## Strukturierte Claim-Grenzen - **Keine produktiven Daily-Feeds behaupten** Erlaubt: Security-Feed-Launch ist vorbereitet und no-secret belegbar. Nicht behaupten: Taegliche externe Malware-/Blacklist-/Phishing-Feeds laufen produktiv. Grund: Feed-Credentials, Storage-Approval, Runner-Aktivierung und Launch-Gates muessen zusammen passed sein. - **Kein Malwarefrei-Zertifikat** Erlaubt: Im belegten passiven Pruefumfang und in den freigegebenen Feeds wurden bestimmte Signale geprueft. Nicht behaupten: Die Domain ist garantiert malwarefrei oder sicher. Grund: Feeds sind Momentaufnahmen, koennen veraltet sein und brauchen Quellenfrische, Review und klare Scope-Grenzen. - **Keine produktive Alert-Zustellung ohne Secret/Freigabe** Erlaubt: Alert-Payloads, Receiver-Vertrag und HMAC-Blueprint sind vorbereitet. Nicht behaupten: Betreiber erhalten produktive Alerts. Grund: Echte Empfaenger, Webhook-URLs, HMAC-Secrets und Dispatch-Freigaben bleiben private Betreiber-Gates. - **Keine öffentliche Warnung ohne Review** Erlaubt: Ungeprüfte Feed-Treffer bleiben interne Observations mit Reviewstatus. Nicht behaupten: Ein Feed-Treffer beweist automatisch eine kompromittierte Website. Grund: False Positives durch alte URLs, CDN, Redirects, Fremdpfade oder Feed-Latenz muessen abgeglichen werden. - **Keine Secrets oder Rohpayloads veröffentlichen** Erlaubt: Oeffentliche Exporte zeigen Status, Referenzen, Hashes, Zähler und Evidence-Links. Nicht behaupten: Feed-Keys, Webhook-URLs, Rohpayloads, Malware-Samples oder personenbezogene Logs sind oeffentliche Evidence. Grund: Security-Feed-Evidence muss Betreiber und Endnutzer informieren, ohne Angriffs-, Secret- oder Datenschutzrisiken zu erzeugen. ## Wettbewerbs-Paritaet DACH-Security-Scanner mit Score, Siegel, täglicher Prüfung, Alarmierung, Malware-/Blacklist-/Phishing-/DAST-Signalen und vollständigem Sicherheitsbericht. - **Gesamtscore und vollständiger Sicherheitsbericht**: abgedeckt - DACH-Sicherheitsprofil mit TLS, Headern, Redirects, Cookies, Script-/Version-Signalen, Runbook, JSON/CSV/Markdown und Kurzreport-Verlinkung. Aktion: Security-Profil regelmäßig in Monitoring und Betreiber-Board prüfen. - **Öffentliches Siegel oder Badge mit Prüfstatus**: abgedeckt - Einbettbares Sicherheitsbadge mit Score, Nachweislinks, Badge-JSON und klarer Nicht-Zertifikat-Policy. Aktion: Badge nur mit korrekter Aussage einbetten und bei Score-Änderungen Re-Scan auslösen. - **Benachrichtigung bei kritischen Security-Befunden**: blockiert - Security-Alerts und Delivery-Payloads für Webhook, Slack, Teams, Jira und E-Mail sind erzeugbar; HMAC-Secret bleibt Launch-Gate. Aktion: Webhook-/Operator-Secret setzen und signierten Delivery-Dry-Run prüfen. - **Tägliche Malware-/Blacklist-/Phishing-Prüfung registrierter Domains**: blockiert - Schedule, systemd Runner, Credential-Preflight, Secret-Readiness, Storage-Plan und Launch-Board sind vorhanden; externe Feed-Runs bleiben bis Credentials/Freigabe gesperrt. Aktion: Credential-Preflight, Storage-Freigabe und blockierte Launch-Gates schließen. - **Trefferhistorie, Dedupe, Review und Auditlog**: blockiert - Storage-Vertrag, Retention, erlaubte/verbotene Felder, DB-Readiness und Approval-Dossier sind getrennt nachweisbar. Aktion: DDL-Migration anwenden und Storage-Freigabe erst nach Retention-/Review-Entscheidung setzen. - **Produktionsnaher Schreibpfad-Test ohne externe Feed-Abfrage**: offen - Privater Storage-Canary definiert synthetische Observation, Dedupe, Retention, Auditlog, verbotene Felder, eigene systemd-Unit mit Timer und letzten Runner-Status getrennt von echten Feed-Runs. Aktion: Storage-Canary-Timer prüfen, nach Tabellen-/Freigabe-Gate kontrolliert starten und Runner-State prüfen. - **Externe DAST-/DOM-XSS-/CMS-/Malware-Nachweise**: abgedeckt - Betreiber-Prüfplan mit Akzeptanzkriterien, Ownern und Exportlinks markiert externe Validierungen, die SaferPage nicht aus öffentlichem Scan behauptet. Aktion: Externe Prüfungen beauftragen oder Evidenz hochladen; SaferPage-Report danach gegen Re-Scan abgleichen. ## Security-Coverage 8/8 Security-Coverage-Punkte sind öffentlich belegbar; 5 produktive Feed-/Storage-/Delivery-Punkte warten auf sichere Secrets oder Freigaben. - **TLS, Security-Header und Redirect-Signale**: covered - DACH-Sicherheitsprofil exportiert TLS-/Header-/Security-Signale ohne externe Feed-Secrets. - **Score und Badge mit Claim-Grenzen**: covered - Sicherheitsbadge, Scorecard und Verifizierungsseiten sind öffentlich verlinkt. - **Security-Alerts und Delivery-Vertrag**: guarded_ready - Alert-Payloads, HMAC-Receiver-Vertrag, Idempotency und Delivery-Preflight sind vorhanden; echte Zustellung wartet auf Freigabe. - **Malware-/Blacklist-/Phishing-Feed-Vertrag**: guarded_ready - Feed-Evidence, Import-Preview, Live-Connector-Vertrag und Credential-Preflight sind vorhanden; externe Feed-Abfrage läuft nicht im Standard. - **Geplanter Feed-Runner mit Stop-Bedingungen**: covered - systemd Runner-State, Schedule, Dry-run-Drill, Go-live-Sequenz und Stop-Bedingungen sind öffentlich belegbar. - **Storage, Retention, Dedupe und Auditlog**: guarded_ready - Storage-Vertrag, Migration-SQL, Preflight, Readiness, Canary und Approval-Dossier sind getrennt belegbar. - **Externe DAST-/DOM-XSS-/CMS-Nachweise**: covered - Externer Prüfplan markiert, welche Nachweise Betreiber zusätzlich liefern oder beauftragen müssen. - **Go/No-Go-Freigabeakte**: guarded_ready - Launch-Board und Approval-Dossier bündeln Gates, Signoffs, Risiken, Environment-Vertrag und Evidence-Links ohne Secret-Ausgabe. ## Claim-Grenzen - SaferPage behauptet keine Malware-/Blacklist-Clean-Entscheidung ohne ausgeführte externe Feed-Connectoren. - Badge und Sicherheitsprofil sind öffentliche Prüfhinweise, kein Zertifikat und kein Penetrationstest. - Produktive Alerts, Feed-Speicherung und externe Feed-Abfragen benötigen explizite Betreiberfreigabe und Server-Secrets. ## Reihenfolge - DB-Owner Migration Package aus Storage-Readiness anwenden lassen. - Credential-Preflight prüfen und Feed-/Delivery-Secrets serverseitig ohne Secret-Ausgabe nachweisen. - Feed- und Delivery-Secrets serverseitig setzen; keine Secret-Werte veröffentlichen. - Storage-Freigabe erst nach Retention-/Review-/Alert-Routing-Entscheidung aktivieren. - Runner manuell starten, Launch-Board prüfen und erst dann Daily-Betrieb als produktiv markieren.