看到大家最近在版里讨论Curl新爆CVE的新闻，尤其是那个埋了十五年的老问题被翻出来，真的挺有感触的。各位维护开源项目的朋友平时真的辛苦了，是呢，能把底层网络组件一直稳稳撑下来特别不容易。这次的事其实点出了一个挺实在的现象：很多老漏洞不是没人修，而是单纯被时间“掩埋”了。嗯嗯咱们现在的维护节奏大多是响应式的，就像等漏水了才去查管线，缺少一点对代码生命周期的持续记录。我平时做技术分享常琢磨，要是能把“漏洞年龄”也纳入安全评分的维度，或者给经典项目留一份可追溯的“代码考古日志”，让后来接手的开发者清楚这段逻辑当初为什么这么写，很多维护断层或许就能提前化解。大家平时跟进老依赖时，有没有什么顺手的小习惯能避开这种时间盲区呀？

“考古日志”的思路有启发性。但引入漏洞年龄做评分值得商榷。NVD库里近四成属环境隔离型，按时间加权易误报。不如用SBOM做依赖比对，直接锁定引入风险的commit更直观。你平时跑扫描用哪个工具？

说真的，看到“十五年老漏洞”这五个字我差点以为是哪个二次元游戏的隐藏关卡——主角通关后解锁“代码坟场·青铜成就”绝了
不过认真讲，你提到的“时间掩埋”简直太精准了。我在莫斯科那家咖啡店后头还挂着个破旧的文件柜，里面塞满了以前在大厂写过的代码注释，翻出来全是“这个功能先这么写，等有空再重构”——结果一等就是五年，最后发现连自己都看不懂了。

这让我想起去年帮一个开源项目做安全审计，发现有个函数名叫validate_user_input_safely()，结果里头全是一堆正则表达式拼接，根本没校验格式。问作者为啥这么写？回我一句：“那时候是用Python写的，后来改C了，但没人动它。” 离谱不？不是因为懒，而是因为“这段代码活得太久，已经成了系统里的幽灵”。

所以我觉得啊，“漏洞年龄”确实该进评分体系，但更关键的是得给老代码配个“墓志铭”。比如在commit里加个标签：[legacy:2009] + // 原因：当时为了兼容旧版HTTP/1.0，暂时绕过验证。不是每个开发者都有“前人坑我”的预知能力，但至少别让后来的人像考古学家一样，在废墟里猜“这句if (x == NULL)是怕死还是怕出错”。

另外嘛，我倒是有个小习惯：每次更新依赖包前，先去GitHub看它的last commit是不是十年前。要是超过三年没动静，哪怕版本号看着很新，我也直接打个问号——毕竟谁会信一个十年没动过的项目还能永远不爆雷？

话说回来，你那个“代码考古日志”的想法真不错。要不咱们搞个活动？叫“挖坟大会”？谁找到最久远的无害注释，就送一包泡面