如何看待阿里云被暂停工信部网络安全威胁信息共享平台合作单位？

下面一群人屁股老歪了哈，工信部可没有禁止向apache报告，反而《网络产品安全漏洞管理规定》第七条中，第一就是立即向上游产品提供者报告，也就是说必须立即向apache报告；第二才是在2日内向工信部通报。阿里云明显没有做到这一点，被罚纯活该

这个老哥说的好，

有理有据，令人信服

阿里报给apache17天后，apache才对外公布；

而工信部是15天后才收到消息，apache收到漏洞的15天里压根就没有通知中国工信部，那apache会不会告诉美国的相关主管部门呢？会吧。

阿里呢？又有没有通知工信部？没有吧。

高下立判……

要我说，技术人员都是在开源思想下工作的，在一个共享开源平台上交流技术经验，利用开源程序不需要『重新造轮子』

事情的本质就是，技术人员没有合规人员的觉悟

技术人员发现问题以后，想到的是解决，也就是联系提供者，但是少了觉悟，还是要向工信部报备的

看完全过程，认可评论区有个人说的，谁能在一开始就上帝视角完美处理好呢，事后风凉话谁都会说，立定改正才是正解

发现阿帕奇的漏洞的第一反应挺真实，想的不够细觉悟不够高，坦白来说这事跟我们买了个过期食品先跟商家说一样，但特殊环境下，阿里还是要提高觉悟力

网络安全类的工作是不能有半点差池的，以后的公司在这方面一定要提高警惕心和重视度啊！

首先阿里云和国家信安部是合作方，乙方有义务在发现漏洞的情况下第一时间告知甲方。

还有洗地职业道德和政治觉悟冲突的，冲突你个 。

同时上报甲方和社区这两件事之间难道加了互斥锁的？

还有说不信任开源软件就不要用的人，我信任开源软件，但是信任不了利用开源软件的漏洞背后去使坏的那群人啊。这里面的逻辑都理不清，你要好好掂量自己的智商了。

“阿里云将该漏洞第一时间报给了美国Apache公司，并未向我国工信部报备该漏洞，且间隔17天后.Apache公司发布补丁才对公众公布此事。(- 般公司产品漏洞的修复时间及发布补J不会超过三天)在此期间，如果利用漏洞发起攻击，影响的范围堪比2017年“永恒之蓝"病毒，当年的WannaCry勒索病毒，致使美国、英国、俄罗斯、中国等至少150个国家，30万名用户中招。目前中美形式十分紧张，美对我网络攻击持续渗透中，国安、部委正在排查我国资产受否已受到境外攻击，造成信息被窃取或者服务器、系统被植入木马等损失。”

这个事情我觉得阿里云是有点儿冤的。

熟悉我的都知道我是阿里黑，但是就事论事的讲，发现了问题，第一时间报告给其作者，这个事情是没什么毛病的。

一般的互联网公司法务又不懂技术，虽然这个事情很可能是阿里云的工程师自己发给Apache的，但是即便是同时通报给法务部门，要给他们解释清楚这是个什么漏洞估计都要好多天……

我觉得主要是这个事情后来的发酵太大了，传播太广了，还有些营销号说这是近十年来最严重的Bug差点儿没把我笑死……

这种低级错误GitHub上真是一搜一大把，只是这次正好出在Log4j这种广泛使用的框架上了而已。而且讲道理，Log4j这玩意儿的应用，也没很多人想的那么广泛，只是一堆Apache基金会的Java项目受影响而已，非Java的项目几乎都不用这玩意儿……

总的来说，阿里云这次挺冤的，另外，Apache基金会要抓抓内鬼了，这特么种点后门进去未免也太简单了……

还有人给我发私信说这种漏洞是核弹级的，因为可以远程执行代码……。那SQL注入是不是氢弹级的，还能远程删库呢……再说了，你以为SQL注入就只能执行SQL？

题目就没写全。

