Preproduction Security Audit

Sicherheitsaudit vor der Produktion

Erstelle eine entscheidungsrelevante Sicherheitsbewertung des angegebenen Releases. Erkläre, was untersucht wurde, was die Beweise stützen, was noch unbekannt ist, und wie jedes Problem behoben und verifiziert werden kann. Standardmäßig wird der Bericht auf Englisch verfasst, es sei denn, der Nutzer wünscht eine andere Sprache.

Verwende nur die verfügbaren, autorisierten Fähigkeiten des aktuellen Hosts. Löse gebündelte Referenzen relativ zu diesem Skill-Ordner auf. Lokaler Dateizugriff, Shell-Scanner, Browser, Konnektoren und Delegation werden nicht vorausgesetzt. Wenn eine Fähigkeit nicht verfügbar ist, überprüfe die bereitgestellten Beweise und dokumentiere Lücken mit U-###. Wenn das angeforderte Dateisystemziel nicht beschrieben werden kann, stelle den Bericht als herunterladbares Artefakt oder als Markdown-Text zur Verfügung und gib diese Einschränkung an.

Vor der Auswahl der Prüfungen kalibrieren

1. Identifiziere die angeforderte Bewertung, das Ziel-Release oder den Commit, das Bereitstellungsziel, die verfügbaren Beweise und die bestehende Autorisierung. Bewahre den Umfang und die vorherigen Antworten des Nutzers.
2. Lies die Scoping-Fragen. Löse Q-00 auf, bevor du den Repository-Inhalt inspizierst, falls die Repository-Überprüfung nicht bereits angefordert oder eindeutig eingeschlossen wurde. Eine Anfrage, das Repository oder den Code zu auditieren, beantwortet dies bereits; frage nicht noch einmal. Wenn der Nutzer die Repository-Überprüfung ausschließt, arbeite mit den ausgewählten Dokumenten/Konfigurationen/Laufzeitbeweisen und dokumentiere die Einschränkung.
3. Prüfe nur die im Umfang enthaltenen Projektmetadaten und die Dokumentation, ohne den Projektcode auszuführen. Dokumentiere Fakten getrennt von Schlussfolgerungen und Aussagen des Nutzers. Stelle einen kurzen Stapel von verbleibenden Fragen und verzweige nach Produkt, Exposition, Hosting, Identität, Daten und verfügbarem Zugang. Setze die unabhängig autorisierte Arbeit fort, während du wartest; Stille beantwortet keine ungeklärte Umfangsentscheidung.
4. Dokumentiere eine Umfangsübersicht, ausgewählte Module, anwendbare Steuerungs-IDs, zulässige Prüfungen und offene Fragen im Bericht. Aktualisiere diese Übersicht, wenn sich der Umfang aufgrund von Antworten ändert.

Zu relevanten Modulen weiterleiten

Verwende immer die Prüfmethode und Ergebnisse und Prioritäten. Lade Moduldetails nur, wenn deren Oberfläche vorhanden ist oder Untersuchung benötigt. Lade nicht jedes Modell nur, weil es existiert.

Verwende die 35-Domänen-Abdeckungskarte, um die ursprünglichen Bewertungsbereiche mit Steuerungs-IDs zu verknüpfen. Wenn werkzeugunterstützte Prüfungen im Umfang sind, befolge die Scanner-Ausführungsverfahren für Gitleaks, Semgrep CE, Trivy und ZAP; wähle Werkzeuge basierend auf Beweisen und Verfügbarkeit aus und dokumentiere tatsächliche Ausführungen, Fehler und Auslassungen. Eine rein manuelle Anfrage aktiviert keine Scanner.

Für Abhängigkeitsinventare verwende zuerst eine zielgemäße SBOM, dann Trivy, falls Generierung erforderlich und zulässig ist. Native Paketgraphen, Syft und Quellimportanalyse sind optionale Ergänzungen; befolge das Inventarverfahren im selben Referenzdokument. Halte Paketbeziehungen getrennt von Codeimporten und Laufzeitbeziehungen.

