byteratio/security-sweep

Sicherheitsscan

Beantworte eine Frage gut: Sind diese Projekte einer Abhängigkeitslücke ausgesetzt, die gerade jetzt relevant ist? „Relevant“ bedeutet entweder katalogisiert und erreichbar oder ein aktueller Vorfall, der sich noch nicht vollständig in den Prüfdatenbanken niedergeschlagen hat.

Der Mehrwert gegenüber einem einfachen npm audit liegt in der Recherche-Ebene. Beratungsdatenbanken hinken Offenlegungen hinterher, und Vorfälle mit bösartigen Paketen werden oft durch Löschen der Pakete behoben (es gibt keine abfragbare Warnung). Daher kombiniert dieser Scan die deterministischen Werkzeuge mit Live-Recherchen zu aktuell ausgenutzten Schwachstellen und prüft die Lockfile direkt auf diese Namen – das schnellste zuverlässige Signal, das kein Prüfwerkzeug liefert.

Standardmäßig schreibgeschützt: Dies untersucht und berichtet. Schlagen Sie nur Reparaturen vor; wenden Sie keine Versions-Upgrades ohne Zustimmung des Benutzers an (sie können Builds zerstören).

Wann verwenden

• „Sicherheit untersuchen“ / „Auf verwundbare Abhängigkeiten prüfen“ / „Einen Sicherheitsscan durchführen.“
• „Sind wir von <einer benannten CVE, GHSA oder einem Paket-Kompromiss-Vorfall> betroffen?“ – der Benutzer hat etwas gelesen und möchte wissen, ob er exponiert ist.
• Eine regelmäßige Überprüfung (kombinieren mit dem schedule-Skill für einen wiederkehrenden Cloud-Scan – siehe Ende).

Schritt 1 – Umfang

Lege fest, was gescannt werden soll. Standardmäßig das aktuelle Projekt; biete einen Scan über mehrere Repos an, wenn die Formulierung des Benutzers breit gefasst ist („unsere Projekte“, „alles“, „die gesamte Flotte“).

• Aktuelles Projekt: das Repo, in dem du dich befindest.
• Mehrere Repos: Liste die benachbarten Repos neben dem aktuellen auf – d.h. das übergeordnete Verzeichnis des aktuellen Git-Roots (normalerweise ~/projects/*/ oder ~/src/*/). Bestätige das Verzeichnis mit dem Benutzer, bevor du es durchläufst, anstatt es anzunehmen; eine falsche Annahme verschwendet einen langen Scan. Erkenne für jedes Repo die Ökosysteme anhand des Manifests (unten), führe nacheinander einen Scan durch und berichte pro Projekt.

Schritt 2 – Ökosysteme erkennen und Lockfiles lokalisieren

Pro Projekt ist ein Ökosystem vorhanden, wenn seine Lockfile existiert:

Ökosystem	Manifest / Lockfile	Üblicher Speicherort
npm	package-lock.json	frontend/ oder Repo-Root
Go	go.mod / go.sum	backend/ oder Repo-Root
Python	poetry.lock, requirements.txt, uv.lock	Repo-Root
Swift/SPM	Package.resolved	ios/ oder ein .xcodeproj

Die Lockfile – nicht das Manifest – wird gescannt: Sie fixiert die exakten transitiven Versionen, die tatsächlich installiert sind.

Schritt 3 – Deterministische Basisprüfung (pro Ökosystem)

Führe die eigenen Werkzeuge des Ökosystems aus. Diese erfassen alles, was bereits in den Beratungsdatenbanken ist. Bevorzuge Werkzeuge mit Reachability-Analyse (sie melden nur Schwachstellen, die dein Code tatsächlich erreichen kann), sofern verfügbar.

• npm: cd <dir> && npm audit --omit=dev --audit-level=high (was an Benutzer ausgeliefert wird) und ein einfaches npm audit (alles, informativ). Keine Reachability – übermeldet; gewichte Produktions-Funde.
• Go: govulncheck ./... – hat eine Reachability-Analyse (meldet nur Schwachstellen in aufgerufenem Code); einmalig installieren mit go install golang.org/x/vuln/cmd/govulncheck@latest. Der Goldstandard dieser Werkzeuge.
• Python: pip-audit (oder pip-audit -r requirements.txt).
• Jedes Ökosystem oder wenn ein Werkzeug fehlt: osv-scanner gegen die Lockfile, ausgeführt in einem Container, damit nichts installiert werden muss: <runtime> run --rm -v "$PWD:/src:ro" ghcr.io/google/osv-scanner:latest scan --lockfile=/src/<lockfile>. Breiteste Datenbank; der Fallback für Swift/SPM, das dünne Erstanbieter-Werkzeuge hat.

Erfasse, was jedes meldet. Unterscheide Produktion/erreichbar von Dev/Build-Zeit – ein hoher Eintrag in einem Build-Werkzeug, das niemals ausgeliefert wird, ist nicht dasselbe wie in einer Laufzeit-Abhängigkeit.

Schritt 4 – Aktuelle Bedrohungslandschaft recherchieren (der Mehrwert)