他发现了阿帕奇产品的问题是第一时间向美国阿帕奇软件基金会报告，但十几天后才报告工信部。问题是工信部有规定的，发现类似的漏洞2个工作日以内向工信部汇报，这是明确的规定，所以，这是板上钉钉的违规行为。半年内阿里云不会接到任何对公业务了，而且，以后大企业是否选择阿里云也要打个问号了，信任已经存疑了

如果说阿里发现漏洞先报告国家，再通知Apache，这算屁股红。

如果说阿里发现漏洞先报告Apache再马上告诉国家，这算技术牛，懂大局。

如果说阿里发现漏洞先报告Apache再规定时间内告诉国家，这算正常商业，无可厚非。

如果说阿里发现漏洞先报告Apache然后就不管，等Apache公布漏洞后，国家才知道，这就有意思了。

阿里到底是哪个国家的公司？这漏洞还不是小漏洞，范围大，影响大。他本着我是国际公司，开源的精神告诉了美国的开源公司，然后又没告诉中国风险，试问下，这算怎么回事。

联想在说自己是哪国公司的时候，还支支吾吾。阿里可以大声的说，自己是一家立足于世界的国际公司。

你觉得Apache不会告诉美国？从阿里告诉Apache到Apache公开，中间隔了十几天，十几天时间估计可以把网络玩个遍了。

阿里毕竟和联想一样是一个设立在中国的跨国公司。和联想最大的不同估计是阿里还有大量的外资。阿里的屁股正不正，这由大家评说。但总的来说，阿里让我想到了一些明朝的晋商集团。

后续：

阿里云官方今日回应称，因在早期未意识到该漏洞的严重性，未及时共享漏洞信息。阿里云将强化漏洞管理、提升合规意识，积极协同各方做好网络安全风险防范工作。

阿里的回应更加搞笑，阿里会不知道这个漏洞的严重性？用途这么大的组件出现这么严重的BUG，他会不知道严重性？他是在侮辱阿里的安全人员啊。

有人说我外行，实际上，第一，我是一个搞软件开发的，所以别说我外行了。第二，行业规矩不代表是正确的。第三，行业规矩不代表美国企业会遵守，详细见马斯克的卫星变道事件，美国企业比中国会站屁股多了，美国IEEE一个学会把阿里踢出合作名单。第四，国家为了让这些歪屁股资本家遵守规矩，所以定了新的规矩，其中，阿里是签订了，两天内必须报告的规矩。简单来说，阿里不单单是歪屁股，而且还不遵守规矩。现在只是对他不遵守规矩的事情进行了处罚，实际上，我觉得更改对阿里歪屁股进行触发。看看外国科技公司屁股多正，中国的科技公司各个买办

中国啊，还是太讲规矩了，对资本家还是太好了

简单说说我的看法，虽然我也是圈外人

1、安全圈没有小白兔

2、0day漏洞发现了，特别这次的log4j漏洞，其实是核弹级别的，其实一般来说往往是挖挖金矿，用完后再公布

3、普通的漏洞第一时间通知apache官方没啥的，这次的核弹级漏洞，通知apache官方，apache需要测试，需要想解决方案，这个时间差其实够做很多事情了。特别工信部声称也是通过公开渠道才知道这个消息的，这对于国家来说很尴尬。

而且apache公布方案是深夜——可能对于他们来说是白天，这个也很尴尬。

最后，重复一遍，安全圈高管没有小白兔，阿里云估计起码要下台个副总裁谢罪。

对接apache是需要的，但是在此之前，第一时间和工信部、公安部沟通，更加必要。阿里云这么多高级安全专家，不会不懂这个事情的必要性。

最后我强调下：安全圈经常游走于灰色地带，所以对法律法规政治因素其实是很敏感的。包括很多安全届著名的攻击案例都是国战性质的（例如美帝对伊朗伊拉克的网络攻击）。这些都是写在安全教科书上，这其中还有阿里雇佣的安全专家写的著作

