add

concepts/open-source-package-supply-chain-attacks.md

@@ -0,0 +1,36 @@
+---
+title: Open Source Package Supply Chain Attacks
+created: 2026-07-01
+updated: 2026-07-02
+type: concept
+tags: [security, supply-chain, dev-tool, reliability]
+sources: [raw/articles/checkmarx-operation-navy-ghost-pyrogram-supply-chain-2026.md, raw/articles/ladybird-maintainer-only-development-ai-pr-risk-2026.md]
+confidence: medium
+---
+
+# Open Source Package Supply Chain Attacks
+
+Open source package supply chain attacks are compromises where the attacker does not need to break into a project or account: they can publish a plausible dependency, fork, plugin, or extension and wait for developers, bots, CI jobs, or production services to install it. This complements [[ci-cd-runtime-security]], which focuses on observing privileged automation while it runs, and [[scrutineer]], which focuses on human-gated vulnerability discovery and disclosure.
+
+## Operation Navy Ghost
+
+Checkmarx's Operation Navy Ghost report describes a PyPI campaign against Telegram bot developers using fake or trojanized `pyrogram` forks. Between November 2025 and June 2026, the attacker published packages such as `vlifegram`, `vlife-gram`, `kelragram`, `pyrogram-navy`, `pyrogram-styled`, `sepgram`, `pyrogram-zeeb`, and `pyrogram-kelra`. The packages looked like legitimate forks but included a hidden `pyrogram/helpers/secret.py` backdoor and modified startup paths.^[raw/articles/checkmarx-operation-navy-ghost-pyrogram-supply-chain-2026.md]
+
+The useful pattern is that the malicious code targeted bot/server environments rather than only local developer machines. It registered Telegram-controlled handlers for Python execution and shell execution, used Telegram itself as command-and-control and exfiltration, and included self-exclusion logic so the attacker's own accounts would not trigger the backdoor. For Yuta-style automation, this is a reminder that package choice, bot tokens, CI runners, and long-lived agent services share the same risk surface: once an installed dependency runs with credentials, network monitoring alone may not show the useful evidence.
+
+Ladybird の開発方針変更は、package registry ではなく open-source contribution path 側の trust model 変化を示す。Ladybird は AI tool によって「大きな patch を出す労力」が善意や長期関与の proxy ではなくなり、browser のように untrusted internet input を実行する project では、一つのよく隠れた脆弱性が深刻な結果を持つとして、public pull request を閉じ、maintainer だけが code を入れる方針へ移った。これは [[ci-cd-runtime-security]] や [[ai-agent-command-safety]] と同じく、AI が生成速度を上げたことで review capacity と responsibility boundary が希少資源になる例である。^[raw/articles/ladybird-maintainer-only-development-ai-pr-risk-2026.md]
+
+## Defensive implications
+
+- Treat dependency names and maintainers as part of the threat model, especially for forks of popular libraries.
+- Check installed packages and lockfiles for near-name variants, not only for known CVEs.
+- Prefer runtime evidence and containment when automation has credentials: process ancestry, file access, network destinations, and credential reads matter as much as static provenance.
+- For bot or agent services, rotate tokens and audit persistence if a malicious package may have run; the package may have accessed environment variables, sessions, files, or cloud credentials.
+- Link package-ingest checks with [[ai-agent-command-safety]]: agents can install dependencies, run examples, or execute project scripts, so package manager operations are command-execution boundaries, not just setup steps.
+- Treat generated-looking contribution volume as a review-capacity problem, not only a code-quality problem; projects may need narrower trusted committer paths when a disguised vulnerability is high impact.
+
+## Open questions
+
+- How should local agent sandboxes make package installation observable without making day-to-day development too slow?
+- Which package-registry trust signals are actually useful to an agent making autonomous install decisions?
+- Can CI/CD sensors and local agent logs share enough schema to reconstruct package-originated credential access after the fact?