对安全专家而言，这种行为无疑是一种恶梦。更加堪忧的是，多数企业目前还忙于解决其它更紧迫的应用安全性问题（包括SQL注入和购物车负数等问题），无暇顾及内部人员恶意代码可能带来的风险。Veracode和Cenzic日前发布的两项报告，证实了这一情况。Cenzic的报告指出，该公司在2012年测试过的应用程序中，99％包含至少一项严重缺陷，而Veracode则表示三分之一Web应用程序容易受到SQL注入攻击。与此相比，在关键应用中，任何恶意的破坏行为，更可能对业务产生非常重大的影响。

 

　　例如，依赖地图软件来调查石油储量的公司，可能会因为软件中位置信息的细小改动而损失数百万美元。同样，在对冲基金公司中，交易算法决定着一切，任何人只要暗中对该进行修改，就可导致灾难性的后果。由于应用的价值和敏感性，企业必须重新审视与应用源代码篡改相关的安全风险，首先要列出所有可能的攻击者和攻击手段，如包括心怀不满的开发者或其它内部人员，以及来自网络，可以入侵系统并插入恶意Java Script代码的外来攻击者。

 

　　消除源于内部的安全风险是一项艰巨的任务，企业首先要部署适当的内部进程，建立必要的制衡手段，避免将检查代码的任务交给某个个人去做，也不能让开发者去操作审计日志。另外，在开发过程中，企业还可以建立代码互查和同行代码审查机制，以控制代码的质量。很多企业都采用让开发人员结对互相检查的方法，这种做法有很多好处：包括防止恶意代码、改善软件质量和提高员工的创造力。同样，同行之间的代码审查也会找出一些潜在的问题。

 

　　在2009年引起轰动的房利美（Fannie Mae）案例中，一名被解雇的咨询顾问在系统中植入了逻辑炸弹，试图抹去4000台生产服务器上的数据。该代码就是在发作之前，被一位同事发现，没有造成任何损害。

 

　　除了代码审查外，企业还可以向一些成熟的独立软件开发商学习如何建立强大的源代码管理机制，包括代码签名的使用。在这些开发商中，任何程序员编写的代码都会被审计和记录，以开发者的名字进行标注。开发者自己无法蒙混过关，也无法修改这些日志。

 

　　软件的开发、验收和安装只是一个短暂的过程，生产系统则会长期运行。最重要的制衡手段不是在开发和质量控制阶段，而是在软件进入生产系统后，多数恶意软件操纵事件就发生在该阶段。CERT的内部威胁中心也认为，涉及源代码问题的内部攻击通常发生在维护阶段。这主要是因为在最初的开发阶段，会有很多代码审查的流程和机制；而一旦应用进入生产环境开始稳定运行，就不再会有人去做这些审查工作，后续的改进、优化和修补工作往往缺乏严格的管控，这是企业需要改进的地主。

 

　　利用软件工具，自动扫描生产系统的恶意代码和系统弱点，可以算是一个起步。多数人认为自动扫描过程只是为了寻找潜在的漏洞，这只是它主要的目的，另外一个用途是找到恶意插入的代码。当然扫描工具不可能发现所有问题，尤其是该问题并非开发缺陷时。这时候可能会需要引入一些安全咨询公司的专业检查和服务了。

 

　　当然技术并不是唯一需要控制的因素。密码共享等行为也可能给生产环境中的源代码带来巨大的安全风险。有时密码会以纯文本文件的格式存储在网络共享文件夹中，所以理论上任何人有访问权限的人，包括供应商、承办商或兼职人员都可以利用它来访问和篡改生产环境中的源代码。这时候，双因子身份验证可能会派上用场，结合适当的授权机制，可以有效控制开发者对生产环境的访问。这些都不只是IT方面的问题。企业也要借助更好的人事手段，确保员工的可信程度，这是技术手段所无法取代的。