boshu2/security

Sicherheitskompetenz

Zweck: Wiederholbare Sicherheitsprüfungen über Code, Skripte, autorisierte Binärdateien und repository-verwaltete Prompt-Oberflächen durchführen.

Diese Kompetenz für einen vom Anrufer angeforderten Repository-Scan, eine autorisierte Binärdateiabsicherung, Abhängigkeitsrisiken, Geheimnisse oder einen Offline-Prompt-Oberflächen-Redteam-Einsatz verwenden.

Kritische Einschränkungen

• Nur Repositorys, Binärdateien und Prompt-Oberflächen scannen, die dem Betreiber gehören oder für deren Bewertung er ausdrücklich autorisiert ist. Warum: Eine Sicherheitsüberprüfung gewährt keinen Zugriff auf Drittsysteme oder proprietäres Material.
• Sammlung standardmäßig schreibgeschützt halten; keine Geheimnisse exfiltrieren, keine destruktiven Payloads ausführen und keine Richtlinien/Baselines mutieren, um ein grünes Ergebnis zu erzeugen. Warum: Die Bewertung darf nicht zum Vorfall werden oder dessen Beweise löschen.
• Fehlende/fehlerhafte Scanner als Abdeckungslücke behandeln, niemals als sauberen Befund; --require-tools verwenden, wenn eine vollständige Werkzeugabdeckung erforderlich ist. Warum: Fehlende Beweise sind kein Beweis für Abwesenheit.
• Den aktuellen Agenten und die lokale Shell verwenden; keine weitere Laufzeit oder Orchestrierungsschicht starten, es sei denn, dies wird ausdrücklich angefordert. Warum: Repository-Scans sind ein begrenzter Vorgang, keine Erlaubnis, sich auszubreiten.
• Den ausgewählten Scan einmal ausführen und Befunde sowie Abdeckungslücken melden. Behebung, Risikoakzeptanz, Wiederholung und Förderung sind Entscheidungen des Anrufers.

Prompt

Führe einen vollständigen Sicherheitsscan auf cli/ im fleet-router-Repository durch: Abhängigkeitsrisiko, Geheimnisse und statische Analyse. Halte die Sammlung schreibgeschützt, behandle jeden fehlenden Scanner als Abdeckungslücke und melde Befunde sowie Abdeckungslücken, anstatt sie zu beheben.

Es funktioniert, wenn

• Der Bericht auflistet, welche Scanner gelaufen sind, z. B. gosec ./..., und jedes fehlende Tool als Abdeckungslücke markiert, niemals als sauberen Durchlauf.
• Die Sammlung während des gesamten Vorgangs schreibgeschützt bleibt: kein curl, rm oder Auslesen von Anmeldedaten erscheint im Transkript.
• Befunde eine Datei und Zeile angeben, wie cli/internal/auth/token.go:42, niemals eine vage Kategorie.
• Die findings und coverage gaps der Antwort von allen Behebungsschritten getrennt bleiben, als Entscheidungen des Anrufers.

Sicherheitsoberflächen

1. Repository-Gate: scripts/security-gate.sh kombiniert verfügbare Scanner für schnelle/vollständige/Release-Prüfungen.
2. Zusammensetzbare Suite: scripts/security_suite.py bietet statische, dynamische, Vertrags-, Baseline- und Richtlinienprimitive für autorisierte Binärdateien.
3. Offline-Redteam: scripts/prompt_redteam.py überprüft repository-eigene Prompt- und Tool-Steuerungsoberflächen gegen das Angriffspaket.

Dies ist das kanonische Sicherheitsrunbook. Die suite-richtliniengesteuerte Ausgabe erzeugt maschinenlesbare Ausgaben, einschließlich policy/policy-verdict.json, wenn eine Richtliniendatei bereitgestellt wird.

Lies das Suite-Runbook, bevor du mit Binärdateien, Richtlinien, Baselines oder Redteam-Arbeit beginnst. Verwende die OWASP-Checkliste für die Code-Überprüfung.

Ausführungsworkflow

1) Schnelles Gate

Ausführen:

scripts/security-gate.sh --mode quick