Das kann ein reiner Audit nicht leisten. Verwende WebSearch / WebFetch, um herauszufinden, was derzeit aktiv ist, und bringe die Namen dann zu Schritt 5 zurück.

• Aktuelle Supply-Chain-Vorfälle in den Ökosystemen des Projekts: Suche nach aktuellen npm-/PyPI-/Go-Kompromittierungen und Malware-Kampagnen; überprüfe die GitHub Advisory Database (github.com/advisories) und OSV (osv.dev) auf kürzlich veröffentlichte Einträge, die Pakete betreffen, die du in Schritt 2 gesehen hast.
• Wenn der Benutzer eine bestimmte CVE / GHSA / einen bestimmten Vorfall genannt hat, rufe die maßgebliche Beratungsmeldung ab und extrahiere die exakten betroffenen Paketnamen und Versionsbereiche – das wird dann gegen die Lockfile abgeglichen.
• Bevorzuge Primärquellen (die Beratungsmeldung, der Beitrag des Maintainers, die Sicherheitsmitteilung der Registry) gegenüber zusammenfassenden Headlines; notiere, wenn etwas unbestätigt ist.

Halte es aktuell: Datumsstempel für jede Behauptung, und gib an, was dein Recherchezeitfenster war (z.B. „aktive Vorfälle, die in den letzten ~8 Wochen offengelegt wurden“).

Schritt 5 – Namen direkt gegen die Lockfile abgleichen

Für jedes in Schritt 4 gefundene Paket warte nicht auf das Prüfwerkzeug – überprüfe den gefixten Baum selbst. Dies ist der führende Indikator-Schritt:

# npm
cd <dir> && npm ls <package>
grep -n '"<package>"' package-lock.json
# Go
grep -n '<module-path>' go.sum
# Python
grep -in '<package>' poetry.lock requirements.txt uv.lock 2>/dev/null
# Swift
grep -rn '<package>' --include=Package.resolved .

Vergleiche dann die gefixte Version mit dem betroffenen Bereich aus der Beratungsmeldung. Drei Ergebnisse pro Name: exponiert (vorhanden und im Bereich), klar (nicht vorhanden oder vorhanden, aber außerhalb des Bereichs), unsicher (transitive Version, die nicht vollständig aufgelöst werden konnte – tiefer graben oder markieren).

Schritt 6 – Bericht

Pro Projekt führe mit dem Befund, dann den Beweisen:

• Exponiert – Paket, gefixte Version, Beratungsmeldung/Vorfall, ob es produktionserreichbar ist, und eine konkrete Abhilfemaßnahme (gezielter Versions-Upgrade; niemals ein blindes npm audit fix). Wenn eine kompromittierte Version möglicherweise installiert wurde, weise darauf hin, dass ihr Postinstall-Skript bereits ausgeführt worden sein könnte – der Hauptgrund, warum ein ignore-scripts-Standard wichtig ist.
• Klar – die recherchierten aktiven Bedrohungen wurden überprüft und sind nicht vorhanden. Sage, was überprüft wurde, damit „klar“ etwas bedeutet.
• Unsicher / nicht abgedeckt – Ökosysteme mit dünnen Werkzeugen (Swift), unaufgelöste transitive Abhängigkeiten oder Recherchen, die einen Bereich nicht bestätigen konnten. Benenne die Lücke, anstatt vollständige Abdeckung zu implizieren.

Gib nicht vor, alles gefunden zu haben. Gib das Zeitfenster und die tatsächlich gescannten Ökosysteme an.

Kombinieren

• Wiederkehrender Scan: Übergib die Vorgehensweise dieses Skills an den schedule-Skill für einen wöchentlichen Cloud-Lauf über die Repos, sodass ein neuer Vorstand innerhalb von Tagen erkannt wird, anstatt erst, wenn jemand das nächste Mal daran denkt.
• Vor einem Release oder einem Push: Führe einen eingeschränkten Scan eines einzelnen Projekts durch. Er passt natürlich zu einem make audit / make secret-scan Pre-Push-Schritt, falls das Projekt einen solchen hat.

Anmerkungen

• Prüfwerkzeuge sind nachlaufende Indikatoren; die Nachrichten und Schritt 4 dieses Skills sind die führenden. Wenn diese widersprüchlich sind – die Recherche sagt, ein Paket sei kompromittiert, aber die Werkzeuge schweigen – vertraue der direkten Lockfile-Prüfung und behandle es als live.
• npm audit meldet die Schwere der Beratungsmeldung, nicht deine Ausnutzbarkeit (keine Reachability-Analyse) – es übermeldet. govulncheck ist das Gegenteil und das Modell, das bevorzugt werden sollte, wenn ein Ökosystem es anbietet.
• Dieser Skill beantwortet die Exposition. Abhilfemaßnahmen (Versions-Upgrades, Fixierung, npm rebuild für eine spezielle Script-Ausnahme) sind ein separater, vom Benutzer genehmigter Schritt – zeige die Lösung an, wende sie nicht unaufgefordert an.