1 xcodeghost事件始末
Xcode为苹果官方的编译套件，在Mac App Store中免费提供。中国大陆访问Mac App Store有连接困难，部分开发者选择了国内第三方渠道下载（如百度云盘），由此带来了安全隐患。而这部分Xcode被植入了一套称作“Xcode Ghost”的代码，会替换相关的库，使得编译出来的APP携带有病毒代码，在最终用户端运行时将隐私信息提交给第三方；同时安装这类受感染应用的设备具备可能的广告点击能力。
2 谁的责任——互联网公司软件开发流程简介
2.1 开发人员的责任?
IOS系统向来以安全著称，虽然早在PC辉煌的windows时代就有类似于感染编译器而著称的Delphi梦魇。但是在移动互联网大潮下以同样手法侵入IOS依然给公众带来的太多震惊。震惊之余我们不得不去探求事件产生的深层原因。部分读者纯粹的将这次的事情归咎于——居然那么多的IOS程序员连一个Xcode开发环境都不会装。作为一名安全从业者，笔者希望能够揭示给大家潜伏在表面下的事实。
笔者有幸曾经在互联网公司做过一段时间的研发，所以对于互联网公司一个软件上线的流程有很详细的了解。通常制作一款软件，不管是移动端的IOS/Android还是windows下的一款互联网公司上线的软件，虽然发行版有几十兆，相对于当下的宽带运营商动辄提供10M或者更高的宽带接入速度大家对几十M的大小可能并没有太直观的感知。其实如QQ，微信，微博，滴滴打车等这样用户体量的软件，抛开市场推广人员，运营人员，测试人员不算仅仅研发人员都会有百十号人。难道这百十号人所有的Xcode环境都会装错吗。这里我们需要给大家简单解释一下互联网公司的软件开发流程。
一个软件，百十号人同时开发，肯定会有一个多人协作机制。如Git如Svn都是这种多人协作机制中的解决方案中的一种。大家有兴趣可以自行了解。
为了不引起项目的修改冲突，往往不同程序员都在敲着不同文件的代码，每次完成自己的任务以后，会将自己的代码提交到Github或者一些不同公司乐于使用的远程的Code Server，然后经由Package人员经过校验无误后合并进主线代码库中，所以每次程序员提交的代码只会提交他自己敲打的代码，oc也好，swift也罢，甚至一些底层算法用的C++或者是一些xib文件的修改，都只会将程序员自己敲修改的东西提交，绝不会把Xcode开发环境里的任何内部文件提交，说白了开发人员是没有权限去改动编译器文件的。Windows环境下面的软件编译甚至为了考虑运行时库的差异，最终大家提交的代码需要编译的部分都统一在一台装好编译环境的编译机上进行统一编译。整个软件的编译过程(排除掉以二进制方式提交的组件)甚至都是不需要程序员参与的。开发人员是没有权力也是不需要去干涉和参与最后的软件的编译和打包的。简单说，就是你在APP Store下载的APP完全不是在某一个或者几个开发人员的xcode开发环境下编译出来的，而是从一个统一的xcode开发环境(CI或者编译机)下面编译出来。由于一个软件可能有几百个人同时开发，即使开发人员的本地环境有问题(开发人员的本地环境通常只用于平常自己代码的编译测试调试排错，而最终的发布版本一定会在统一的编译机或者CI上进行编译)，除了二进制方式提交的部分组件外，不会影响到由编译机或者CI编译出来的最终的版本。需要说明的是编译机或者CI就是一个通用的编译环境，苹果平台下就是苹果提供的XCODE环境。而就是由于最终负责统一编译的XCODE环境是在第三方平台下载更新的，所以导致此次的xcodeghost事件。
2.2 打包和测试人员的责任?
一般来说发release版本，使用编译机或者说CI的人是打包人员。但是编译机或者说CI这东西平常装上之后也就是做一下简单维护和更新不需要太多操心，而众所周知时间就是互联网公司的生命，小步试错迭代发行，打包人员的本职工作就是做Package而并不是负责安装和维护编译环境。每一次研发人员的苦逼加班背后肯定需要跟着同一组的打包和测试人员。每天本职工作加班加点都做不过来怎么有空闲的心思去关心编译环境的问题，只要发release版的时候编译环境不出问题能够正常使用，平常根本或者说没有时间去异想天开——竟然开发环境还会被污染，要理解大多数的测试和打包人员是不怎么懂技术的。
软件从CI上编译好之后紧接着就是测试。当然一个公司内部会测试与开发同步进行着，并且很多大的互联网公司都有着专门的测试组，他们负责时刻与程序员交流沟通工作进程并且测试软件的各种异常，针对软件开发的测试一般分两种，IOS也不例外。一种是功能测试，就是用手点点每个按钮看有没有啥异常，一般苹果的App Store也就是做做这种测试，第二种就是性能测试，写测试代码或者使用第三方性能跟踪软件，利用性能跟踪软件实时监控内存、函数调用是否异常、内存占用情况、数据传输定位等等，这次的事件主要症状就是一些数据被传输到了指定服务器，这些额外传输数据的功能在测试的时候却没有发现，或者说测试的时候发现了测试人员也会以为是程序的正常功能和逻辑，从这里我们其实可见一斑，即使是大的互联网公司的专门的软件测试人员在做测试的时候实际上也可能存在着疏露，即使软件测试的流程走完了，也不一定能保证软件是没有问题的。
测试流程走完之后，该项目或者产品的负责人会等测试报告和项目功能校验等一系列任务完成之后，使用测试通过的软件包也就是测试通过的APP再提交到苹果官方的iTunes Connect，至此这个出问题APP的接力棒就交到了苹果手中。
2.3苹果公司的责任——为什么没有审核出问题APP?
事实上苹果官网列出了常见的几种APP会被苹果审核不通过的情况。读者可以自行从苹果的这个网页看到。https://developer.apple.com/cn/app-store/review/rejections/
从截图中可以比较清楚的看到官方审核APP基本大都是在APP功能的范畴。不久前被闹的沸沸扬扬的360产品在APP Store被全线下架的事件也是因为360的产品调用了苹果的私有API接口犯了苹果的大忌所以被下架。而此次的xcodeghost的危害只是能存活于用户手机中，然后收集iPhone和app的基本信息，包括：时间，bundle id(包名)，应用名称，系统版本，语言，国家等并回传到指定服务器。目前版本的xcodeghost收集的这些信息是一个正常应用也可能会收集并且会传到自己服务器的信息。显然xcodeghost的这个行为明显不在苹果的app store对app审核的关注范围之内。
3 xcodeghost的反思——互联网从业者KPI考核、软件付费和版权的市场现状
xcodeghost事件曝光之后由于媒体的聚焦报道，短时间之内病毒制造者、苹果公司和相关的APP的开发的互联网公司被推到的舆论的风口浪尖。当然多数人还是一边倒的谴责的声音，一部分还是中立的声音认为是由于官方的Mac App Store的xcode的安装包过于庞大，开发者由于网络问题连接困难不得不从第三方进行下载所以才导致的此次xcodeghost事件。也不能将责任完全归咎于开发人员。
（由图片可以看到xcode的开发环境安装包大约3.59GB的大小，比64位的windows7旗舰版的安装包足足还大了400多MB，并且还需要从Mac App Store进行安装。很多人有从app store下载更新大型游戏软件的经历。其中的痛苦几乎不需要太夸张的进行表述。）
就在笔者缓缓的敲击键盘将此篇文章的文字逐个通过word 2003进行编辑的时候笔者尴尬的看了一下自己的office2003的安装包——蜻蜓特派员office2003 sp3 五合一精简安装版。相信xcodeghost曝光之后那些对病毒制造者、苹果和相关APP开发公司进行口诛笔伐的媒体从业者们在这方面的情况也不会比笔者太好。
笔者在安全行业从业这几年回想起来，几乎没有太多公司或者企业会为开发者提供官方采购的开发环境。从最基础的windows操作系统到办公软件的office系列，从逆向需要的IDA到双机MBR调试的所需要的VMware虚拟机。整个业界的从业者都是自力更生去找破解版或者序列号，没有人关心开发者的开发环境是否是正版，使用的软件应该付费而却没付费，从业者更多在乎的是自己的KPI。
就在我敲下这行字的时候我静静的在京东的搜索框中敲下了windows7这几个字。按照销量由高到低搜索到的页面是这样显示的。
CNNIC曾经给出过一个官方的统计大体数字是这样的，截至2013年12月，我国网民规模达6.18亿，手机网民规模达5亿，占总网民数的81.0%。考虑到linux在桌面操作系统份额占有率和windows的悬殊差距，可见一斑——中国市场，正版windows用户寥寥。就连windows这么大用户基数的基本是人手必装的操作系统软件拥有正版授权的用户极少，几乎都是从第三方网站或者直接使用盗版光盘。在这样的行业和市场的大环境下xcodeghost的出现也是迟早的事情，哪怕苹果的xcode的开发环境是免费的。这一次xcodeghost出现在苹果平台，目标瞄准的是开发者，下一次类似手法的病毒瞄准的很可能就是windows或者安卓平台，同样的手法可以直接狙击终端用户。
很多用户看到xcodeghost的报道之后觉得自己是一名受害者，殊不知我们中间的大多数在面对软件版权和付费的时候由于目前的不健全和不具有严苛效力的法律条款，更多的时候也被动的扮演了一名施害者。