夜雨聆风买了一个软件，等保测评没通过，到底是卖软件的锅，还是买软件的人的锅？
开篇：一个真实到让人头疼的场景
你是某政府部门的IT负责人，单位花200万买了一款业务管理系统。验收那天，软件功能没问题，测试跑通了。
结果你把系统拿去等保测评——
测评师翻了一圈说：“这系统的身份认证没有双因素、日志不完整、数据传输没加密。这是高风险项，先整改再测吧。”
你回头找软件厂商：“兄弟，这软件过不了等保，你们得负责搞定。”
对方回复：“大哥，合同里没写安全要求啊，我们按功能需求开发的，等保是你们的事吧？”
你愣住了。
对啊，到底是谁的事？
一、法律怎么说：责任主体是谁？
先把结论摆出来，一个字都不能错：
根据《网络安全法》第二十一条、“网络安全等级保护条例"及相关规定，等级保护的责任主体是"网络运营者”——也就是信息系统的拥有者、管理者和运营使用单位。通俗说，甲方。
翻译成大实话：谁的系统需要做等保，谁就是法定的责任人。不是软件厂商。
我们来拆解一下法律语言：
| 甲方 | ||
| 乙方 |
用一个比喻讲清楚：
甲方是房主，乙方是装修队。
房子（信息系统）要过消防验收（等保测评），房主是法定责任人——验收不通过，罚的是房主，不是装修队。
但如果当初签装修合同时，你写了"电线必须国标、烟感必须装、逃生通道必须留出来"——装修队没做到，那就是他们违约。
问题是：很多甲方的"合同"里根本没写安全要求。
二、甲乙双方的"责任分界线"到底在哪？
我们把甲方乙方在等保这件事上的"地盘"画清楚：
🔴 甲方的地盘（必须自己扛）
| 系统定级 | ||
| 公安机关备案 | ||
| 部署环境安全 | ||
| 安全管理制度 | ||
| 持续安全运维 | ||
| 聘请测评机构 |
🔵 乙方的地盘（承诺了就必须做到）
| 应用层的安全功能 | ||
| 交付物的安全质量 | ||
| 合同中承诺的安全标准 | ||
| 协助甲方过等保 |
三、“模糊地带”——最容易扯皮的四个场景
现实中，甲乙方的责任远没有上面那张表干净。更常见的是以下四种"扯皮场景"：
场景一：甲方没说，乙方没问
甲方签合同时就没提安全要求，乙方按功能需求开发了一个"功能100分、安全20分"的系统。等做了等保测评，一看全是漏洞。
怎么破？
- 甲方的教训
：采购合同中必须明确安全要求。“功能齐全"不等于"安全合规”。招标文件和合同中必须引入安全条款。 - 乙方的教训
：你是专业做软件的，你的系统能不能过等保，你自己心里没数？开发时没考虑安全，交付后客户过不了等保，口碑一定坏。长期看，乙方也有动力提前做好安全。
比喻：这就像你请人盖房子，你没说要做抗震，师傅按正常标准盖了。地震来了，房子塌了——你说谁的责任？师傅说"你没说要抗震"，你说"你是专业的你应该知道"。这就是经典扯皮。
场景二：软件过了等保，部署后出事了
乙方说："我的软件已经拿到了等保三级测评报告，安全没问题！"甲方放心部署，结果被黑了。一看原因——甲方把软件装在一个没有防火墙的服务器上，操作系统三年没打补丁。
怎么破？
软件等保测评报告只覆盖应用层。服务器没打补丁导致被入侵，是甲方的部署环境安全责任。
比喻：你买了个防盗门（软件），厂家测试通过了防撬认证。结果你把它装在了一面纸糊的墙上——小偷直接把墙凿了个洞。你说这是防盗门的责任？
一句话原则：软件等保≠系统等保。软件防得住应用层攻击，防不住你操作系统没打补丁。甲方买软件之前，先看看自己的"墙"是不是砖头砌的。
场景三：合同写了"交付物需满足等保三级要求"，乙方说做了，结果测评没过
合同里确实写了安全要求。乙方说"我交付的软件符合等保三级"。甲方拿去测评，测评师说"权限控制不满足、日志格式不符合要求、数据传输未强制加密"。
怎么破？
"满足等保三级要求"是一句模糊承诺。合同中应该具体到控制点级别：
✅ 好的写法：
“乙方交付的应用软件需满足GB/T 22239-2019中安全计算环境（第三级）关于身份鉴别、访问控制、安全审计、数据完整性与保密性、个人信息保护的全部控制要求。测评结果中不得出现高风险项。”
❌ 差的写法：
“交付物需满足等保三级要求。”
比喻：你说"这辆车要安全"，厂家给了你一辆装了安全带的五菱宏光。你说"我要的是安全"——厂家说"这不是有安全带吗？“——你当初就该写清楚"要ESP、要8个安全气囊、要AEB主动刹车”。
场景四：乙方帮甲方"代劳"定级备案
甲方想省事："我是政府单位，你们公司帮我把定级备案一道做了吧。"乙方想拿项目，满口答应。结果备案材料出问题——定级不准、系统描述与实际不符——公安机关找上门。
怎么破？
备案是法律行为，乙方不能代替甲方签法律文件。
定级报告上的"运营使用单位"栏、安全责任书上的"法定代表人"签字，必须是甲方的。乙方可以作为技术支撑协助准备材料，但最终的法律责任在甲方。
比喻：你可以请装修队帮你准备消防验收的材料，但验收申请书上必须是你自己的签字。装修队代你签字——你敢吗？
四、一个务实的分工清单：各司其职，少扯皮
把上面的分析整理成一张可落地的清单：
五、给甲乙双方的三条黄金建议
给甲方（系统采购方）
- 招标时就写清楚安全要求。
别等到验收了才发现"这个软件过不了等保"。招标文件里必须列明安全条款：需满足等保三级安全计算环境的哪些控制要求、交付物需经过渗透测试、源代码不允许有高危漏洞。 - 软件等保报告≠系统等保通过。
买来的软件有等保报告，不代表你部署后就万事大吉。你的机房、网络、服务器、管理制度，都要同步达到等保要求。 - 自己是最终责任人。
乙方不配合，你可以按合同追责；但公安机关找你，找的是你，不是乙方。
给乙方（软件开发商）
- 安全不是"增值服务"，是"基本配置"。
你的产品如果"一遍过等保"而不是"反复整改"，是巨大的竞争壁垒。客户选你，省的不是测评费，是无数个整改加班的夜晚。 - 合同里别承诺做不到的事。
“我们的软件满足所有等保要求”——这句话是坑自己的。你只能承诺"应用层满足安全计算环境的三级要求"，管不了客户的机房有没有气体灭火。 - 提前配合，减少扯皮。
甲方测评时，积极配合提供技术文档和解释。你的专业配合，是长期合作的基础。
终极比喻：这根"责任绳"，你拉哪头？
把甲乙双方在等保这件事上的关系，想象成一根拔河绳子：
code复制
甲方（法定义务人） │ 乙方（合同义务人）
定级、备案、环境、管理、 │ 应用安全、代码质量、
聘请测评机构、持续运维 │ 技术配合、合同交付
│
▼
┌─────┴──────┐
│ 合同约定 │
│ 甲方没写=扯皮│
│ 甲方写了=乙方│
│ 必须做到 │
└─────────────┘
绳子中间那个模糊地带，靠的是什么？合同。
合同写得清楚，绳子就拉得直。合同写得含糊，绳子就拧成一团。
所以，下次签定制软件开发合同时，别只写"功能需求"。把安全条款也写进去。
📌 下一篇预告：《等保测评机构的水有多深？——谁有资格、多少钱、靠不靠谱？》
转发给同样在"甲乙扯皮"中挣扎的同行。
本文法律观点基于《网络安全法》及现行等级保护制度体系。具体法律问题请咨询专业律师。