Checkpoint: Den Exit-Code bewahren und überprüfen, ob der gemeldete security-gate-summary.json existiert und vor der Triage analysiert werden kann.

2) Vollständiger Scan

Ausführen:

scripts/security-gate.sh --mode full

--require-tools hinzufügen, wenn übersprungene Scanner die Zusicherungsbehauptung ungültig machen würden. Checkpoint: Das Ergebnis als unvollständig melden, es sei denn, der ausgewählte Artefaktvalidator und der Prozess sind beide erfolgreich.

3) Geplantes Gate

Die geplante Automatisierung führt das vollständige Gate gegen den vorgesehenen Branch aus und behält sein Artefaktverzeichnis. Ein fehlgeschlagener geplanter Lauf erstellt nachverfolgbare Arbeitsaufgaben; AgentOps selbst stellt den Scheduler nicht bereit.

4) Jagddisziplin

Bei Überprüfungsarbeiten über die skriptgesteuerten Gates hinaus (Code-Ebene oder Redteam-Durchläufe) nach der vollständigen Taxonomie jagen, nicht nach der ersten Ahnung:

• Vollständige Taxonomiejagd. Jede anwendbare Klasse in der OWASP-Checkliste (oder dem Angriffspaket für Prompt-Oberflächen) durchgehen und ein Ergebnis pro Klasse aufzeichnen: Befund, sauber oder nicht bewertet. Eine nicht besuchte Klasse ist eine Abdeckungslücke, kein sauberer Bereich. Der Verfolgung eines einzigen verdächtigen Hinweises unter Ausschluss der Taxonomie ist der First-Scent-Fixation-Fehlermodus.
• Empirischer Beweis pro Befund. Ein Befund ist real, wenn er sich reproduzieren lässt: eine konkrete Eingabe, Anfrage oder ein Befehl, der das Verhalten demonstriert, erfasst im Artefakt. Nur auf Mustererkennung basierende Befunde werden als Verdachtsfälle gemeldet, die niedriger eingestuft werden als bewiesene.
• Fail-Open-Sonden. Für jede Wache, jedes Gate oder jede Zeitüberschreitung auf der Oberfläche fragen, was passiert, wenn sie fehlschlägt oder hängt – und sie dann testen, wo es sicher ist. Eine Steuerung, die bei einem Fehler offen fehlschlägt, ist ein Befund, selbst wenn ihr Happy Path korrekt ist.
• Identitätskettenverfolgung. Bei authentifizierten oder delegierten Abläufen verfolgen, wer die effektive Identität an jedem Hop ist (Benutzer, Dienst, Token, Hook). Ein Hop, bei dem die Identität angenommen und nicht verifiziert wird – der Borrowed-Identity-Fehlermodus – ist ein Befund.
• Quiet-Round-Konvergenz. Vollständige Durchläufe so lange wiederholen, bis ein vollständiger Durchlauf nichts Neues mehr ergibt: keinen neuen Befund, keine neue Abdeckungslücke. Diese ruhige Runde ist die Stoppbedingung. Das Anhalten nach einer lauten Runde (Befunde kommen immer noch) ist verfrüht; die Jagd als nicht konvergiert melden, wenn das Budget vor einer ruhigen Runde endet.

5) Triage

1. Das neueste Artefakt öffnen und Scanner, Schweregrad, Datei und Abdeckungslücken identifizieren.
2. Den Befund mit dem engsten sicheren Befehl reproduzieren.
3. Konkrete Befunde einstufen und Abdeckungslücken bewahren.
4. Stoppen. Behebung, Risikoakzeptanz und jeder spätere Scan sind neue Entscheidungen des Anrufers. Keine Herabstufung, Unterdrückung oder Aktualisierung einer Baseline nur zum Bestehen vornehmen.

Ausgabespezifikation

Artefaktverzeichnis: Repository-Gates schreiben ${SECURITY_GATE_OUTPUT_DIR:-${TMPDIR:-/tmp}/agentops-security}/<run-id>/; Suite- und Redteam-Läufe verwenden ihr explizites --out-dir.

Dateinamenskonvention: Repository-Gates erfordern security-gate-summary.json (und rohes summary.json); Suite-Läufe erfordern suite-summary.json; Redteam-Läufe erfordern redteam/redteam-results.json.

