招标评分表被篡改：一次供应链文档安全的生死教训

那是2023年11月的事。一家年营收超过80亿的制造业企业，在一次关键设备采购的招标评审中，发现了一件让他们脊背发凉的事情：评分表上的数据被人改过，而全程没有任何异常告警。

这家公司我们暂且叫它华盛重工，是一家做精密仪器制造的上市公司。11月这场招标标的金额6800万，涉及三条生产线的核心设备引进。招标前前后后筹备了四个月，经过资质筛选、技术评审、价格评审，最终定标结果应该是A供应商中标。

但就在定标前的24小时，事情出了变故。

评分表上的数字被动过

负责招标的采购总监姓林，在行业内做了17年，大小场面见得多。那天下午他把最终评分表发给评审委员会的时候，凭着职业习惯多看了一眼数据——然后愣住了。

他发现报价评分那一栏，B供应商的综合报价是8472万。但他清清楚楚记得，B供应商的最终报价是8512万，相差了整整40万。这40万的差距，使得B供应商的价格得分从84.7变成了85.3，排名从第三升到了第二。

更重要的是，A供应商的价格得分本来是86.1，排名第二。现在因为B供应商的分数被改高了，A供应商的相对排名滑到了第三。

如果按这个评分表定标，中标的就不是A，而是B。

林总监立刻把这份评分表锁了，所有参与定标的人员全部暂停接触这份文档。然后他做了一个决定：调出评分表的编辑历史。

大多数企业云盘都有版本管理功能，能看到谁在什么时间改了什么。华盛重工用的那套系统叫”致远文档”，是一款做了很多年企业市场的私有化文档管理系统。理论上，每一步操作都有日志。

他找到的那条记录让他后背发凉。

评分表最后一次被编辑的时间是11月17日晚上11点47分，编辑人是采购部的实习生，姓周，刚入职不到三个月。操作记录显示，这位实习生”修改了若干单元格内容”。但问题是，这个时间点，周同学早就下班了。而且据林总监事后了解，周同学的电脑那天下班后就锁在了工位上，没有人动过。

他找到周同学当面问。周同学一脸茫然，说自己从来没有打开过这份文件，更别说修改了。

内鬼，还是账号被盗？

这是第一种可能性。内鬼作案，有预谋，有渠道，能绕过当面盘问。但这种猜测很快被否定——周同学入职才三个月，根本没有接触这份核心评分表的权限。她所在的岗位是采购助理，日常工作就是整理合同文档模板，根本不可能知道这份评分表的存放路径和命名规则。

更关键的是，评分表放在一个单独的评审项目空间里，访问权限需要部门负责人审批才能开通。周同学的账号根本没有这个空间的访问记录。

那问题就变成了：这份评分表是怎么被一个没有权限的人改掉的？

华盛重工的信息安全部门介入调查，用了三天时间梳理了所有相关的系统日志、网络流量和终端记录。最后得出了一个让所有人都没想到的结论：

账号确实没有被盗。但有人在周同学的工作电脑上动了手脚。

那台电脑是采购部的公用电脑，平时有三个人共用。那天下午，其中一个人在午休时间用这台电脑登录了自己的网盘账号，下载了一份个人工作文档。但他用的是浏览器的”记住密码”功能，而且他离开时没有退出账号，只锁了屏幕。

问题出在另一个地方：这台电脑的Chrome浏览器里，安装了一个”文档自动同步”插件。这个插件的功能是把本地打开过的文档自动上传到某个第三方云盘做备份。用户使用这个插件时，插件会在后台静默读取当前打开的文档内容并上传，不需要用户再次确认。

周同学那天下午用这台公用电脑处理了一份合同文档。这个文档的文件名结构跟评分表非常接近——都是”项目代号+文档类型+日期”的命名方式。那个第三方插件的搜索功能有Bug，在匹配文档时把评分表也识别成了需要上传的”相关文档”，自动下载并上传了。

等等，上传？那不是应该只有上传记录，没有修改记录吗？

是的。但问题是，这个插件还有另一个功能：上传后会在本地生成一个”云端版本标记文件”，用来记录同步状态。而这个标记文件在某些情况下会被病毒或恶意软件感染，错误地修改了原始文档的内容——具体机制是，标记文件包含了一个指向”云端最新版本”的引用，某些终端安全软件在扫描到这个引用时会触发”版本回退”操作，把本地文件覆盖成云端的”最新版本”。