Oberfläche	Modul	Weiterleitungsrichtlinie
Jede Bewertung	Architektur	Ermittle Assets, Vertrauensgrenzen, kritische Aktionen, Exposition und Verantwortung.
Konten, Berechtigungen, Tenant, Sitzungen oder Dienstidentitäten	Identität und Zugriff	Schließe Infrastrukturidentitäten ein, auch wenn das Produkt kein Login hat.
Weboberflächen, APIs, Worker, Dateien oder Integrationen	Anwendung und API	Wähle Steuerungen für tatsächliche Eingabe, Ausgabe, Protokoll- und Geschäftspfade.
Daten, Anmeldeinformationen, Kryptografie, Datenbanken oder Speicher	Daten und Geheimnisse	Schließe Anmeldeinformationen und Metadaten ein, auch wenn keine personenbezogenen Daten vorhanden sind.
Ein bereitgestellter Dienst oder eine geplante Bereitstellung	Infrastruktur und Bereitstellung	Passe Anbieter und Bereitstellungsmodell an; unterscheide beabsichtigte Konfiguration von beobachteter Laufzeit.
Quelle, Abhängigkeiten, Build- oder Release-Prozess	Lieferkette	Wenn die Repository-Überprüfung enthalten ist, inspiziere entdeckte CI/CD-Definitionen, deren Skripte/Vorlagen, Vertrauensübergänge und Bereitstellungsgates, ohne auf eine zweite Berechtigungsfrage zu warten. Effektive Plattformeinstellungen bleiben eine separate Beweisquelle.
Ein Dienst, der in Betrieb geht oder bereits in Betrieb ist	Betrieb und Resilienz	Bewerte Erkennung, Wiederherstellung, Incident-Handling, Verfügbarkeit und Verantwortung.
LLMs, RAG, KI-Tools, Agenten oder MCP	KI und Agenten	Überprüfe Modelleingaben, Datenzugriff, delegierte Autorität, Ausgaben und Ressourcengrenzen.
Mobile, Desktop- oder Browsererweiterungs-Client	Mobil und Desktop	Wähle Plattformabschnitte aus und auditiere das Backend separat.

Für nicht unterstützte Spezialoberflächen, wie Industrieanlagen oder kundenspezifische Hardware, dokumentiere die Abdeckungsgrenze und die erforderliche Spezialüberprüfung. Gib nicht an, dass die Softwaremodule diese vollständig bewerten.

Untersuche und dokumentiere

• Befolge die Beweis-, Autorisierungs- und Ausführungsregeln der Prüfmethode. Eine Prüfanfrage autorisiert die Analyse und Berichtserstellung; sie autorisiert nicht automatisch Produktionsänderungen, zerstörerische Sondierungen oder die Veröffentlichung sensibler Ergebnisse.
• Eine Repository-Überprüfung umfasst die vereinbarten Dateien, Quellpfade, Manifeste, relevanten Verlauf und CI/CD-Definitionen. Sie beinhaltet fest codierte Geheimnisse, unsichere Fallback-Werte, umgebungsspezifische Ziele und festgelegte Sicherheits-/Identitätsrichtlinien. Beachte engere Pfad-/Verlaufsausschlüsse; kennzeichne normale Konstanten nicht ohne Sicherheitsrelevanz als Schwachstellen.
• Führe während der Arbeit ein Beweisprotokoll, eine Steuerungsmatrix, Ergebnisse, Unbekanntes, Prüfpfadkanten und Abhängigkeitskanten. Verknüpfe alle wesentlichen Behauptungen mit genauen Quellpositionen oder Beobachtungen und der überprüften Version/Umgebung.
• Behandle Scannerausgaben als Hinweise, bis sie kontextualisiert sind. Verfolge relevante Aufrufer, Guards, Datenpfade, Konfiguration und Bereitstellungsannahmen, bevor du einen bestätigten Fehler oder eine Release-Konsequenz zuweist.
• Nach dem Inventar wende die fokussierte aktuelle Beratungstriage der Lieferkettenmodule (SC-003) an, wobei kritische Komponenten und bekannte ausgenutzte oder kritische/hohe Probleme priorisiert werden. Dokumentiere exakte Paket-/Versionsübereinstimmungen, datierte Quellen, überprüfte Korrekturen, lokale Exposition und abgefragte Abdeckung; Offline- oder fehlgeschlagene Lookups bleiben explizite Lücken.
• Verwende dieselbe Steuerungs-ID in Abdeckung, Ergebnissen, Korrektur und Graphen. Dedupliziere Ergebnisse mit derselben zugrunde liegenden Ursache, während betroffene Oberflächen erhalten bleiben.
• Bei langen Überprüfungen delegiere unabhängige Module, wenn unterstützt. Gib jedem Prüfer den Umfang und die ID-Zuteilung, gleiche dann gemeinsame Vertrauensgrenzen und widersprüchliche Behauptungen ab, bevor der Bericht verfasst wird.
• Wenn Zugang oder ein Werkzeug nicht verfügbar ist, dokumentiere die Einschränkung und setze die sinnvolle Arbeit fort. Ein fehlgeschlagener Check ist kein bestandener Check. Eine unbekannte Steuerung ist nicht nicht anwendbar.

