dependency management
该标签下有 7 篇文章
Ethersphere bee-js 13.3.0 和 Swarm Desktop 0.56.2 带有恶意软件（2026年11月）：受影响版本以及用户该怎么做
去中心化存储网络 Swarm 的开发方 Ethersphere 的 npm 包 @ethersphere/bee-js 的 13.3.0 版本包含恶意代码。2026年11月9日发布的 GitHub 公告（GHSA-hh7j-5m3j-23pf）把 13.3.0 列为唯一受影响的版本，并称没有已修补的版本。公告称，凡是安装或运行了该包的计算机，都应视为已被完全攻陷，其中所有的机密和密钥应立即从另一台计算机上轮换。删除该包可能无法清除安装所带来的全部恶意软件。至于 Swarm Desktop，Ethersphere 的发布说明称，11月9日发布的 0.56.3 取代了被攻陷的 0.56.2。据一家安全公司的分析，bee-js 13.3.0 于11月9日协调世界时约 00:09（日本时间 09:09）出现在 npm 上，约 75 分钟后被撤下。Swarm Desktop 0.56.2 公开了约 8.5 小时，并且通过自动更新送达了 Windows x64 和 Apple Silicon。据报告，bee-js 13.2.0 及更早版本以及 Swarm Desktop 0.56.1 不受影响。同一分析称，Bee 节点的配置文件（其中有明文密码）及其钱包密钥是目标，官方发布自动化所使用的凭据也被滥用。我们的结论：请重建安装过受影响版本的机器或 CI 环境，把钱包迁移到新密钥并转移资金，并从另一台机器上轮换凭据。
LiteLLM 1.107.0 带有凭据窃取程序（2026 年 10 月）：受影响的 PyPI 版本与 Docker 镜像，以及用户该怎么做
2026 年 10 月 21 日（UTC），LiteLLM 背后的公司 BerriAI 宣布其发布流水线遭到入侵，并发布了一个含有恶意软件的 v1.107.0，该恶意软件会窃取凭据并加载远程代码执行工具。受影响的有：PyPI 上的 litellm==1.107.0（11:39 至 13:23 UTC），以及 Docker Hub 上的 v1.107.0、latest、main-latest 和 main-stable 标签（11:46 至 14:20 UTC）和 GHCR 上的同名标签（自 11:46 UTC 起，至 13:51 UTC 前下架，约两小时）。GitHub 上官方的 v1.107.0 源码标签不含恶意文件；这些构建产物是由攻击者控制的仿冒仓库构建的。所有更早的版本都不在此次入侵范围内，公司请用户固定使用 1.106.2 或其他明确指定的更早版本。10 月 24 日（UTC），公司发布了 1.103.8、1.104.6、1.105.4 和 1.106.3，从这些版本起，Docker 镜像和 Helm chart 使用新的 cosign 密钥签名（旧密钥已无法验证）。10 月 23 日，公司发布了根因分析，并更正了最初认为令牌是从内部 LiteLLM 部署的日志中被获取的判断。根据该分析，5 月 27 日一个配置文件被误提交到公开仓库，其中包含某个内部智能体平台的主密钥；该提交被覆盖，但密钥从未被吊销。10 月 10 日，攻击者用该密钥调用该平台的 API，获得了配置在其中的某位 GitHub 组织所有者的 GitHub CLI 令牌。攻击者借此窃取了 CI 机密，进而获得另外两位维护者的令牌，并在 10 月 21 日关闭了分支保护、修改了发布工作流并批准了发布。本站结论：凡是在该时间窗口内安装或启动过 1.107.0 的环境，都应重建，并轮换其可触及的所有密钥，包括 LLM 提供商密钥、代理主密钥、数据库密码和云角色。
osv-scanner 实战：pnpm 支持、忽略 CVE、离线模式与常见错误
只回答装好之后才会遇到的问题，全部依据官方文档。pnpm-lock.yaml 受支持；忽略规则写在 osv-scanner.toml 的 IgnoredVulns 下，并可以设置期限；离线模式是三个作用各不相同的参数。本站的看法：扫描器报告的是已知漏洞，对你自己固定的版本变旧这件事什么也不会说，这需要另外的机制。
Express（Node.js）安全 —— 生产环境加固实务参考
Express 是极简框架 —— 默认几乎不守护任何东西，防御要靠你自己添加。本页是一份可上手的实务参考：(1) 按优先级排序的加固清单（P0–P2），(2) 分领域的具体对策 —— 安全响应头（helmet）+ 禁用 x-powered-by、npm 依赖 CVE、输入校验与注入（SQL/NoSQL 运算符）、认证与所有者范围授权、限流与大小上限、会话/Cookie/CSRF、SSRF、生产错误处理（不暴露堆栈）、NODE_ENV，以及 (3) 自查清单。仅讲防御，不含攻击步骤。
Next.js 安全 — 生产环境加固实务参考
Next.js 的默认配置相当安全，但事故发生在服务端/客户端的边界上。本页是一份可上手的实务参考：(1) 按优先级排序的加固检查清单（P0–P2）；(2) 分领域指南——边界与环境变量（NEXT_PUBLIC_）、依赖 CVE（含核心 RCE）、Server Actions / Route Handlers 的授权 + 输入校验、服务端 fetch 的 SSRF、安全响应头/CSP、认证/会话/Cookie、速率限制；(3) 一份自我验证清单。仅限防御——不含攻击步骤。
Ruby on Rails 安全 — 生产环境加固实务参考
Rails 自带约定和安全默认值（CSRF 防护、Strong Parameters、ORM），但生产事故来自运营。这是一份实务参考：(1) 优先级排序的加固清单（P0–P2）；(2) 分领域指引——密钥与 credentials（master key/secret_key_base）、生产环境配置（force_ssl、不暴露异常）、gem CVE、Strong Parameters/Mass Assignment、授权（Pundit、所有者范围）、注入与危险方法（where 拼接/send/constantize）、会话/Cookie/CSRF、SSRF/上传；(3) 自查清单。仅防御，不含攻击步骤。
Spring Boot 安全加固 —— 生产环境加固实务参考
Spring Boot 是稳定的框架，但事故来自依赖、配置和授权。本页是一份可上手的实务参考：(1) 按优先级排序的加固清单（P0–P2），(2) 分领域的具体对策 —— 依赖 CVE（Log4Shell 类，按实际运行版本判定）、生产配置与外部化密钥、Spring Security 授权（默认拒绝／方法级授权／所有者校验）、Actuator／管理端点的暴露收敛、不安全的反序列化、注入、请求头/CSRF/会话、SSRF，以及 (3) 自查清单。仅讲防御，不含攻击步骤。