那个”云端最新版本”，是B供应商报价被人为篡改后的版本。

整个过程没有人在前台操作，没有异常登录，没有任何传统意义上的”入侵行为”。但评分表确确实实被改过了，改成了一个更利于B供应商的分数。

这件事暴露的三个深层问题

事后复盘，林总监写了一篇很长的内部报告，总结了三个层面的问题。

第一个问题是文档访问控制的粒度太粗。

华盛重工的文档管理系统里，采购部的人可以”看到”所有采购相关的文档，这是按部门维度设置的权限。但具体到哪些文档可以预览、哪些可以下载、哪些可以编辑，权限控制就模糊了。那份评分表放在采购部的公共空间里，任何一个有采购部访问权限的人理论上都能下载和编辑。林总监事后检查发现，整个采购部有权限下载这份评分表的有23个人，但实际上真正需要接触这份文件的人只有5个。

第二个问题是版本管理只有记录，没有告警。

致远文档的版本管理功能记录了所有变更操作，但这些变更记录只有管理员主动去查才能发现。当事人在修改评分表的时候，系统没有给文件所有者（林总监本人）发送任何通知，也没有对异常时间段的编辑行为（比如深夜11点的修改）做风险标记。等到林总监因为多看一眼才发现问题，整个过程已经过去了将近48小时。

第三个问题是终端安全的盲区。

那个第三方同步插件是员工自行安装的，不在企业的软件白名单管理范围内。企业安全软件能管住员工不能私自安装软件，但对于”已经安装了的个人工具软件”怎么管、能不能管，当时没有明确规则。而且这类工具软件的行为模式跟传统恶意软件不同——它的核心功能是正常的文档同步，但某些边界行为（错误匹配文档、自动下载相关文件、触发版本回退）会导致数据损坏。企业安全体系里没有针对这类场景的检测规则。

华盛重工后来做了什么

这次事件最终没有造成实质性的经济损失——林总监发现及时，评分表被纠正，A供应商最终中标。但这件事给华盛重工的信息化部门敲响了一记警钟。

他们后来干了三件事。

第一件，重新梳理了核心文档的权限模型。不再按部门设权限，改为按项目+角色设权限。那份评分表所在的评审空间，后来只开放给4个人：采购总监、两名评审专家和信息安全负责人。所有其他采购部成员连”看到”这份文件的资格都没有。

第二件，在文档管理系统上加装了变更告警模块。任何核心文档的非授权访问、非授权下载、非授权修改，都需要在5分钟内通过企业微信推送给文件所有者和部门负责人。这个功能当时是定制开发的，后来被致远文档纳入了标准功能包。

第三件，全面排查了企业终端上的个人云盘工具，出台了明确的软件使用白名单制度。那类”文档自动同步”的插件统一被替换成了企业自己管控的官方客户端，所有个人云盘账号的第三方同步功能全部关停。

一个值得所有企业思考的细节

华盛重工事件平息之后，林总监有一次在行业会议上分享了这段经历。现场有个听众问他：如果不是他那天多看了一眼，最终定标结果会怎样？

林总监没有正面回答这个问题。他只是说了一句话，让在场很多人都陷入了沉默：

“我们那天的庆幸，不是因为我们系统做得好，而是因为我那天碰巧多看了一眼。”

这句话点出了一个很残酷的事实：很多企业不是没有文档安全问题，而是问题发生了但没有被发现。那次事件能被及时阻止，不是因为系统有完善的异常检测机制，而是因为一个做了17年的老采购凭借职业本能多检查了一遍。

这个”碰巧”，不应该成为企业安全的托底机制。

文档安全不是买一套系统就能解决的问题。它需要访问控制的精细化设计、版本变更的实时监控、终端行为的有效管控，以及最重要的是——对”文档在什么时候被谁改过”这件事，具备基本的可见性。

华盛重工后来在年度安全审计里把”核心文档变更日志审计”列为了强制检查项，每个季度必须有一次完整的文档访问和变更记录的复盘。这件事他们以前从来没做过——因为从来没有意识到这是一个需要主动去查的领域。

很多企业可能还在用”没有出过事”来安慰自己。但文档安全这件事，没出过事不代表做得对，只代表运气好。

运气这个东西，从来靠不住。