所以阿里这次难辞其咎，他们没有权力推脱我不知道我不敏感。

另外一方面，发现这个漏洞是阿里对世界的贡献，这一点也需要正确认知他们的贡献——当然其实有另外个可能是其他组织早就发现但是秘而不宣。对于宣布漏洞的组织，我们还是需要对此致谢和保持敬意。所以这个事情是两个角度看待。

0day漏洞第一时间通报代码主创方是业内惯例，是白帽行为的惯例，技术团队例行就做了。

但通报上峰则必须是公司行为，阿里云首先不是安全公司，安全团队也是相对弱势的support team，这方面将其对比奇安信有些不公允，而我猜测阿里安全工程师都不知道有个两日内通告国内的规定。

再者，0day不是核泄漏，绝大多数情况下外部访问不能直接exploit，有充分时间让主创方确认最佳修补方案，随后共同通报CVE组织，广而告之。

上纲上线，就算先提交给上峰，他们有能力补？

也许阿里云有错，但更大的错在某些公众号和想炫耀技术的人

最早，只是个别几位大佬了解这个漏洞并成功复现，管理员在群里明确说明：不要再讨论这个漏洞了，禁止公布漏洞细节，大家聊其他的事情。当时我分析Log4j2源码，并阅读官方文档，参考commit，大概推测出了漏洞原理，简单尝试后成功RCE，不过我并没有告诉任何人，也不打算在任何平台分享，开始写漏洞分析文章，打算等官方通报并发布新版本后发表

本以为没什么事，结果当天晚上某公众号发出了漏洞利用的细节，在安全圈中称之为POC：能够让完全不懂Java安全的小白也可以利用该漏洞。该公众号有不少的粉丝，人传人，后果就是全网脚本小子的狂欢，疯狂dnslog。该公众号管理员中，能独立分析出漏洞利用细节的安全人员确实是懂技术的，但是，为了炫耀技术也好，为了公众号粉丝也罢，都不应该发出去

实际情况不只是这篇公众号，还有很多具有一定技术的安全人员，为了炫耀等原因，将自己研究出的漏洞细节公布，无论是发到安全交流群里，或是发到博客，或者公众号，或者抖音B站等。让广大脚本小子群体得知了该漏洞利用细节，这才是该漏洞被广泛利用并造成危害最根本的原因

其实该漏洞的挖掘难度不是非常大，如果告诉你Log4j2有JNDI注入漏洞，然后给你一份源码，熟悉Java安全的师傅们基本都可以找到。但任何人通过任何方式利用了该漏洞，如果造成损失和影响，都可能会算到阿里云头上，因为漏洞报告者是阿里云

阿里发现漏洞，报告给阿帕奇，美国就得知了漏洞，此时中国所有大公司（除了阿里）都面临高危风险（包括很多军工保密单位）。中国处于完全被动状态，阿里和美国掌握主动权，此时美国窃取中国信息轻而易举。

如果阿里先报告给政府，可以保证中国所有大公司都已知了风险，不会那么的被动。

信息时代，微小时间差就会产生不可估量的数据泄露。

不要说什么开源精神，国家利益高于一切，看看英特尔不用新疆产品，你能有啥反制措施？log4j2漏洞这机会千载难逢，被断送

漏洞细节

在谈论阿里之前，我们先从技术处理层面看一下这个事情。关于这件事其实有很多细节都还没有披露出来，目前Apache方面的通告基本可以参考这个：

搜索"CVE-2021-44228"就可以看到Apache关于这个漏洞的描述，我摘取前面的一部分放在下面，大家可以看到这个漏洞的描述、影响范围(from 2.0-beta9 to 2.14.1)、安全级别、以及修复版本号（当然Apache和下游的供应商也会想办法在早先的版本上修复这个问题)等。

Fixed in Log4j 2.15.0 (Java 8)

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.

CVE-2021-44228 Remote Code Execution
Severity Critical
Base CVSS Score 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected All versions from 2.0-beta9 to 2.14.1

