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-Launch
Ein Board für Secrets, DB, Runner und Betreiberfreigabe
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.
Konsolidierung
Was belegbar ist, was blockiert bleibt
Das Board trennt öffentliche Security-Evidence von echten Produktivläufen. So bleiben Konkurrenz-Claims verwertbar, ohne tägliche Feeds, Alerts oder Malwarefreiheit vor Go-live zu behaupten.
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.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.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.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.Claim-Grenzen
Erlaubte Aussagen statt überzogener Security-Versprechen
Diese Grenzen sind für Betreibertexte, Badges, Kurzreports und Vergleichsseiten maßgeblich.
Nicht behaupten: Taegliche externe Malware-/Blacklist-/Phishing-Feeds laufen produktiv.
Feed-Credentials, Storage-Approval, Runner-Aktivierung und Launch-Gates muessen zusammen passed sein.Nicht behaupten: Die Domain ist garantiert malwarefrei oder sicher.
Feeds sind Momentaufnahmen, koennen veraltet sein und brauchen Quellenfrische, Review und klare Scope-Grenzen.Nicht behaupten: Betreiber erhalten produktive Alerts.
Echte Empfaenger, Webhook-URLs, HMAC-Secrets und Dispatch-Freigaben bleiben private Betreiber-Gates.Nicht behaupten: Ein Feed-Treffer beweist automatisch eine kompromittierte Website.
False Positives durch alte URLs, CDN, Redirects, Fremdpfade oder Feed-Latenz muessen abgeglichen werden.Nicht behaupten: Feed-Keys, Webhook-URLs, Rohpayloads, Malware-Samples oder personenbezogene Logs sind oeffentliche Evidence.
Security-Feed-Evidence muss Betreiber und Endnutzer informieren, ohne Angriffs-, Secret- oder Datenschutzrisiken zu erzeugen.Letzter Smoke-Lauf
Security-Feed-Readiness ohne Secret- oder Feed-Ausführung
No-Secret-Smoke fuer Security-Feed-Launch-Board, Credential-Preflight, Storage-Readiness, Runner, Runtime-Kontrollen, Operator-Go-live und isolierten Dry-run.
Dieser Smoke setzt keine Feed-Credentials, ruft keine externen Malware-/Safe-Browsing-Feeds auf, speichert keine echten Observations, versendet keine Alerts und wendet keine Migration an.
Das Ergebnis enthält nur Zielstatus, Gate-Zähler und sanitisierten Dry-run-Status. Secret-Werte, Rohpayloads, Empfänger, private Ziele und Besucherlogs bleiben ausgeschlossen.
Security-Coverage
Was bereits öffentlich belegbar ist
8/8 Security-Coverage-Punkte sind öffentlich belegbar; 5 produktive Feed-/Storage-/Delivery-Punkte warten auf sichere Secrets oder Freigaben.
DACH-Sicherheitsprofil exportiert TLS-/Header-/Security-Signale ohne externe Feed-Secrets.
- Nachweis
- öffnen
Sicherheitsbadge, Scorecard und Verifizierungsseiten sind öffentlich verlinkt.
- Nachweis
- öffnen
Alert-Payloads, HMAC-Receiver-Vertrag, Idempotency und Delivery-Preflight sind vorhanden; echte Zustellung wartet auf Freigabe.
- Nachweis
- öffnen
Feed-Evidence, Import-Preview, Live-Connector-Vertrag und Credential-Preflight sind vorhanden; externe Feed-Abfrage läuft nicht im Standard.
- Nachweis
- öffnen
systemd Runner-State, Schedule, Dry-run-Drill, Go-live-Sequenz und Stop-Bedingungen sind öffentlich belegbar.
- Nachweis
- öffnen
Storage-Vertrag, Migration-SQL, Preflight, Readiness, Canary und Approval-Dossier sind getrennt belegbar.
- Nachweis
- öffnen
Externer Prüfplan markiert, welche Nachweise Betreiber zusätzlich liefern oder beauftragen müssen.
- Nachweis
- öffnen
Launch-Board und Approval-Dossier bündeln Gates, Signoffs, Risiken, Environment-Vertrag und Evidence-Links ohne Secret-Ausgabe.
- Nachweis
- öffnen
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.
Wettbewerbs-Parität
Was für einen SIWECOS-artigen Sicherheitscheck noch fehlt
DACH-Security-Scanner mit Score, Siegel, täglicher Prüfung, Alarmierung, Malware-/Blacklist-/Phishing-/DAST-Signalen und vollständigem Sicherheitsbericht.
DACH-Sicherheitsprofil mit TLS, Headern, Redirects, Cookies, Script-/Version-Signalen, Runbook, JSON/CSV/Markdown und Kurzreport-Verlinkung.
Security-Profil regelmäßig in Monitoring und Betreiber-Board prüfen.- Nachweis
- öffnen
Einbettbares Sicherheitsbadge mit Score, Nachweislinks, Badge-JSON und klarer Nicht-Zertifikat-Policy.
Badge nur mit korrekter Aussage einbetten und bei Score-Änderungen Re-Scan auslösen.- Nachweis
- öffnen
Security-Alerts und Delivery-Payloads für Webhook, Slack, Teams, Jira und E-Mail sind erzeugbar; HMAC-Secret bleibt Launch-Gate.
Webhook-/Operator-Secret setzen und signierten Delivery-Dry-Run prüfen.- Nachweis
- öffnen
Schedule, systemd Runner, Credential-Preflight, Secret-Readiness, Storage-Plan und Launch-Board sind vorhanden; externe Feed-Runs bleiben bis Credentials/Freigabe gesperrt.
Credential-Preflight, Storage-Freigabe und blockierte Launch-Gates schließen.- Nachweis
- öffnen
Storage-Vertrag, Retention, erlaubte/verbotene Felder, DB-Readiness und Approval-Dossier sind getrennt nachweisbar.
DDL-Migration anwenden und Storage-Freigabe erst nach Retention-/Review-Entscheidung setzen.- Nachweis
- öffnen
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.
Storage-Canary-Timer prüfen, nach Tabellen-/Freigabe-Gate kontrolliert starten und Runner-State prüfen.- Nachweis
- öffnen
Betreiber-Prüfplan mit Akzeptanzkriterien, Ownern und Exportlinks markiert externe Validierungen, die SaferPage nicht aus öffentlichem Scan behauptet.
Externe Prüfungen beauftragen oder Evidenz hochladen; SaferPage-Report danach gegen Re-Scan abgleichen.- Nachweis
- öffnen
Gates
Was Launch blockiert
anrufer.info: Security-Feed-Secrets mit 4 Secret-Referenz(en), 0 konfiguriert, 4 fehlend.
SAFERPAGE_URLHAUS_AUTH_KEY und SAFERPAGE_GOOGLE_SAFE_BROWSING_API_KEY serverseitig setzen und Rotation dokumentieren.- Evidence
- öffnen
Security-Feed-Storage ist noch nicht schreibbereit: 0 Datenbank-Artefakt(e) fehlen oder die Serverfreigabe ist nicht aktiv.
Keine Aktion im Launch-Gate offen; weiterhin überwachen.- Evidence
- öffnen
Ohne Serverfreigabe bleibt Speicherung deaktiviert, selbst wenn Tabellen vorhanden sind.
SAFERPAGE_SECURITY_FEED_STORAGE_APPROVED=yes erst nach Retention-, Review- und Alert-Routing-Freigabe setzen.- Evidence
- öffnen
Signatursecret fehlt; Payloads bleiben Dry-Run.
SAFERPAGE_WEBHOOK_SECRET oder SAFERPAGE_OPERATOR_WEBHOOK_SECRET setzen und HMAC-Dry-Run dokumentieren.- Evidence
- öffnen
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.
Keine Aktion im Launch-Gate offen; weiterhin überwachen.- Evidence
- öffnen
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.
Keine Aktion im Launch-Gate offen; weiterhin überwachen.- Evidence
- öffnen
anrufer.info: Security-Feed-Aktivierung mit 5 Gate(s), 4 blockiert, Delivery ohne Secret.
Alle blockierten Activation-Gates nacheinander schließen und danach Einzeltest ausführen.- Evidence
- öffnen
Reihenfolge
Kontrollierter Weg zur Aktivierung
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.
Freigabeakte
Go/No-Go als Betreiber-Dossier exportieren
Das Dossier bündelt Signoffs, Change Plan, Risiken, Environment-Vertrag und Evidence-Links, ohne Feeds auszuführen oder Secret-Werte auszugeben.