4月27日，国家网信办官网公布了一则消息：近日，国家互联网信息办公室、国家发改委等12个部门联合发布了《网络安全审查办法》（以下简称《办法》），今年6月1日起实施。

从《网络产品和服务安全审查办法（试行）》到《网络安全审查办法（征求意见稿）》，再到《办法》正式实施在即，和大家再度盘点一下《办法》里的重点内容，同时，一起看看网络安全从业人员和FreeBuf的作者们是怎么说的……

CII自身安全团队使用的渗透工具要不要上报审查？

上报VS不上报

@吞龙：

个人理解应上报，工具对审查结果有直接关联性，提交的结果更加客观，工具对审查结果的偏差影响更为直接。

@linuxself：

一般不上报，但是可以通过VPN进行流量记录，保证渗透可查。

@bbbbbbig：

需要上报审查。原因如下：

1、很多团队目前使用的渗透工具主要是破解版和一些私人开发工具，这些工具有可能会存在问题；

2、对公司而言，可以掌握这些工具的大致情况；

3、客户处工具上报后，也可以让客户了解在项目实施过程中具体会使用到的工具，这样客户也会有底。

@米怀特：

从安全的角度来讲上报是肯定的。从软件版权的角度讲：1、开源软件审查产生问题和费用怎么负责。2、破解版涉嫌侵权问题，对于破解版的审查合法么？

@两块：

自身安全团队使用的渗透工具，应该也属于供应采购，不需要自己上报审查，除非工具软件是自行开发的，应该有工具软件提供商出具相应的审查报告。

@煜阳：

上报是肯定的，而且我个人认为不管是业界公认还是开源自研的都应该上报，只不过是公认上报名称就行了。开源自研上报除了名称还要有三方评估报告，这样才能确保结果的准确性以及接入环节的安全性。

用户如何知道自己的数据和设备是安全的？

《办法》 要求运营者承诺不利用提供产品和服务的便利条件非法获取用户数据、非法控制和操纵用户设备。

@linuxself：

一般很难发现自己的数据被滥用，被获取可以通过移动终端的权限控制进行记录和审计，至于硬件层没有很好的办法，签一个用户协议？

@两块：

运营者应该自证明自己合规合法，提供用户查询自己数据和设备是否安全的通道，不仅限于要求运营者提供检测报告或者相应证明。

供应链安全在安全圈甲乙方关系中如何保障？

@米怀特：

供应链：物料(编程语言等)->研发人员->产品->实施或有关人员->用户->维护。而哪个环节出现问题都会产生不小的影响。比如：

1、物料(编程语言)存在后门

2、研发人员从删库到跑路

3、产品存在高危问题

4、实施或有关人员泄露客户防御架构

5、用户对于安全低敏感

6、维护操作配置不当

……

通过各种规章制度和加强供应链各个环节安全人员参与度，能够缓解或解决部分问题。比如某些大厂着手安全审计自家产品就是很好的例子。

此外，最高效的办法使用最新版。但很多企业研发底蕴不允许，比如一些组件存在新旧兼容问题，重新开发成本又大。有的会选择安全产品，但是没有安全人员介入可能会形成安全问题的循环。还有一些公司并不在意安全影响业务，运营到一定规模才会考虑安全问题。通俗讲快饿死了，哪有精力管是否安全。

@yangyangwithgnu：

我们用的工具多多少少有些非正版，现在内部要求安全评估尽可能在虚机中操作。针对nday，我们是两方面要求：一是安全侧缩短扫描周期；二是要求业务侧主动关注依赖组件官网发布的漏洞通知，尽早升级。更多地把内驱力落实在业务方。

@linuxself：

通常从供应链的生命周期来进行，不同的角度有不同的生命周期，比如终端就是下载、使用、传输、卸载，应用开发是设计、开发、编译、测试、发布、运营，期间涉及的供应链不仅包括环境、中间件、组件，还有平台等，建议建立内部的软件、环境、组件白名单，容器仓库白名单统一管理，通过开发流程来进行插桩把控。

其他

供应链安全仍然面临很多挑战。比如PCI DSS，整个供应链全部都是PCI DSS的安全标准，当发生信息泄露的时候，由PCI研究所对整个供应链做检测，这个是没问题的，但是一旦有供应链中的一方标准不统一，实施就难度很大。目前《办法》给出了一个方向，但供应链安全仍然缺乏成熟的方案，需要继续努力。

……

对于《网络安全审查办法》你还有什么想要分享的，欢迎评论区一起讨论~

【申请入群 即刻参与话题讨论】