Description
In Apache Log4j2 versions up to and including 2.14.1 (excluding security releases 2.3.1, 2.12.2 and 2.12.3), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

感兴趣的可以打开上面的链接自己看一下，后面还有很多内容。比如给出了在未修复的版本上如何暂时“缓解”这个漏洞办法，还有他们如何在各个版本上解决这个问题的方案等。当然最后也明确感谢了漏洞的发现方：

Credit:
This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.

以及追踪解决这个漏洞的过程：

Limit the protocols JNDI can use and restrict LDAP.
Message lookups should be disabled by default

阿里错在哪里

对技术细节感兴趣的可以翻看上面的部分的更多链接，了解更多技术细节。因为问题问的是如何看待阿里云被罚，所以我们还是说一下阿里的问题在哪。

从时间线上看：

• 1）上面Apache没有给出他们具体收到阿里报告的时间，但是从bug的追踪记录看绝对早于2021年12月5日，甚至可能早于12月。那阿里到底是哪一天察觉这一漏洞的，目前还没有官方明确的信息，相信应该更早。
• 2）那么工业和信息化部网络安全威胁和漏洞信息共享平台（后面简称为“工信部”）又是什么时候才知道这个事情的呢？根据工信部官方的描述，他们是在2021年12月9日才得知这一漏洞的：

2021年12月9日，工业和信息化部网络安全威胁和漏洞信息共享平台收到有关网络安全专业机构报告，阿帕奇Log4j2组件存在严重安全漏洞。

那12月9日是个什么日子？12月9日是Apache已经在自己的版本上处理完了这个漏洞（甚至应该也提前已知会了一些相关公司等），然后公开披露的日子，也就是说到这一天你想不知道都难，因为这一天全世界搞这方面的都会知道了，你想不知道都会有人跟你聊起来。而工信部就像这个“一直被蒙在鼓里的傻孩子”，新闻中的措辞是工信部“收到有关网络安全专业机构报告”，这就相当于是大家都知道了，然后才有人过来告诉你，而这个“有关网络安全专业机构”可能还不是阿里，如果是阿里可能工信部就直接说了。

从这里我们就可以看出，阿里错在过于敷衍了工信部的地位，或者他们自己低估了这个事件可能带来的影响力。不管是哪个，都是阿里内部管理上的问题。因为从技术规范角度来说，从开源软件中发现漏洞后报给上游软件供应者一点问题都没有，工信部也不会因为你把问题报给Apache而处罚。问题出在把问题上报给工信部的时间，甚至可能一直都没上报给工信部，工信部可能最终也是从别人那知道的。

这就问题大了，工信部不是一个简单的部门，他下面牵连着很多相关成员。或者换句话说你可以将工信部理解为阿里云的重量级客户（虽然不是直接客户），这样问题就很好理解了，甲方爸爸管你吃管你穿，结果有这么大一个漏洞你不第一个告诉我就忍了，我竟然差不多是大家都知道后最后一个知道的。

这就好比有一个熊孩子，发现他爸爸正在穿的一条裤子后面有了个洞，然后他第一个先打电话通知了这条裤子的生产厂商，说你们这个款式 的裤子的某个位置没缝好有个洞，生产厂商知道后感谢了熊孩子，并表示一定尽快修复这条生产线的做工问题。然后熊孩子就美滋滋的回家睡觉去了，任凭他爸爸穿着那条破洞的裤子被人看了好几天都不知道，直到生产厂商那边解决了生产问题，通告下来说所有穿这款裤子的人都注意一下自己的裤子有洞，并明确感谢了这个熊孩子，这时他爸爸还不知道，直到一个同事看到了这个通告，认出了是XXX的儿子，这时他的爸爸才知道自己一直穿着破洞的裤子给别人看，而他的儿子是第一个知道的。你想想如果这是你的儿子，你禁他半年零花钱过分不？

