Security-Audit

Sicherheitsaudit

Finden Sie Schwachstellen, die eine echte Vertrauensgrenze verletzen, und geben Sie den Eigentümern dann die Quellnachweise, eine sichere Reproduktion, Priorität und den kleinstmöglichen effektiven Fix. Dies ist ein defensiver, quellorientierter Workflow. Ein Kandidat ohne einen konkreten betroffenen Hauptakteur, eine Ressource oder ein Sicherheitsergebnis ist kein bestätigter Befund.

Betriebsmodi

Diese Fähigkeit ist standardmäßig eine Anleitung. Das Laden autorisiert weder den vollständigen Audit-Workflow noch die Dateierstellung.

• Anleitungsmodus: Verwenden Sie für Sicherheitsfragen, gezielte Überprüfungen, Methodik, Triage oder Untersuchung bestimmter Befunde nur die relevanten Teile dieser Fähigkeit. Führen Sie nicht automatisch alle sechs Phasen aus, erstellen Sie kein Ausgabeverzeichnis und schreiben Sie keine Audit-Artefakte. Sie können bei Bedarf fokussierte Agents starten; diese geben Ergebnisse an die aktuelle Aufgabe zurück.
• Vollständiger Audit-Modus: Verwenden Sie den vollständigen Workflow, wenn der Benutzer explizit bittet, eine Codebasis zu auditieren oder einem Pen-Test zu unterziehen, einen vollständigen, umfassenden oder End-to-End-Sicherheitsreview anfordert oder Berichtsartefakte wünscht. Führen Sie alle sechs Phasen aus und schreiben Sie die unten definierten Dateien.

Wenn die Anfrage beide Modi bedeuten könnte, stellen Sie eine gezielte Frage, bevor Sie Dateien erstellen oder den vollständigen Workflow starten.

Plattform-Terminologie

Diese Fähigkeit ist agentenneutral:

• Parent ist der Agent, der den Lauf koordiniert und den gemeinsamen Zustand besitzt.
• Task-Tool ist der Delegations- oder Sub-Agent-Mechanismus der Plattform.
• research-Agent ist ein delegierter Agent für fokussierte Quellenerkundung und Faktenüberprüfung.
• general-Agent ist ein delegierter Agent für breite Untersuchungen und begrenzte lokale Ausführung.
• subagent_type: in einer Überschrift benennt, welcher dieser beiden delegierten Agentenrollen diese Arbeit ausführt.

Verwenden Sie äquivalente Plattformfähigkeiten, während Sie Rollen-, Schreibisolations-, Prompt- und Unabhängigkeitsgrenzen einhalten.

Universelle Ausführungssicherheit

Diese Regeln gelten in beiden Betriebsmodi. Die Quellinspektion ist schreibgeschützt. Führen Sie zielgesteuerte Builds, Tests, Prozesse, Browser, Emulatoren, Fuzzer und Fixture-Verarbeitung nur innerhalb einer betriebssystemgestützten Sandbox aus, die alle diese Kontrollen bietet:

• kein externes Netzwerk; verwenden Sie nur einen isolierten Loopback-Namensraum, wenn die Prüfung lokalen Client/Server-Verkehr benötigt;
• eine leere Umgebung, die aus einer expliziten Positivliste mit sicheren Werten befüllt wird, mit lokalen HOME-, temporären Verzeichnissen und Caches für den Scratch-Bereich;
• ein schreibgeschütztes Ziel und eine Toolchain, wobei der zielgesteuerte Prozess nur in sein zugewiesenes scratch/-Verzeichnis schreiben darf; und
• explizite niedrige Grenzwerte für CPU, Speicher, Prozesse, Dateigröße, Festplatte und Wanduhrzeit.

Der Agent (außerhalb des zielgesteuerten Prozesses) darf eine einmalige Quellkopie in einem zugewiesenen scratch/-Verzeichnis erstellen, wenn ein Build neben die Quelle schreiben muss. Im Anleitungsmodus behalten Sie keine zielgesteuerten Dateien. Im vollständigen Audit-Modus darf nur vertrauenswürdiger Parent-seitiger Code das minimale nicht geheime Ergebnis mithilfe des Verfahrens unter Schreibisolation in das behaltene artifacts/ überführen. Machen Sie niemals ein behaltenes Ausgabeverzeichnis (außer dem eigenen zugewiesenen scratch/ des Agents), das Verzeichnis eines anderen Agents, das Home-Verzeichnis des Hosts, Anmeldeinformationen, Sockets oder gemeinsame Dienste für Zielcode zugänglich. Installieren Sie keine Abhängigkeiten und lassen Sie Builds diese nicht abrufen. Verwenden Sie nur bereits lokal verfügbare Tools und Abhängigkeiten. Wenn nicht jede Kontrolle durchgesetzt werden kann, führen Sie keinen Zielcode aus: melden Sie die fehlende Sandbox-Fähigkeit als Validierungsblocker und geben Sie einen sicheren Validierungsplan an.

Verwenden Sie Dummy-Hauptakteure, Fixtures und Geheimnisse. Sondieren Sie keine bereitgestellten Endpunkte, externen Dienste, gemeinsamen Infrastrukturen, Produktionsidentitäten, Daten anderer Benutzer oder Live-Steuerungsebenen. Testen Sie keine Verfügbarkeit gegen einen Live- oder gemeinsamen Prozess, veröffentlichen Sie keine Artefakte, ändern Sie keine Releases, verbrauchen Sie kein bezahltes API-Kontingent und fahren Sie nicht über die minimalen lokalen Auswirkungen hinaus fort, die zum Nachweis eines Defekts erforderlich sind. Wenn die entscheidende Tatsache außerhalb der Quelle oder der Sandbox-Fixture liegt, melden Sie sie als validierungsbedürftig.

