hadifarnoud/supply-chain-security

Supply-Chain-Sicherheitsstandards

Gilt für alle Projekte. Regeln überprüft am 2026-11-11 (nach Shai-Hulud / Mini Shai-Hulud-Wurm).

---

Maschinenweite Voreinstellungen (~/.npmrc)

minimum-release-age=1440        # pnpm only — MINUTEN (1440 = 24h)
min-release-age=1               # npm 12+ only — TAGE  (1 = 24h)

Die beiden Paketmanager verwenden unterschiedliche Schlüsselnamen UND unterschiedliche Einheiten. Überprüft 2026-08-21 durch Lesen des Quellcodes jedes Tools: pnpm berechnet Date.now() - minimumReleaseAge * 60 * 1e3 (Minuten); npms Konfigurationsdefinition für min-release-age führt hint: '<days>'. Beide Zeilen sind erforderlich – eine deckt die andere nicht ab, und das Kopieren von 1440 in den npm-Schlüssel würde 1440 Tage bedeuten und im Wesentlichen jede Installation blockieren.

npm gibt Unknown user config "minimum-release-age" bei der Installation aus und warnt, dass dies in einer zukünftigen Hauptversion nicht mehr funktionieren wird. Dies ist unvermeidbar, solange der Schlüssel in ~/.npmrc lebt: pnpm 11 hat das globale Konfigurationsschreiben entfernt (pnpm config set --global leitet jetzt zu einer projektspezifischen pnpm-workspace.yaml um), daher ist ~/.npmrc der einzige Ort, an dem ein globaler pnpm-Gate leben kann. Akzeptieren Sie die Warnung; löschen Sie den Schlüssel nicht.

Verlassen Sie sich nicht auf diese – als unwirksam bestätigt

• block-exotic-subdependencies – kommt weder im Quellcode von npm noch von pnpm vor. Es hat nie etwas bewirkt. Exotische Abhängigkeiten müssen durch Überprüfung abgefangen werden, nicht durch diesen Schlüssel.

• ignore-scripts=true – dieses Skill hat zuvor behauptet, es sei global gesetzt. Es ist nicht gesetzt, und npm config get ignore-scripts gibt false zurück, daher führen Lebenszyklus-Skripte doch bei der Installation aus.

  Entschieden 2026-08-21: Lassen Sie es aus. Aktivieren Sie es nicht. Postinstall ist der primäre npm-Kompromittierungsvektor, also ist dies eine bekannte, akzeptierte Lücke – kein Versehen, das behoben werden muss. Das globale Aktivieren bricht native Builds (esbuild, swc, sharp, node-gyp) in jedem Projekt, und die Fehler treten fern der Ursache auf. Der 24-Stunden-Release-Age-Gate oben trägt dieses Risiko stattdessen. Wenn ein bestimmtes Projekt jemals Skriptisolierung benötigt, begrenzen Sie es dort – niemals global.

Überprüfen Sie Behauptungen wie diese gegen das Tool und nicht gegen diese Datei – alle drei Einträge hier waren zum Zeitpunkt des Audits falsch.

---

Supply-Chain-Angriffstaxonomie (Referenz vor dem Audit)

1. Typosquatting / Dependency Confusion

Paketname nahezu identisch mit einem populären, oder ein öffentliches Paket, das einem internen Scoped-Namen entspricht. 454.648 bösartige npm-Pakete allein im Jahr 2025 veröffentlicht. Erkennung: npm info <pkg> | grep -E 'created|repository' bei unbekannten Paketen. Querverweis mit internen Registry-Namen.

2. Maintainer Account Takeover

Angreifer phisht einen Maintainer, veröffentlicht eine neue Version mit einem Postinstall-Payload. Shai-Hulud Sept. 2025 traf chalk, debug, ansi-styles (2,6 Mrd. wöchentliche Downloads). Axios (100 Mio.+/Woche) getroffen März 2026 via nordkoreanische Social-Engineering. Erkennung: npm diff <pkg>@<letzter-bekannter-guter> <pkg>@latest -- package.json scripts – prüfen Sie auf neue Lebenszyklus-Skripte, die in Patch-Versionen hinzugefügt wurden.

3. Repo Jacking / Namespace Squatting

Angreifer registriert einen verlassenen GitHub-Benutzernamen oder npm-Namespace, erstellt das Repo neu, serviert bösartigen Code. Erkennung: Prüfen Sie das repository-Feld in package.json; markieren Sie GitHub-Konten, die nach dem ersten npm-Veröffentlichungsdatum des Pakets erstellt wurden.