到此，阿里云被工信部处罚暂停合作6个月已经不算重了。要不是看在还是自家儿子的份上早就终止一切合作了。

对阿里的影响

这件事对阿里的影响应该是不言而喻的：

1. 首先好的影响是让阿里的技术团队的能力得到肯定，毕竟发现了这个漏洞。
2. 不好的影响就比较多了，最直接的就是其被信任的程度直接下降，这会成为阿里云和其它人谈合作的一个污点。
3. 另外一个直接的不好影响就是阿里的股票可能会再次下跌，造成公司的经济损失（不知道我那几个在阿里云工作的朋友今年的年终奖怎么样）。要知道阿里的股票已经带着中概股一路下跌了：

阿里云部分本来没怎么跌，结果现在整这么一出，估计阿里云的部分也得跌。唉，不知道该怎么评价阿里了。你说你可怜它是中国企业吧，它接连干出来的事情确实不地道，你说你惩罚他吧，自己又肉疼。只能希望阿里能吸取教训，重新振作吧，别总自己作自己。

这也能扯这么多？

就是单纯不知道这个流程而已，很简单的。真正干活的工程师不可能知道这份规定的，怎么公开怎么PR，肯定是领导和相关部门说了算的。

实际上不上报也未造成任何影响，因为这个事很快就人尽皆知了。只是和工信部网络安全威胁信息共享平台合作的流程上出了问题。完全不涉及爱国不爱国，3.75还是3.0的。实际上就是你不上报，平台肯定也知道了（否则那真是有大问题了），但你把平台规定当摆设也不对，这次借机打个杀威棒。

贴一下相关规定：

（一）发现或者获知所提供网络产品存在安全漏洞后，应当立即采取措施并组织对安全漏洞进行验证，评估安全漏洞的危害程度和影响范围；对属于其上游产品或者组件存在的安全漏洞，应当立即通知相关产品提供者。
（二）应当在 2 日内向工业和信息化部网络安全威胁和漏洞信息共享平台报送相关漏洞信息。报送内容应当包括存在网络产品安全漏洞的产品名称、型号、版本以及漏洞的技术特点、危害和影响范围等。

可以看到规定要求先通知上游（Apache），再在2日内发送相关漏洞信息。所以不涉及爱不爱国，单纯是相关规范不了解，通知社区是程序员的职业素养，而不知道还有这么个事而已。

信息共享平台的意义本来就是你知道有漏洞了上报，平台分享给其他成员，大家都能及时得到通知。你在那收别人的信息收的欢，自己发现的反而没报告，这算啥……暂停自然就是为这个事情的警告。

安全漏洞这种事情为什么需要有信息共享平台，因为安全信息的送达是分秒必争的，如果安全漏洞在被发现之后先被攻击者知晓，就会造成不可挽回的损失，所以有必要有专门的通知渠道，保证在漏洞被广泛揭晓之前，先给关键服务提供商修复的机会，国家主导的平台就是为了确保有个尽量可信的送达机制能让这样的信息在尽可能保密的情况下尽快送达各个合作方，阿里因为自身疏忽没好好配合，那不就是没有尽到合作方义务吗？

安全漏洞研究是必须要遵循工作流程规范的，如果工作没做好，反而会成为攻击者的帮凶。这就好比好心帮忙检查大楼坚固不坚固当然是好事，但检查的时候一声招呼不打直接把楼弄塌了，他是好心，你要在楼里面你怎么想？

昨天这事儿闹得沸沸扬扬，工信部的惩罚和阿里云的公告我都看了下，简单聊聊我的看法。

我认为这就是一个工作流程上的失误，阿里还处于「工业和信息化部网络安全威胁和漏洞信息共享平台」（以下简称平台）未上线之前的工作流程，还是按照只上报产品提供方的原流程。

我猜想是安全工程师和项目负责人忙于处理安全隐患，而把新修改的上报流程忘到脑后了。

