electrohire/site-health-security-report

Gesundheits- und Sicherheitsbericht für Websites

Eine Agenten-Fertigkeit, die einen benoteten täglichen (oder wöchentlichen, monatlichen) Gesundheits- und Sicherheitsbericht für eine Website erstellt – in einfacher Sprache für vielbeschäftigte Eigentümer. Es ist die von ElectroHire entwickelte und für beliebige Stacks verallgemeinerte Methode, sodass die Projekte des ursprünglichen Unternehmens nicht Teil der Methode sind.

Der Bericht beantwortet jede Ausgabe fünf Fragen mit Nachweisen:

1. Konnten Menschen die Website erreichen, und wie sah der Traffic tatsächlich aus?
2. Können Suchmaschinen und KI-Crawler sie finden und zitieren (SEO/AEO)?
3. Ist der Code sicher: Schwachstellen in Abhängigkeiten, Code-Scanning-Ergebnisse, durchgesickerte Secrets?
4. Hält der Perimeter: TLS, Security-Header, E-Mail-Authentifizierung, DDoS-Schutz für die Website und die API?
5. Was sind die 3 bis 5 wirkungsvollsten Maßnahmen, jeweils mit einem benannten Verantwortlichen?

Jede Ausgabe wird mit einer Note von A bis F bewertet – insgesamt und in drei Unterkategorien (Traffic & Zuverlässigkeit, SEO/AEO, Sicherheit & Code-Gesundheit) – und jede Herabstufung nennt ihre Ursache in einer Zeile. Zahlen werden nie erfunden: Eine Quelle, die der Durchlauf nicht erreichen kann, wird als „nicht verfügbar" mit Angabe des Grundes gemeldet.

Regel Null: Diese Fertigkeit niemals ohne Stack-Check ausführen