4. CI/CD Pipeline Injection (pull_request_target / Cache Poisoning)

Angreifer eröffnet einen PR gegen ein Repo mit pull_request_target, das einen Cache mit einem privilegierten Publish-Job teilt. Vergiftet den pnpm-Store; der nächste Release-Workflow gibt das npm-OIDC-Token preis. TanStack-Vektor (Nov. 2025, Mini Shai-Hulud Mai 2026, 300+ Pakete, 16 Mio. wöchentliche Downloads). Erkennung:

grep -r "pull_request_target" .github/workflows/
grep -r "cache" .github/workflows/ | grep -i "pnpm\|npm\|store"

Harte Regel: Verwenden Sie niemals pull_request_target, wenn der Workflow PR-Code auscheckt oder einen Cache mit einem privilegierten Job teilt.

5. Docker Image Poisoning

Angreifer kompromittiert Docker-Hub-Zugangsdaten und überschreibt bestehende Image-Tags (einschließlich latest) mit bösartigen Binärdateien. Trivy aquasec/trivy-Tags 0.69.4–0.69.6 und latest vergiftet März 2026. KICS April 2026 – fünf Tags überschrieben; scannt Terraform/K8s-Konfigurationen, die Geheimnisse enthalten. Erkennung: docker inspect <image> --format '{{.Id}}' vs. einen gepinnten Digest in der Konfiguration. Harte Regel: Pinnen Sie alle Images auf @sha256:-Digest. Verwenden Sie niemals latest für Sicherheitstool-Images.

6. GitHub Actions Tag Re-Pointing

Angreifer kompromittiert das Token eines Action-Maintainers, verschiebt einen bestehenden Version-Tag, um auf bösartigen Code zu verweisen. tj-actions/changed-files CVE-2025-30066 (März 2025, 23.000+ Repos) hat alle CI-Geheimnisse in Logs ausgegeben. Mai 2026: populäre Action-Tags auf Impostor-Commits umgeleitet. Erkennung:

grep -r "uses:.*@v[0-9]" .github/workflows/   # markiert Tag-gepinnt (schlecht)
grep -r "uses:.*@[a-f0-9]\{40\}" .github/workflows/  # SHA-gepinnt (korrekt)

