5.3 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Open Source Package Supply Chain Attacks | 2026-07-01 | 2026-07-16 | concept |
|
|
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/[email protected](-alpha.1) や @asyncapi/[email protected] などに 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?