公告对这个事情的解释也是，发现安全bug后“按业界惯例”报告给了Apache开源社区请求帮助，随后，这个漏洞才被外界证实是一个全球性的重大漏洞。

但是现在说什么都没用了，错误已经是既定事实，有则改之就行了。

工信部也给了惩罚措施，暂停合作6个月，整改完再说。阿里云在公告里也表了态：强化漏洞管理、提升合规意识，积极协同各方做好网络安全风险防范工作。

在聊这个性质之前，我们先来看看这个漏洞本身的危害。

这个漏洞危害有多大？

首先这个漏洞被发现在阿帕奇Apache上，Apache是一个Web服务器，其中Apache HTTP Server 是Apache软件基金会的一个开放源码的网页服务器，可以在大多数计算机操作系统中运行，由于其多平台和安全性被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩展，将Perl/Python等解释器编译到服务器中。

简单来说，每当你在网页地址栏里输入http://abc.def.ghi的时候，这条命令背后的处理器Apache就负责全力开展行动。

正因为Apache的广泛使用，才导致这次的漏洞危害特别大。

Apache Log4j2 是阿帕奇软件基金会旗下的一款日志纪录工具，90% 以上的 Java 开发平台都会直接或间接地使用这款工具。

漏洞原理官方表述 是：Apache Log4j2 中存在JNDI注入漏洞，当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。

覆盖了 IT 通信 ( 互联网 ) 、高校、工业制造、金融、医疗卫生、运营商等大量的行业和领域。业界将其称之为堪比 2017 年 " 永恒之蓝 " 的安全漏洞。

2017 年 4 月，黑客团体 Shadow Brokers 公布了一大批网络攻击工具，其中最为突出的便是 " 永恒之蓝 " 工具。

这款工具利用 Windows 系统的 SMB 漏洞，可以获取系统的最高权限。不法分子通过 " 永恒之蓝 " 工具制作了 wannacry 勒索病毒，攻击了英国、俄罗斯、整个欧洲等地区的多个高校、大型企业机构的网络系统，并向被攻击者勒索高额赎金才予以解密恢复文件。

如此高危害级别的安全漏洞，阿里云虽然发现了漏洞并反馈给了软件所有方阿帕奇软件基金会，但在网络安全威胁信息共享平台的上报流程上出现了问题。

警惕阴谋论

阿里云在云计算领域里面，不管是其的技术方面，还是开源方面，在业内都是佼佼者。计算机领域的开源精神在网络安全方面体现的淋漓尽致。

在这次的事件中出现了一些「漏洞」离谱的阴谋论：

1 为什么没按规范做？

目前最新的漏洞上报流程只有一个文件，具体的案例还暂未出现，阿里云基于「开源」的精神，将漏洞率先上报提供方，这无形中是满足了规范的第一条规定的。只是没有意识到这个严重性，所以没有及时上报。

作为一家成熟的企业，明确法规却瞒报是不可能的事情。

2 阿里ptsd

阿里云的云服务质量绝对是世界范围内的佼佼者，除了AWS和MS在欧美领域的先发优势，其在别的地域实力不逞多让。

3 不应该用开源的，应当全部国产，自主可控。

这个其实就有点不知道怎么反驳了，因为太过离谱。因为Apache只是成千上万个模块中的一个，这些模块是全世界的开发者共同努力的结果。正是因为互联网的「开源精神」，才让它发展的如此迅猛。

不是所有的东西都能国产，单独的国家力量是有限的。

阿里云在这件事情上明确存在管理不规范的问题，处罚的一点问题也没有。但是，这个上报的合作单位绝对不止阿里云一家，其他的合作单位的处理方法暂时还是未知数。但可以肯定的是，各种阴谋论是绝对不可取的，人人自危的结果就是技术停滞不前。

新的上报流程

题目中提到的「工信部网络安全威胁信息共享平台合作单位」是工信部下属的一个工作单位，于今年的九月二日成立

