tag
依赖管理
该标签下有 5 篇文章
2026-06-11
漏洞（CVE）处置实务：彻底修复，并持续监控复发
漏洞处置不是『修了』就完事。完成＝①扫描②修复③隔离/移交④监控四点齐备才算数。尤其在加上监控（每日变化检测）之前都算未完成——因为依赖明天又可能变得脆弱。修复内容哪怕100分，只要下一次部署就被覆盖，也等于0分。越是小团队，越能靠自动变化检测和『local→push→deploy』的纪律守得出奇地稳。
2026-06-11
osv-scanner 的安装与使用：用机器找出依赖包里的 CVE
osv-scanner 是一款免费工具，扫描锁文件或容器以排查依赖中的 CVE。本文把安装、运行、CI 集成做成步骤，并理清它与 npm/pnpm audit、Dependabot 的取舍。本站的观点＝选工具的正确答案由『你的架构』决定。多语言混用或不依赖 GitHub 就用 osv-scanner，单一 npm 用自带的 pnpm audit 就够了。
2026-06-07
Log4Shell（CVE-2021-44228）——让全世界一夜之间为『不知道自己是否在用』的漏洞而战栗的一天
Log4j 的漏洞（CVSS 10.0）。本质在于『经由间接依赖（传递性依赖），在不知不觉中正在使用』的恐怖。日志输出这一被动处理成了攻击通道。SBOM 与依赖的机器化监控、迅速打补丁、对后续 CVE 的追踪，都是教训所在。
2026-06-07
XZ Utils 后门（CVE-2024-3094）——『信任本身』被瞄准的供应链事件
压缩库 xz 中被一名赢得信任的维护者植入了后门的供应链攻击。在即将进入稳定版的前一刻，一名技术人员凭『慢』这一违和感把它拦下。被瞄准的不是代码，而是『人与信任』。教训是：把依赖最小化、固定版本、提高可复现性、追踪违和感、支援维护者。
2026-06-07
安全运维 Next.js：建立不在已公开CVE上掉队的机制
框架的最大风险是放任已公开的CVE。以生产实际版本判定，用 Dependabot/osv-scanner 做机器监控，迅速更新，并以最小权限防守，构成四根支柱。本站的视角＝个人开发者输掉的不是知识，而是『运维的可持续性』。靠不漏看的机制取胜，而非速度。