审计日志里那条被拦截的命令,让我出了一身冷汗 有天早上巡检,我在运维 Agent 的审计日志里翻到这么一条: { "ts": "2025-07-29T03:14:22.118Z", "sessionId": "sess-7f3a91c0", "userId": "u_zhangwei",
安全部甩来 213 个漏洞,限期两周整改 11 月初,安全部门用他们的商用扫描器对我们的 14 个 Java 服务扫了一遍,发来一份 Excel:213 个"高危及以上"漏洞,要求两周内清零。 我们团队三个人,14 个服务,平均每人每周要处理 35 个漏洞。第一反应是不可能完成。但真正让我头疼的不是
周五下午的告警 2022-03-31 Spring4Shell(CVE-2022-22965)被公开,我们安全群里炸了。我负责的两个服务跑在 Spring Boot 2.3 上,得立刻确认是否在影响范围内。应急响应的第一步不是升级,而是确认影响面——盲目全量升级可能引入别的问题,先搞清楚"我中没中"
周五晚上十点,安全组在群里丢了三个 CVE 编号 2021 年 12 月 10 号晚上 22:17,公司安全组群里一条消息,只有三行: CVE-2021-44228 Log4j2 RCE,影响版本 2.0-beta9 至 2.14.1,请各业务线今晚完成自查并反馈。 那时候这个漏洞还没被媒体炒起来,
安全组的一封邮件 2021 年 1 月 20 号上午,公司安全组群发了一封邮件,标题是《关于 fastjson 反序列化漏洞的紧急排查通知》,要求各业务线在周五前上报使用了 fastjson 的服务清单和版本。 我心里咯噔一下。我们三个核心服务全在用 fastjson,版本 1.2.62。 $ mv