根据其职能，不仅要求需要上报网络产品安全漏洞，包括还不限于工业控制产品安全漏洞、移动互联网APP产品安全漏洞、车联网产品安全漏洞等。

在其官网上可以看到这有三个栏目，其中关于上报流程的规定就在第二个文件里面，可见发布时间是今年的8月30日。

其中具体要求如下图

第一，立即上报产品提供者（也就是Apache） ----- 完成

第二，两日内向「平台」上报，并报送内容应当包括存在网络产品安全漏洞的产品名称、型号、版本以及漏洞的技术特点、危害和影响范围等。 ------ 疏漏

第三，对客户和用户负责 ---- 完成

显而易见，阿里还是按照之前的流程，只做了第一和第三步，而对于新增的第二步产生了工作流程上的疏漏。

正常情况下不会去做这种很明显是错误的事，这种工作流程上的不完善，从各自的工作日志上都可见端倪。

平台从建立以来，也没有过具体的漏洞公布过。

工作流程的失误是板上钉钉的事实了。所以新规颁发后，作为国内市占率第一的云厂商，更应该做好带头作用，内部形成这种意识形态和敏感性。

能力越大责任也越大

阿里云的份额在世界排名第三，在亚太第一无可争议的第一。正是因为这么大的覆盖面，这种错误才显得难以接受。

不过大家也不用太过担心，因为近期由Gartner发布最新报告显示，阿里云IaaS基础设施能力拿下全球第一，在计算、存储、网络、安全四项核心评比中均斩获最高分。据介绍，这也是中国云首次在硬核的IaaS能力上整体超越亚马逊、微软、谷歌等国际厂商 。

阿里云在安全方面其实是非常专业的，这次的乌龙事件就是流程上的失误，以其在权威机构评分下极高的安全性能，还是十分值得信任的。

这次错误犯得的不好，下次不允许再犯了。

昨天白天和朋友 @lokinko 讨论了下这个问题，不过昨天忙得没时间写回答，现在才来简单答答。

其实问题很简单，就好像@lokinko同学说的，阴谋论的回答可以歇歇了，也不要把什么问题都上升到大是大非。发生这种事情，完全是阿里云安全部门的工作流程出现了错误而已。我估计可能是以下两种原因：

1. 合规部门没有及时跟进到最新政策。但可能性较少，因为合规部门的工作之一就是研究政策。
2. 最可能的是合规部门可能了解到了新政策，但阿里云的合规部门没有和工程部门做好知识共享，结果发现漏洞的人没有即时告诉工信部这个漏洞。

有人好奇，到底是什么政策？其实是《网络产品安全漏洞管理规定》，公布于今年7月，9月1日开始实施，还是挺新的政策。

可能有人会说，你说的这些，是不是为阿里洗地？非也。我自己做风控的，主要业务就是做合规技术的（RegTech），用技术推进合规。我能理解作为工程人员，是很难了解所有政策的，连我这种专门做RegTech的人都很难了解所有政策，更别说专门做云技术的技术人员了，所以很多公司会有专门的合规部门。

有人说，这个漏洞，最先发现漏洞的，是阿里云安全团队，从技术角度上来说，阿里云本来应该是立功了，帮助整个行业修复了一个严重的安全漏洞，为啥阿里云还被罚了，这样的话，是不是以后大家发现漏洞都不敢报了？没必要过度想象。

事实上，在《网络产品安全漏洞管理规定》的第七条（1）中说到：对属于其上游产品或者组件存在的安全漏洞，应当立即通知相关产品提供者。所以，阿里云根据开源项目惯例，发现漏洞，立即报给Apache，并没任何不妥，完全符合规定。

但是——这里要说但是了——紧接着的第七条（2）指出——应当在2日内向工业和信息化部网络安全威胁和漏洞信息共享平台报送相关漏洞信息。这点阿里云并没有做到，工信部是多天以后才从公开新闻了解到这个漏洞。