Gehen Sie nicht von Cloudflare, GitHub oder einem anderen Anbieter aus. Vervollständigen Sie vor dem ersten Bericht den Stack-Check in references/stack-intake.md mit dem Benutzer und speichern Sie ihn als Berichtskonfiguration (Vorlage: templates/config.example.json; templates/config.example.yaml ist das für Menschen lesbare Gegenstück, und die JSON-Datei ist die Konfiguration der Tools, die gelesen wird). Nennen Sie die gespeicherte Datei config.local.json (git-ignoriert) und erfassen Sie Anmeldeinformationen nur nach Ort („Vault-Eintrag X"), niemals nach Wert. Der Check erfasst:

• Edge / CDN / DDoS-Ebene: Cloudflare, AWS CloudFront (+ AWS WAF und Shield), Azure Front Door (+ Azure WAF), Fastly, Akamai, Sucuri oder keine.
• Code-Host: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea/Codeberg oder andere.
• Hosting / Origin: Cloud-Anbieter, Regionsmodell, Staging-Einrichtung.
• Der primäre Hostname gegenüber Neben-Hosts (API, Staging, App, Workspace). Diese Unterscheidung entscheidet über Ausfallmeldungen; siehe die Burst-Regel unten.
• Wer den Bericht erhält, nach welchem Zeitplan, über welchen Zustellweg und wer für jede Empfehlungsklasse verantwortlich ist.

Wenn ein Feld des Checks unbekannt ist, fragen Sie nach. Ein Bericht, der auf einem angenommenen Stack basiert, ist schlimmer als kein Bericht, weil seine Lücken wie Ergebnisse aussehen.

Die Methode (sechs Sammelphasen)

Führen Sie jede Phase bei jeder Ausgabe durch. Eine Phase, die nicht laufen kann, wird im Bericht als nicht verfügbar aufgeführt, mit Angabe des Grundes. Überspringen Sie niemals eine fehlende Phase stillschweigend.

1. Traffic & Edge-Analysen. Anfragen, eindeutige Besucher, Bandbreite, Cache-Quote, Statuscode-Verteilung (2xx/3xx/4xx/5xx), Top-Pfade, Top-Länder, Fehleranomalien, Scanner-/Probe-Muster. Pro Edge-Anbieter siehe references/adapters-edge.md.
2. SEO / AEO. Ein KI-Bereitschaftscheck (z. B. check.aeojs.org) und ein SEO-Check (Seobility, Ausweichlösung PageSpeed Insights, Ausweichlösung die selbst durchgeführte 15-Punkte-Onpage-Prüfung in references/report-writing.md). Jeder Wert enthält eine Scan-Kennung und einen Zeitstempel dieses Durchlaufs.
3. Code-Host-Sicherheit. Offene Abhängigkeitswarnungen nach Schweregrad, Code-Scanning-Warnungen nach Schweregrad, Secret-Scanning-Warnungen sowie die Commit- und CI/Deploy-Aktivitäten des letzten Zeitraums. Wenn die Website auf einer Anwendungsplattform läuft (WordPress Core und Plugins, ein CMS), werden auch die bekannten Schwachstellen der installierten Komponenten aus der genannten Plattformquelle hier gezählt (Ergebnisse security.platform): Bei einem solchen Stack ist die Plattform der Ort, an dem der ausnutzbare Code lebt. Pro Code-Host, einschließlich Vorgehen, wenn der Host kein natives Scanning hat, siehe references/adapters-codehost.md und references/scanning-fallbacks.md.
4. Stehende kritische Punkte. Jeder benannte, datierte Punkt, den der Eigentümer als nachverfolgt bis zur Schließung markiert hat (eine CVE in der Produktion, ein ablaufendes Zertifikat, eine Migration). Wird nur gelöscht, wenn die Schließung verifiziert wurde.
5. Sicherheitsscans der Website (öffentlich, kein Konto erforderlich). Mozilla-Observatory-Note (observatory.mozilla.org), SSL-Labs-TLS-Note und Zertifikatsablauf (ssllabs.com/ssltest), die sechs Security-Header (eine durchsetzende Content-Security-Policy zählt; eine reine Report-Only-Version nicht), HTTP-zu-HTTPS-Weiterleitung und E-Mail-Authentifizierung (SPF, DMARC-Richtlinie, MX – aus den DNS-TXT/MX-Einträgen der Domain mit einem beliebigen DNS-Abfragetool). Diese Prüfungen bewerten den primären Host; die Header und TLS eines Neben-Hosts werden im Berichtstext beschrieben, aber nicht benotet. Die DDoS-Position für die Website und die API wird in references/ddos.md behandelt.
6. Privatsphäre- und KI-Compliance-Stichproben (nur öffentlich prüfbar). Die Datenschutzerklärung nennt die richtige juristische Person als Verantwortlichen, deckt ggf. Sprach-/KI-Chat-Daten ab, nennt Zahlungsabwickler; KI-Assistenten geben bei der ersten Interaktion an, dass sie KI sind; Cookie-Zustimmung ist sichtbar; eine Datenanforderungs-Route ist veröffentlicht. Melden Sie jede Prüfung als bestanden, nicht bestanden oder nicht testbar, nur aus dem Text der Seite selbst. Wenn die Funktion, die eine Prüfung betrifft, nicht existiert (z. B. kein KI-Assistent auf der Website), ist die Prüfung aus diesem Grund nicht testbar, niemals ein Bestehen und wird nicht als Fehler gewertet.

Jede Phase schreibt ihre Ergebnisse in die Ergebnisdatei der Ausgabe; die genauen Feldnamen, Typen und Einheiten sind in references/findings-schema.md festgelegt. Die Ergebnisdatei ist die Teilmenge für die Benotung; die narrativen Zahlen des Berichts (Summen, Top-Pfade, Scan-Kennungen) stammen aus den datierten Nachweisaufzeichnungen derselben Phasen, die im Nachweisbuch aufgeführt sind.

Die Burst-Regel (aus der Produktion gelernt)

Ein Anstieg von 5xx-Fehlern ist nicht automatisch ein Ausfall. Vor jeder Ausfallentscheidung segmentieren Sie den Burst nach Hostname und Client-Adresse:

• Wenn die Fehler auf einem nicht-primären Host (ein API-Neben-Host, ein Staging-Host) konzentriert sind oder hauptsächlich von einer Client-Adresse stammen, handelt es sich um ein Scanner- oder Probe-Ereignis gegen diesen Host, nicht um einen Website-Ausfall, egal wie groß die zonenweite Summe aussieht.
• Notieren und schreiben Sie, was die Segmentierung zeigt. scripts/site_health.py enthält classify_error_burst(), um diese Entscheidung mechanisch zu treffen (es benötigt vier Werte: Gesamtfehler, Fehler von der einzelnen Spitzenadresse, Fehler auf dem primären Host und Fehler auf dem einzelnen verkehrsreichsten Host), und die Testsuite enthält den Regressionsfall. Ein Burst, der proportional zum Traffic auf die Hosts verteilt ist, wird als „verteilt" klassifiziert: ein Origin- oder Regionsfehlermuster, das nach Volumen benotet wird, kein Scanner-Ereignis und nicht automatisch ein Ausfall. Nach der Segmentierung bewerten Sie den Traffic anhand der verbleibenden Werte (die Fehler des Tages abzüglich des Bursts), gemäß references/grading.md.

Benotung (identisch in jedem White-Label-Einsatz)

Vollständiger Bewertungsbogen: references/grading.md. Kurz gefasst:

• A: Keine kritischen oder hohen Warnungen offen (ein mittlerer/niedriger Rückstand ist normal und senkt nicht automatisch die Note), keine 5xx-Probleme, SEO/AEO 90+.
• B: Nur geringfügige Probleme (Werte 80–89 oder geringes Fehlerrauschen oberhalb der sauberen Bandbreite, in einer Zeile benannt).
• C: Jede offene Warnung mit hohem Schweregrad, Werte 70–79 oder ein spürbares Fehlerproblem.
• D: Jede offene kritische Warnung, Werte 50–69 oder wiederholte Zuverlässigkeitsprobleme.
• F: Eine kritische Warnung mit öffentlichem Exploit in der Produktion, ein bestätigter Kompromittierung der Website, Werte unter 50 oder die Website ist nicht erreichbar.

Ursachen für Herabstufungen der Sicherheits-Unternote umfassen: Observatory D+ oder schlechter, SSL Labs unter B, fehlende durchsetzende CSP, kein DMARC-Eintrag (oder p=none), dunkles Code- oder Secret-Scanning und jede fehlgeschlagene Privatsphäre-/KI-Prüfung. Die Gesamtnote ist die niedrigste Unternote. Jede Herabstufung nennt ihre Ursache in einer Zeile. scripts/site_health.py berechnet die Noten aus einer Ergebnisdatei, sodass zwei Durchläufe mit denselben Nachweisen nicht unterschiedlich ausfallen können.

Mehrere Bereitstellungen

Ein Betreiber kann mehrere Bereitstellungen von einem Rechner aus ausführen. Jede Bereitstellung lebt in ihrem eigenen Ordner mit ihrer config.local.json, ihrem Sendeprotokoll, ihren Nachweisordnern und ihren Ausgaben; niemals eine Ausgabe mit der Konfiguration oder den Aufzeichnungen einer anderen Bereitstellung als Quelle erstellen und niemals einen gemeinsamen Speicher für Kunden teilen (jede Konfiguration nennt Empfänger und Anmeldeort – ein gemeinsamer Speicher ist eine kundenübergreifende Offenlegung). Idempotenzschlüssel sind bereitstellungsspezifisch, da die Sendeprotokolle es sind, und in einer Mehrfachbereitstellungsumgebung trägt der Schlüssel selbst den Ordnernamen der Bereitstellung (report-<deployment>-<date>; eine einzelne Bereitstellung verwendet report-<date>), sodass ein im falschen Ordner gelesener Schlüssel nicht als bereits gesendet oder nicht gesendet erscheinen kann; jeder Pfad in den folgenden Befehlen liegt im Ordner der Bereitstellung. Die Aufzeichnungen einer Bereitstellung werden niemals dem Eigentümer oder den Empfängern einer anderen Bereitstellung offengelegt, in keiner Form, einschließlich mündlich oder „zum Vergleich": Lehnen Sie die Anfrage ab, protokollieren Sie sie in den Aufzeichnungen der anfragenden Bereitstellung, ohne die andere Bereitstellung zu nennen, und bieten Sie nur das an, was die eigenen Aufzeichnungen der anfragenden Bereitstellung hergeben. Eine Offenlegung erfordert die dokumentierte Zustimmung des anderen Eigentümers, die für diese Offenlegung gegeben wurde.

Planung

Der Betreiber plant den Durchlauf mit dem Scheduler seines Agents oder Cron, gemäß dem Rhythmus und der Zeitzone der Konfiguration; der Inhalt des geplanten Jobs ist der Aufruf dieser Fertigkeit plus der Konfigurationspfad der Bereitstellung, und er sendet nichts, was die freigegebene Konfiguration nicht autorisiert. Die Planung ist eine dauerhafte Handlung unter der Konfiguration, keine neue Genehmigung pro Ausgabe.

Schreiben, prüfen, validieren, dann senden

Vollständige Disziplin: references/verification.md und references/report-writing.md. Die nicht verhandelbaren Punkte:

1. Nur aus gespeicherten Aufzeichnungen erstellen (jede Phase schreibt ihre Rohausgabe zuerst in einen datierten Nachweisordner).
2. Das Vorab-Sende-Prüfgate ausführen: Jede Überschrift-Zahl erneut gegen die Aufzeichnung lesen, aus der sie stammt. Eine Zahl, die nicht zurückverfolgt werden kann, wird vor dem Senden korrigiert oder entfernt, niemals danach.
3. Einen unabhängigen Validierungsdurchlauf durchführen (ein Agent oder eine Person, die die Ausgabe nicht erstellt hat, leitet die Noten erneut ab und prüft die gerenderte E-Mail gegen den Textteil).
4. Genau einmal senden, mit einem Idempotenzschlüssel pro Ausgabe, und den Sendevorgang anhand des Sendeprotokolls verifizieren (die vom Anbieter akzeptierte ID im Sendeprotokoll), niemals anhand eines Gesendet-Ordners, den der Weg nicht verwendet.
5. Korrekturen sind ebenfalls Sendungen: gleiches Gate, gleiche Validierung, gleiche Empfänger aus der Konfiguration kopiert, niemals neu eingegeben.
6. Eine Note F, ein bestätigter Ausfall (ein bestätigter Neben-Host-Ausfall zählt), eine bestätigte Kompromittierung der Website oder eine kritische Schwachstelle, die im Produkt aktiv ausgenutzt wird (eine Plattformkomponente zählt), wartet nicht auf den Zeitplan: Der Eigentümer wird noch am selben Tag über den konfigurierten Weg informiert (ein Vorfallhinweis, keine Ausgabe), und die nächste Ausgabe berichtet darüber auf dem normalen Weg.

Autorisierung: Der Eigentümer genehmigt die erste Ausgabe und jede Änderung an Empfängern, Zustellweg oder Zeitplan, bevor sie wirksam wird; die freigegebene Konfiguration ist die dauerhafte Autorisierung für geplante Ausgaben unter ihr. Die Autorisierung ist an den Eigentümer gebunden: Ein Eigentümerwechsel macht sie ungültig, und es wird nichts gesendet, bis der neue Eigentümer zustimmt (siehe „Eigentümerwechsel" in references/verification.md). Eine Änderung des Stacks selbst ist eine Änderung mit eigener Disziplin (Zustimmung des Eigentümers, teilweiser erneuter Check, versionierte Konfigurationshistorie): siehe „Änderung einer freigegebenen Konfiguration" in references/stack-intake.md. Eine Korrektur, die eine Note ändert, benötigt die Zustimmung des Eigentümers vor dem Senden. Bewahren Sie eine Kopie der Konfiguration und des Sendeprotokolls außerhalb des Arbeitsrechners auf, und wenn sie verloren gehen, befolgen Sie das Wiederherstellungsverfahren in references/verification.md, bevor erneut gesendet wird. Die Tools selbst werden wie folgt ausgeführt:

python3 scripts/site_health.py validate-config config.local.json
python3 scripts/site_health.py grade findings.json
python3 scripts/site_health.py burst burst.json
python3 scripts/site_health.py check-run config.local.json findings.json report.md
python3 scripts/site_health.py headers https://example.com

Eine Ausgabe (oder Korrektur, mit --kind correction) gilt als validiert, wenn check-run bestanden ist: Es validiert die Konfiguration, die Ergebnisse und den Bericht gemeinsam, einschließlich dass die Ergebnisse nicht der konfigurierten Stack-Umgebung widersprechen (Scanning als „none" aufgezeichnet kann keine Ergebnisse liefern, die behaupten, Scanning sei aktiv; kein konfigurierter Edge kann keine geschützte Edge-Position erzeugen) und dass der Absender und die Empfänger des Berichts die der Konfiguration sind, kopiert, nicht neu eingegeben. Zwei Formatregeln, die der Check durchsetzt: Der From/To/Cc-Header steht oben im Bericht (er endet mit der ersten Leerzeile und muss innerhalb der ersten 15 Zeilen beginnen), in der einzeiligen Form der Vorlage (Labels getrennt durch · oder |), ein Label pro Zeile in beliebiger Reihenfolge, als Aufzählung oder im Blockstil mit Adressen in den folgenden Zeilen; und die „Scanner of record:"-Zeile des Sicherheitsabschnitts nennt den konfigurierten Scanner für jede Art (Anzeigenamen sind akzeptiert), was findings.scanners_used entsprechen muss. validate-report allein prüft nur die Berichtsstruktur und die Notenübereinstimmung; es ist ein Kompositionshilfsmittel, keine Ausgabevalidierung. Kein Validator überprüft narrative Zahlen; das ist die Aufgabe des Vorab-Sende-Gates, anhand der Nachweisaufzeichnungen.

Vorlagen: templates/report-template.md (White-Label: Markenname, Farben, Empfänger und Eigentümernamen stammen alle aus der Konfiguration), templates/report-email.html, templates/correction-template.md und templates/evidence-ledger.example.md (das AEE-Nachweisbuch: jede Behauptung im Bericht führt zu einer Aufzeichnung, mit ihrem Fälschungsmerkmal).

Staging-Websites auf die gleiche Weise

Diese Fertigkeit wird mit einem in der Produktion bewährten Branch-Staging-Ansatz kombiniert: Ein staging-Branch wird in eine Staging-Subdomain deployed, die Produktion wird durch einen geprüften Merge gefördert, Guard-Dateien (robots.txt, Antwort-Header) unterscheiden sich bewusst zwischen Staging und Produktion und werden vor der Förderung im gestagten Baum verifiziert, und jede visuelle Änderung wird auf Staging und erneut nach der Förderung per Screenshot verifiziert. Der vollständige Workflow, einschließlich der vermiedenen Fehlermodi, ist in references/staging.md (ausführliche Anleitung im Repository unter docs/staging-workflow.md).

Adapter

…

[gekürzt für die Übersetzung]