Vollständiges Audit-Setup

Lösen Sie im vollständigen Audit-Modus diese Werte vor der Erkundung auf:

• Skill-Verzeichnis: das absolute Verzeichnis, das diese SKILL.md enthält.
• Ziel: das absolute Repository-Root, das überprüft wird.
• Repo-Name: eine stabile Repository-Kennung aus dem Verzeichnis oder dem lokalen Git-Remote.
• Ausgabeverzeichnis: ein neues beschreibbares Verzeichnis außerhalb des Ziels, standardmäßig ~/security-audit-skill/<repo-name>/run-<N>, wobei <N> die nächste ungenutzte ganze Zahl ist. Verwenden Sie ein Verzeichnis innerhalb des Ziels nur, wenn der Benutzer es explizit auswählt und der Parent überprüft, dass die Versionskontrolle das gesamte Verzeichnis ignoriert. Andernfalls stoppen Sie und fordern Sie einen externen Pfad an.
• Source-Ref: der überprüfte Commit und ob der Arbeitsbaum nicht sauber ist. Behandeln Sie nicht überprüfte generierte oder geänderte Dateien nicht als eine andere Revision.

Schreibisolation

Der Parent erstellt die gemeinsam genutzten Laufdateien und ist deren einziger Schreiber:

• run-metadata.json
• architecture.md
• coverage-ledger.json
• findings.json
• REPORT.md
• FINDINGS-DETAIL.md
• NEEDS-VALIDATION.md

Jeder Hunter oder Verifizierer erhält ein eindeutiges Root unter <output-dir>/agents/<agent-id>/ mit separaten scratch/- und artifacts/-Verzeichnissen. Kanonische Agent-IDs entsprechen ^[a-z0-9][a-z0-9_-]{0,63}$ und dürfen nicht mit einem Windows-Gerätenamen wie con, prn, aux, nul, com1 bis com9 oder lpt1 bis lpt9 übereinstimmen. Kleinbuchstaben-IDs verhindern Kollisionen durch Groß-/Kleinschreibung. Der Agent und jeder zielgesteuerte Prozess dürfen nur in scratch/ schreiben; das behaltene artifacts/ gehört dem Parent, wird niemals der Sandbox ausgesetzt und ist nur durch vertrauenswürdigen Parent-seitigen Promotionscode beschreibbar. Agents dürfen keine gemeinsam genutzten Dateien, Zielquellen, behaltene Artefakte oder das Verzeichnis eines anderen Agents ändern. Verwenden Sie nicht /tmp oder das Home-Verzeichnis des Hosts als beschreibbaren Fallback.

Vor der Ausführung öffnet und behält der Parent vertrauenswürdige, nicht vererbbare Verzeichnisdeskriptoren für die scratch/- und artifacts/-Roots des Agents und zeichnet eine Positivliste der erwarteten Scratch-relativen Artefaktdateien sowie explizite Pro-Datei- und kumulative Byte-Limits auf. Übergeben Sie diese Deskriptoren niemals an den Agenten oder die Sandbox. Nach Beendigung der Sandbox und aller ihrer Prozesse befördert der vertrauenswürdige Parent-seitige Code jede Datei auf der Positivliste separat:

1. Validieren Sie den deklarierten relativen Pfad: lehnen Sie absolute, leere, ., .. oder symbolisch verknüpfte Komponenten ab.
2. Durchlaufen Sie jede übergeordnete Komponente ab dem behaltenen Scratch-Root-Deskriptor mit No-Follow-Verzeichnis-Relativoperationen; öffnen Sie niemals erneut über einen Pfad.
3. Öffnen Sie das Blatt No-Follow und nicht blockierend.
4. Überprüfen Sie mit fstat, dass es sich um eine reguläre Datei mit einer Linkanzahl von genau eins und innerhalb der aufgezeichneten Pro-Datei- und kumulativen Byte-Limits handelt.
5. Setzen Sie diese Limits beim Lesen von diesem Deskriptor erneut durch.
6. Kopieren Sie genau die überprüfte Größe, wiederholen Sie fstat und lehnen Sie eine geänderte Identität, einen geänderten Typ, eine geänderte Linkanzahl oder Größe ab.
7. Durchlaufen Sie für das Ziel jede übergeordnete Komponente ab dem behaltenen Artefakt-Root-Deskriptor mit No-Follow-Verzeichnis-Relativoperationen; fordern Sie, dass jede vorhandene Komponente ein echtes Verzeichnis ist, und erstellen Sie fehlende Verzeichnisse exklusiv, bevor Sie sie erneut öffnen und No-Follow überprüfen.
8. Erstellen Sie das Blatt exklusiv, ohne Links zu folgen, überprüfen Sie, dass das geöffnete Ziel eine reguläre Datei mit einer Linkanzahl von genau eins ist, und kopieren Sie vom überprüften Quelldeskriptor, ohne einen der beiden Pfade erneut zu öffnen.
9. Verwenden Sie auf Nicht-POSIX-Systemen äquivalente race-sichere APIs.
10. Kopieren Sie niemals rekursiv Scratching oder Globen, extrahieren Sie kein Archiv in artifacts/ und öffnen oder befördern Sie keinen Symlink, FIFO, Socket, kein Gerät, Verzeichnis, keine hart-verknüpfte Datei, keine sich ändernde Datei und keine Datei, die ihre Grenze überschreitet.
11. Wenn eine Prüfung nicht verfügbar ist, nicht durchgesetzt werden kann oder fehlschlägt, verwerfen Sie den Scratch-Eintrag; wenn es sich um entscheidende Beweise handelt, behalten Sie `needs_v