Liefere den Bericht

Verwende die Berichtsvorlage. Standardmäßig wird eine neue Datei unter security-audits/<YYYY-MM-DD>-<revision-or-target>/security-audit.md im auditierten Projekt erstellt, sofern der Nutzer kein anderes Ziel angibt. Verwende ein nicht kollidierendes Suffix, falls dieses Ziel bereits existiert. Speichere keine Zielberichte in diesem Skill, überschreibe keine vorherige Bewertung und committe/übermittle keine Berichte, es sei denn, dies wurde angefordert.

Füge beide erforderlichen Mermaid-Diagramme ein:

1. Analysepfad-Graph: der beobachtbare Prüfpfad vom Umfang und Artefakten über durchgeführte Prüfungen zu Ergebnissen, unterstützten Schlussfolgerungen und Lücken. Zeige, was inspiziert wurde und wo ein Check gestoppt wurde. Dies ist eine Beweiskarte, keine private Argumentation oder erfundene Chronologie.
2. Analyse-Abhängigkeitsgraph: die inspizierten Komponenten, Paketabhängigkeiten, Dienste, Identitätssystemen, Speicher und externen Integrationen, mit expliziten Kantentypen, Beweisreferenzen und Prüfabdeckung. Zeige materielle nicht inspizierte Grenzen als solche an.

Erstelle Graphen aus den Protokollen gemäß dem Graph-Vertrag in der Prüfmethode. Füge Knoten-/Kantentabellen hinzu, damit der Bericht ohne Mermaid-Darstellung nutzbar bleibt. Teile große Abhängigkeitskarten nach Laufzeit/Dienst, Paket/Build oder CI/CD-Vertrauensbeziehungen unter dem Abhängigkeitsabschnitt auf. Zeige für überprüfte Pipelines Trigger/Eingabe → Job → Runner/Identität → Artefakt → Umgebung mit tatsächlichen Gates, Vertrauensgrenzen und nicht inspizierten Einstellungen.

Der Bericht muss einen priorisierten Korrekturplan, Besitzer oder nicht zugewiesene Rollen, Abhängigkeiten zwischen Korrekturen, Akzeptanztests, verbleibende Risiken und ungelöste Entscheidungen enthalten. Gib eine eingeschränkte Bereitschaftsempfehlung unter Verwendung der Ergebnisregeln ab; das Skill genehmigt keine Bereitstellung oder zertifiziert keine Konformität.

Abschließende Qualitätsprüfung

• Überprüfe, ob Umfang, Revision, Beweislinks, Steuerungsstatus und alle Ergebnis-/Unbekannt-IDs in Text, Tabellen, Graphen und Plan übereinstimmen.
• Überprüfe die Richtung und Beschriftung der Graphkanten. Markiere Deklarationen, beobachtetes Verhalten, Schlussfolgerungen und nicht verfügbare Beweise getrennt. Entferne alle Vorlagenbeispieldaten.
• Stelle sicher, dass keine Anmeldeinformationen, personenbezogenen Datenmuster, sensiblen Prompts oder privaten Infrastrukturidentifikatoren unnötig offengelegt werden.
• Jedes Ergebnis benötigt ein konkretes Korrektur- und Verifikationskriterium. Jede kritische Unbekannte benötigt eine nächste Aktion und ihre Konsequenz für die Release-Entscheidung.
• Gib an, welche Prüfungen tatsächlich ausgeführt wurden, welche fehlschlugen oder übersprungen wurden und ob Diagramme dargestellt oder nur die Syntax überprüft wurde. Behaupte niemals einen Test, eine Darstellung oder Laufzeitverifikation, die nicht stattgefunden hat.
• Gib den Dateiort, wichtige Release-Blocker und Abdeckungsgrenzen präzise an. Überlasse die Implementierung von Korrekturen einer autorisierten Folgemaßnahme, sofern diese nicht bereits in der Anfrage enthalten ist.