jpoindexter/security-skills

SAST-Scan

Abhängigkeitsaudits decken importierten Code ab; SAST deckt den Code ab, den Sie geschrieben haben. Es führt Pattern-Matching durch (und mit Taint-Mode auch Datenflussanalyse) für die klassischen Schwachstellen: Command-/SQL-Injection, Path Traversal, unsichere Deserialisierung, eval/dynamisches Exec auf nicht vertrauenswürdigen Eingaben, hartcodierte Kryptografie, fehlende Auth-Prüfungen. Eine hohe False-Positive-Rate ist inhärent – die Disziplin ist Triage nach Erreichbarkeit, nicht pauschales Ignorieren.

Wann ausführen

• Vor einem Release, auf dem Diff oder dem gesamten Baum.
• Wenn Sie Code hinzufügen, der nicht vertrauenswürdige Eingaben verarbeitet (ein neues Tool, einen Endpunkt, einen Parser, ein Shell-Out).
• In CI bei PRs (diff-bezogen, also schnell und kennzeichnet nur neue Probleme).

Ausführen

# semgrep — die Sicherheitsregelsets. `auto` wählt Regeln basierend auf den erkannten Sprachen.
semgrep scan --config auto --error .

# Fokussierte, signalstärkere Regelsets (weniger Rauschen als auto):
semgrep scan --config p/security-audit --config p/secrets --config p/command-injection .

# Nur Diff (CI bei einem PR — schnell, nur NEUE Funde):
semgrep scan --config auto --baseline-commit origin/main .

Für tiefergehende Datenflussanalyse (erreicht nicht vertrauenswürdige Eingaben tatsächlich die Senke?) ist CodeQL leistungsfähiger, aber schwerer:

codeql database create db --language=javascript    # oder rust, python, …
codeql database analyze db --format=sarif-latest --output=results.sarif \
  codeql/javascript-queries:codeql-suites/javascript-security-extended.qls

Triage — verfolgen, nicht verwerfen

Für jeden Fund verfolgen Sie den Quelle → Senke-Pfad:

1. Ist die Eingabe angreiferkontrolliert? Ein child_process.exec auf einer hartcodierten Konstante ist in Ordnung; auf einem Request-Parameter ist es ein Command-Injection-Fehler. semgrep markiert die Senke; SIE bestätigen die Quelle.
2. Gibt es einen Sanitizer dazwischen? Wenn der Wert vor der Senke validiert/escaped wird (ein Zod-Schema, eine Allowlist, eine parametrisierte Abfrage), handelt es sich um ein False Positive — markieren Sie es mit # nosemgrep: <rule-id> mit einer einzeiligen Begründung, nicht mit einem bloßen Ignorieren.
3. Echt? Beheben Sie die Quelle (Eingabe validieren/escapen) oder die Senke (parametrisieren, die sichere API verwenden), nicht durch Unterdrücken der Warnung.

Deaktivieren Sie niemals pauschal eine Regel, um die Liste zu bereinigen — Sie unterdrücken damit den einen echten Treffer im Rauschen. Unterdrücken Sie pro Zeile, mit einer Begründung.

Was tatsächlich beheben (höchster Wert zuerst)

• Injection (Command/SQL/Template) auf jedem benutzererreichbaren Pfad — die schwerwiegendste, am meisten ausgenutzte Klasse.
• Path Traversal — unvalidierte Pfade, die Datei-Lese-/Schreiboperationen erreichen (ein Agent, der Dateien schreibt, ist genau dieses Risiko; schalten Sie eine Bereichsprüfung vor).
• Unsichere exec/eval von dynamischen Zeichenketten.
• Hartcodierte Kryptografie / schwache Zufälligkeit in einem Sicherheitskontext.

Die Grenze

SAST sieht den Quellcode eines einzigen Repositorys statisch — es kann keine Laufzeitkonfiguration, einen umgebungsgesteuerten Codepfad oder einen Fehler sehen, der erst über eine Dienstgrenze hinweg auftritt. Es ergänzt, ersetzt aber nie ein echtes Bedrohungsmodell und [[dependency-audit]]. Für eine Agenten-/Tool-Laufzeitumgebung ist die stärkste Kontrolle oft architektonisch (ein Kernel, der jede Aktion absichert) statt zeilenweise — SAST validiert den Code UM diese Grenze herum. Binden Sie es in [[security-preflight]] ein.