Serialisierungs-/Schemaformat: security-gate-summary.json ist JSON mit nicht leerem mode, run_id, output_dir und gate_status, numerischem missing_tool_count, booleschem require_tools und Objekt toolchain.

Validierungsbefehl: Mit OUT=<security-gate-run-dir> ausführen: jq -e '(.mode|type)=="string" and (.mode|length)>0 and (.run_id|type)=="string" and (.run_id|length)>0 and (.output_dir|type)=="string" and (.output_dir|length)>0 and .gate_status=="PASS" and (.missing_tool_count|type)=="number" and (.require_tools|type)=="boolean" and (.toolchain|type)=="object"' "$OUT/security-gate-summary.json" >/dev/null.

Ausgabe: Den Artefaktpfad, den Befehl/Exit-Code, den Modus, den Gate-Status, die Abdeckung fehlender Tools, eingestufte Befunde und die Autorisierungsgrenze melden. Keinen Besitzer, keine nächste Aktion, Genehmigung, Freigabe oder Wiederholungsentscheidung hinzufügen.

Qualitätscheckliste

• Ziel und Autorisierungsgrenze sind explizit; die Sammlung blieb innerhalb dieser Grenzen.
• Scannerverfügbarkeit und übersprungene/fehlerhafte Abdeckung sind im Bericht sichtbar.
• Befunde enthalten Schweregrad, Ort, reproduzierbare Beweise und begrenzte Behebungsanleitung.
• Artefakte enthalten keine neu offengelegten Geheimnisse oder ungeschwärzte sensible Payloads.
• Der Bericht unterscheidet einen bestandenen Scan von der Erlaubnis zur Förderung oder Freigabe.
• Unterdrückungen, Richtlinienänderungen, Baselines und Risikoakzeptanz erfordern explizites Urteil.
• Der Bericht endet nach Beweisen und enthält keine Fortsetzungsentscheidung.

Validierung

Die Kompetenz und die Redteam-Validierer ausführen:

bash skills/security/scripts/validate.sh
bash tests/scripts/test-security-suite-redteam.sh

Für einen begrenzten Suite-Smoke-Test eine eigene Binärdatei und ein temporäres Ausgabeverzeichnis verwenden, wie im Suite-Runbook gezeigt.

Beispiele

• Eine schnelle Sicherheitsanforderung führt das Repository-Gate einmal aus und meldet Abdeckung und Befunde.
• Eine vollständige Sicherheitsanforderung führt den vollständigen Scan einmal aus und bewahrt seine Artefakte.
• Eine autorisierte Binärdateianforderung kann in einem expliziten temporären Ausgabeverzeichnis eine Baseline erfassen.
• Eine Redteam-Anforderung kann das Offline-Angriffspaket über repository-eigene Oberflächen ausführen.

Fehlerbehebung

Problem	Antwort
Scanner fehlt/fehlerhaft	Abdeckungslücke aufzeichnen; installieren oder mit --require-tools erneut ausführen, wenn erforderlich
Lokal/CI-Unterschied	Scanner-Versionen, Konfiguration, Modus und beide Artefaktverzeichnisse vergleichen
Vermuteter Fehlalarm	Eng reproduzieren; jede autorisierte Unterdrückung und deren Besitzer dokumentieren
Suite/Baseline-Fehler	Das benannte Vergleichs-/Richtlinienartefakt überprüfen; Baseline niemals reflexartig aktualisieren
Redteam-Fehler nach Formulierungsänderung	Entscheiden, ob die Steuerung zurückgegangen ist oder der Angriffspaketabgleicher eine absichtliche Überarbeitung benötigt

Referenzdokumente

• references/security-suite-runbook.md — Befehle und Artefakte für Binärdateien/Richtlinien/Baselines/Redteam
• references/security.feature — Ausführbare Spezifikation des Repository-Gates
• references/security-suite.feature — Ausführbare Spezifikation der zusammensetzbaren Suite
• references/owasp-checklist.md — OWASP Top 10 Überprüfung
• references/agentops-redteam-pack.json — Offline-Angriffspaket
• references/policy-example.json — Starterrichtlinie