GH Actions - npm Supply Chain Abuse

Overview

Bir attacker, bir GitHub Actions release workflow, maintainer workstation veya package build pipeline içinde code execution elde ettikten sonra, npm publishing yüksek etkili bir pivot haline gelir. Amaç genelde publisher kimlik materyalini çalmak, malicious sürümler publish etmek ve downstream installs’i daha fazla credential-generation node’una dönüştürmektir.

Tipik credential kaynakları:

~/.npmrc, NPM_TOKEN, registry sessions ve npm automation tokens.
GitHub PATs, GITHUB_TOKEN, release-bot credentials, SSH keys ve .netrc / git credential helpers.
id-token: write olan jobs içinde GitHub Actions OIDC request materyali (ACTIONS_ID_TOKEN_REQUEST_URL ve ACTIONS_ID_TOKEN_REQUEST_TOKEN).
Release environment içinde bulunan cloud credentials, Vault tokens, Kubernetes service account tokens ve .env dosyaları.

Install-Time Execution Primitives

Lifecycle hooks

Klasik npm yolu, preinstall, install, postinstall veya prepare script’leriyle malicious bir package version publish etmektir. Version’ı install eden herhangi bir developer workstation veya CI job, attacker-controlled code çalıştırır.

{
"scripts": {
"postinstall": "node ./scripts/collect.js"
}
}

Defenders often monitor these scripts, so red-team incelemeleri ayrıca daha az belirgin execution path’leri de denetlemelidir.

`binding.gyp` / node-gyp execution (Phantom Gyp)

Her install-time execution path package.json lifecycle hooks içinde yer almaz. node-gyp'nin configure step’i, package directory içinde bir binding.gyp file arar; bu yüzden compromised publisher execution’u native build path’e kaydırabilir ve yalnızca preinstall / postinstall denetleyen controls’u bypass edebilir.

Practical checks:

Published tarball’ı, sadece Git repo’yu değil, unexpected binding.gyp, node-gyp, veya native-addon metadata için kontrol edin; özellikle pure JavaScript olması gereken packages içinde.
Ani bir binding.gyp eklenmesini bir execution primitive olarak değerlendirin, özellikle defenders lifecycle-hook monitoring veya --ignore-scripts’e güveniyorsa.
Untrusted artifacts/caches restore edildikten sonra npm install, npm rebuild, veya dependency build steps çalıştıran release jobs’ları inceleyin.

Wormable npm Publishing

Bir maintainer workstation veya release workflow içinde code çalışmaya başladıktan sonra, tek bir stolen registry identity kendi kendini yayan package compromise’a dönüştürülebilir:

Maintainer secrets’lerini toplayın (~/.npmrc, PATs, OIDC request env vars, cloud creds, SSH keys).
Compromised identity veya team’in publish edebildiği packages’ları enumerate edin.
Writable olan her package üzerinde malicious versions’ları yeniden publish edin.
Downstream installs’ın daha fazla credential-generation node oluşturmasına izin verin.

Compromised bir npm identity’den faydalı enumeration:

npm whoami
npm access ls-packages
npm access ls-collaborators <scope-or-package>

Saldırganlar genellikle sık CI install alan, transitive popülerliği yüksek veya zararlı sürümü hızlıca install edecek release automation olan packages'leri tercih eder.

Trusted Publishing ve Provenance Sınırları

Trusted publishing/OIDC, uzun ömürlü static npm tokens'ları kaldırır, ancak compromise olmuş bir release workflow'u güvenli hale getirmez. Eğer attacker, id-token: write olan bir job içinde çalışan code'u kontrol ediyorsa, legitimate workflow gerçekten bunu build edip publish ettiği için malicious release yine de geçerli provenance alabilir.

Provenance şu soruyu yanıtlar: bu artifact'i hangi workflow build etti, şu soruyu değil: workflow, source tree, cache veya build steps temiz miydi.

Yüksek sinyal veren review noktaları:

id-token: write ile npm publish, pnpm publish, changesets, release bots veya custom publish wrappers'ı birleştiren workflows.
Publish etmeden önce düşük güvenli workflows'dan cache'leri veya artifacts'ları restore eden release jobs.
Human approval, environment protection rules veya ikinci bir reviewer olmadan publish eden jobs.
Tüm build inputs doğrulanmadan önce OIDC isteyen workflows.

Hardening

Static npm tokens yerine trusted publishing/OIDC kullanın; ancak bunu sensitive scopes için protected environments ve human approval ile eşleştirin.
Mümkün olan yerlerde high-impact packages için staged publishing / human 2FA approval ekleyin.
Yeni yayınlanan package sürümlerini consume etmeden önce minimumReleaseAge veya eşdeğer dependency quarantine kontrolleri kullanın.
Cache keys'i trust boundary'ye göre ayırın ve integrity checks yapılmadan restored cache contents'i asla execute etmeyin.
Published tarballs'ı source repositories ile diff edin ve binding.gyp gibi beklenmeyen native build metadata için alert üretin.
Build'lerin ihtiyaç duymadığı yerlerde lifecycle scripts'i CI'da disable edin veya sıkı şekilde review edin (npm config set ignore-scripts true).
Package access'i izleyin (npm access ls-packages) ve stale maintainers, bots ve teams'i kaldırın.

5.8 KiB Raw Blame History Unescape Escape