Harte Regel: Pinnen Sie jede Drittanbieter-Action auf einen vollständigen 40-Zeichen-Commit-SHA, nicht auf einen Version-Tag. actions/* (First-Party) dürfen Hauptversion-Tags verwenden.

7. Lockfile Tampering / Integrity Bypass (PackageGate-Klasse)

Angreifer modifiziert die Lockfile, um eine bösartige Paketversion zu ersetzen oder Integritäts-Hashes zu entfernen, sodass die nächste Installation stillschweigend ein anderes Tarball abruft. Sechs Zero-Day-Lockfile-Schwachstellen dokumentiert Jan. 2026 (Koi Security). Erkennung:

grep -E '"resolved".*git\+|tarball' package-lock.json pnpm-lock.yaml
grep -v "integrity" pnpm-lock.yaml | grep "resolved"

Harte Regel: CI muss pnpm install --frozen-lockfile oder npm ci verwenden – niemals bare npm install.

8. Subdependency Shadowing

Angreifer zielt auf eine 3+ Ebenen tiefe transitive Abhängigkeit. @ctrl/tinycolor war ein Shai-Hulud-Ausbreitungsknoten. Erkennung: npm ls --all 2>/dev/null | grep -E "postinstall|preinstall". Verwenden Sie socket scan bei PRs.

9. Social Engineering Maintainer Handoff

Angreifer gibt sich als Personalvermittler oder Geschäftspartner aus, um npm-Publish-Rechte zu erhalten. UNC1069 (Nordkorea) zielte im März 2026 auf den Axios-Maintainer, versuchte es auch gegen den Socket-CEO, Lodash-Ersteller, Fastify-Lead. Erkennung: npm owner ls <pkg> für kritische Abhängigkeiten; überwachen Sie auf neue Mitarbeiter vor einem verdächtigen Release.

10. Protestware (Intentional Maintainer Sabotage)

Maintainer injiziert absichtlich destruktiven Code. colors.js v1.4.44–1.4.2 (Jan. 2022, Endlosschleife), node-ipc v10.1.1–10.1.3 (März 2022, gelöschte Dateien auf russischen IPs). Drei neue bösartige node-ipc-Versionen Mai 2026. Erkennung:

npm diff <pkg>@<vorher> <pkg>@<neu> -- lib/
grep -r "networkInterfaces\|geoip\|fs.rmdir\|fs.unlink" node_modules/<pkg>/

Pinnen Sie node-ipc, colors, faker auf exakte bekannte gute Versionen.

11. Wurmartige Selbstreplizierende Malware

Payload stiehlt npm-Token/PATs und veröffentlicht autonom bösartige Versionen anderer Pakete, die das Opfer verwaltet. Erstmals beobachtet Shai-Hulud Sept. 2025; Mini Shai-Hulud Mai 2026 (300+ Pakete, 16 Mio. wöchentliche Downloads, npm + PyPI gleichzeitig). Erkennung IOCs:

find .github/workflows -name "*.js"            # bundle.js in Workflows
grep -ri "shai-hulud" .                        # Wurm-String
find node_modules -name "data.json" -newer package.json  # Exfiltrations-Staging
find node_modules -name "cloud.json"

12. Ruhende / Umgebungsabhängige Payloads

Payload aktiviert sich nur, wenn AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN oder CI=true vorhanden sind – umgeht Sandbox-Scanner. Erkennung:

grep -r "process.env.AWS_SECRET\|process.env.GITHUB_TOKEN\|process.env.NPM_TOKEN" node_modules/

Markieren Sie jedes Paket, das diese Variablen liest, ohne legitimen Grund dazu.

13. Sicherheitstool als Angriffsvektor

Angreifer zielen gezielt auf Sicherheits-Scanning-Tools (Trivy, KICS, Semgrep), da diese mit erhöhtem Zugriff auf Geheimnisse und Infrastrukturkonfiguration in CI laufen. Trivy und KICS wurden beide März–April 2026 getroffen. Harte Regel: Pinnen Sie alle Sicherheitstool-Docker-Images auf Digest, nicht auf Tag. Überprüfen Sie Digests out-of-band gegen die Release-Notizen des Anbieters.

14. Nicht-Registry- / CDN-Abhängigkeiten

Pakete, die von Git-URLs, GitHub-Tarballs oder benutzerdefinierten CDNs (z. B. cdn.sheetjs.com) aufgelöst werden, umgehen Registry-Sicherheitsgates und Provenance und werden auch nicht vom Release-Age-Gate abgedeckt – es gilt nur für Registry-Versionen. Einigen fehlen Integritäts-Hashes vollständig. Nichts blockiert diese automatisch; sie müssen in der Überprüfung abgefangen werden. Erkennung:

grep -E '"resolved".*github\.com|cdn\.' package-lock.json pnpm-lock.yaml
grep -E '"version":\s*"(git\+|https?:)' package.json

---

Projektbezogene npm/pnpm-Hygiene

• Lockfiles festschreiben. CI muss pnpm install --frozen-lockfile (oder npm ci) verwenden. Niemals bare npm install in CI.
• packageManager in package.json pinnen, um die pnpm/npm-Version zu fixieren.
• Pakete in kompromittierten Namespaces auf exakte Versionen pinnen: @tanstack/*, posthog-node, @mistralai/*, @langchain/mistralai, @ctrl/*, ngx-*, rxnt-*, @zapier/*, @postman/*, @uipath/*, agent-mcp, @semgrep/*, node-ipc, colors, faker.
• Keine Wildcard "*"-Versionen in package.json.
• Keine pkg.pr.new-URLs – dies sind flüchtige PR-Vorschau-Builds, keine unveränderlichen Artefakte.
• Für npm/yarn-Projekte spiegeln Sie die gleichen npmrc-Gates in ihrer lokalen .npmrc wider.
• Bevorzugen Sie pnpm für neue Projekte. Migrieren Sie keine funktionierenden Projekte nur aus Sicherheitsgründen.

---

GitHub Actions-Härtung

Harte Regeln

• Niemals pull_request_target verwenden, wenn der Workflow PR-Code auscheckt, install/build/test aus PR-Code ausführt oder einen Cache mit einem privilegierten Workflow teilt.
• pull_request_target ist nur akzeptabel zum Lesen von PR-Metadaten (Labels, Kommentare, Titel) ohne Checkout.
• Teilen Sie keine Caches zwischen PR-ausgelösten Jobs und Publish/Release-Jobs.
• Niemals curl | bash oder wget | sh gegen einen veränderlichen Branch (@main, @master) in CI. Pinnen Sie Installationsskripte immer auf eine bestimmte Version und überprüfen Sie eine Prüfsumme.

workflow_run-Wächter

Bei Verwendung von workflow_run, um einen privilegierten Job nach einem übergeordneten Workflow zu verketten, MUSS if: alle folgenden Bedingungen enthalten:

if: >
  github.event_name == 'workflow_dispatch' ||
  (github.event.workflow_run.conclusion == 'success' &&
   github.event.workflow_run.head_branch == 'main' &&
   github.event.workflow_run.head_repository.full_name == github.repository &&
   github.event.workflow_run.event == 'push')

Action-Pinning

• Pinnen Sie jede Drittanbieter-Action auf einen vollständigen 40-Zeichen-Commit-SHA, nicht auf @v1/@v6.
• Fügen Sie einen Kommentar mit dem menschenlesbaren Tag zur Prüfbarkeit hinzu: docker/login-action@65d0a9e # v3
• First-Party actions/* dürfen Hauptversion-Tags verwenden.
• Aktuelle SHAs abrufen: gh api repos/<owner>/<action>/git/ref/tags/<tag>
• Automatisieren mit: npx pin-github-action .github/workflows/*.yml
• Minimieren Sie permissions: pro Job. Standardmäßig contents: read. Fügen Sie id-token: write nur im Publish-Schritt hinzu.

npm-Publishing-Workflows

• Erfordern Sie 2FA auf dem npm-Konto: npm profile enable-2fa auth-and-writes.
• Verwenden Sie Trusted Publishing (OIDC) anstelle von langlebigen NPM_TOKEN-Geheimnissen.
• Fügen Sie --provenance (oder provenance: true) hinzu, damit Verbraucher die Herkunft überprüfen können.
• Veröffentlichen Sie nur von einer release.yml, die durch einen Tag-Push auf main ausgelöst wird. Niemals von PR-ausgelösten Workflows.

---

Docker/Container-Hygiene

• Pinnen Sie jedes FROM auf einen Digest: FROM node:22-slim@sha256:<hash>
• Verwenden Sie niemals latest oder Images ohne Tag in Produktions-Dockerfiles oder CI.
• Sicherheitstool-Images (Trivy, KICS, Semgrep, Snyk, Grype, Hadolint) haben das höchste Risiko – pinnen Sie diese zuerst.
• Aktuelle Digests abrufen: docker buildx imagetools inspect node:22-slim --format '{{json .Manifest.Digest}}'
• Für private Registry-Images: Mit unveränderlichen Tags + Digests veröffentlichen.

---

Entwickler-Tools & Konfigurationsdateien

• Speichern Sie niemals API-Tokens oder Geheimnisse im Klartext in ~/.cursor/mcp.json, ~/.claude/settings.json oder ähnlichen Konfigurationsdateien. Verwenden Sie Umgebungsvariablen oder eine Schlüsselverwaltung.
• Pinnen Sie MCP-Server-Pakete auf exakte Versionen ([email protected], nicht mcp-remote@latest).
• Überprüfen Sie ~/.vscode/tasks.json und ~/.cursor/ auf unerwartete Auto-Run-Hooks nach einem Supply-Chain-Vorfall.

---

Erkennung / Überwachung

• Installieren Sie zizmor oder snyk-labs/github-actions-scanner in CI für jedes Repo mit Workflows.
• Fügen Sie socket.dev GitHub App in jedem Repo hinzu, das Pakete veröffentlicht (jede veröffentlichbare Bibliothek).
• Abonnieren Sie npm-Sicherheitsadvisory-RSS und PyPI-Malware-Feeds.

IOC-Schnellcheck-Liste

# Shai-Hulud / Wurm-IOCs
grep -ri "shai-hulud" .
find .github/workflows -name "*.js"
find node_modules -name "cloud.json"
# Kompromittierte Workflow-Muster
grep -r "pull_request_target" .github/workflows/
grep -r "curl.*|.*sh\|wget.*|.*sh\|base64.*eval" .github/workflows/
# Nicht-gepinnte Actions
grep -r "uses:.*@v[0-9]" .github/workflows/
# Lockfile-exotische Abhängigkeiten
grep -E '"resolved".*git\+|cdn\.' package-lock.json pnpm-lock.yaml
grep -v integrity pnpm-lock.yaml | grep resolved
# Docker
grep -r "FROM.*:latest\|FROM.*[^@]$" Dockerfile* docker-compose*.yml

---