作为监管部门，工信部当然有必要及时了解到最新的漏洞信息，况且，工信部毕竟是阿里云的合作伙伴。

所以，暂停6个月的合作这惩罚也算合理，不算轻但也不算严重，希望阿里云吃一堑长一智，之后在漏洞上报流程方面更完善点吧，确保漏洞信息通知到所有利益相关方和监管部门。顺便一说，Log4j2这个问题最近我们好几个客户都遇到了，在漏洞被曝出来后，他们首先通知到各自的合规部门和监管部门，然后通知到了我们公司，基本上所有利益相关的人员都通知到了。

总结下，整个过程是这样的：阿里云安全团队按照国际流程，在发现漏洞时向Apache官方报告了漏洞，但忘记了（或者不知道）也要向工信部报告。毕竟有的时候，处理安全问题，如果流程不一样，产生的结果也不一样。如果你是职场人士，你会对「流程」一词更有体会。

反正我大一的时候，学的第一堂课是工程伦理。大四上的最后一个必修是网络安全与知识产权相关法律。我是不知道你们这些洗地程序大佬怎么那么多的理由和借口的？估计是学分低没技术的课都逃了。

这种恶性bug，不第一时间报告国家，鬼知道有多少重要服务器已经被攻击了。

少他妈技术无国界，什么来源之类的屁话，你们这群洗地的有种就别留在国内。

码农便涨红了脸，额上的青筋条条绽出，争辩道，“开源组织不会窃听……窃听！……程序工程师的事，能算窃么？”接连便是难懂的话，什么“谷歌不作恶”，什么“GPL开源”之类，引得众人都哄笑起来：水区内外充满了快活的空气。

先回顾一下事件的影响，这次log4j的漏洞影响相当大，是全行业受影响，而不仅仅是阿里云：

通过Google搜索引擎对依赖该组件的产品、其他开源组件分析后发现，有310个产品、开源组件依赖了Apache Log4j2 2.14.1的版本，包括诸多全球使用量的Top序列的通用开源组件，例如 Apache Struts2、Apache Solr、Apache Druid、Apache Flink等。

而Struts2，Druid，Flink等组件简直是互联网公司的标配。

这不得不把软件供应链安全再次拿出来讲一讲了。

2015年9月，黑客组织利用当时通过官方渠道获取苹果 Xcode 官方版本困难的情况 , 在非官方渠道发布的 Xcode 注入病毒，导致 2500 多款使用该开发工具开发的苹果 App 被植入恶意代码，受影响的苹果 iOS 用户达 1.28 亿。
2017年8月，安全研究人员发现知名电信设备制造商Iris生产的调制解调器存在五个安全漏洞，其中三个硬编码后门账号漏洞。由于未及时开展漏洞挖掘和修复工作，直接导致攻击者利用三个后门账号控制设备，获取root 权限，安装新固件乃至架设僵尸网络。
2017年9月，NetSarang公司开发的安全终端模拟软件Xmanager、Xshell、Xftp、Xlpd等产品中包含的nssock2.dll模块源码被植入恶意后门。
2020年12月，美国SolarWinds公司的Orion软件更新服务器上存在一个被感染的更新程序，导致美国财政部系统等约18000家关键基础设施、联邦机构和企业受到影响，部分受影响设备甚至可由攻击者完全操控。

据GitHub统计，2020年新增了1600万开发者用户，预计2025年开发者用户数将达到1亿，而中国开发者数量及贡献度增长已成为全球最快，预测到2030年，中国开发者将成为全球最大的开源群体。

软件定义世界，开源定义软件。

可怕的是，如果我们一切的国产化，都建立在开源软件的基础之上，一旦底层开源软件出现漏洞，影响范围难以估量。

芯片卡脖子很难受，没有相应的软硬件，造不出芯片；

开源卡脖子很可怕，当开源已经深入所有应用的方方面面，如果有一天突然断供/出现漏洞，如同整个软件世界的地基突然坍塌，皮之不存，毛将焉附？