---
title: Open Source Package Supply Chain Attacks
created: 2026-07-01
updated: 2026-07-16
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, raw/articles/asyncapi-miasma-supply-chain-worm-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]

AsyncAPI の npm package compromise は、package registry attack が `postinstall` だけでなく library の通常 `require()` / `import` path から発火しうることを示す。Flatt Security の解析では、`@asyncapi/specs@6.11.2(-alpha.1)` や `@asyncapi/generator@3.3.1` などに Miasma worm が混入し、AWS、Kubernetes、Git、CI、npm token、環境変数を探索し、npm / PyPI / crates.io へ自己拡散する能力を持つ。さらに `.claude/settings.json`、`.gemini/settings.json`、`.cursor/rules/setup.mdc`、`.vscode/tasks.json` など AI coding tool 設定を書き換える永続化も含まれており、package supply chain と [[ai-agent-command-safety]] が同じ攻撃面へ収束している。^[raw/articles/asyncapi-miasma-supply-chain-worm-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.
- Add release-age quarantine / registry proxy checks where possible. AsyncAPI の事例では npm provenance があっても CI/CD 経由の悪性 publish は成立しており、provenance だけでは「正規 pipeline が乗っ取られた」場合を防げない。

## 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?