最近，Windows 源代码网上泄漏事件的发生，使开放源代码和封闭源代码的安全性问题再一次成为激烈争论的焦点。
我在自己的专栏中撰文讨论了Windows源代码泄漏事件，指出封闭源代码作为一种安全技术的价值；读者留言中95%不认同我的观点，他们认为，因为开放源代码是开放的，所以它能够获得更好的代码评审；每个人都可以查看代码，并发现其中的问题。
争论的基点源于这样一个假设：封闭的源代码没有经过评审，或者至少没有得到充分的评审——我不太确定这种假设的真实性，事实上，我们没有理由推断封闭源代码公司不能提供良好的代码评审，也没有充分理由去假设开放源代码项目就一定得到了完全的代码检测。
不仅如此，除了一些特别的社区性团体，目前还没有任何官方的专门机构致力于为开放的源代码提供安全性测试服务。
把源代码公开并不能确保代码本身的安全性，同样，封闭源代码也不能使代码本身变得不安全。
当然，开源软件的也常常在接受测试，测试人员有为微软产品提供“黑盒测试”的咨询顾问，也有开源软件开发者。不久以前，开源社区试图建立一个被称作“Sardonix”的组织，以统一零散的测试行为，但最后迫于资金枯竭而基本宣告解散。
Securityfocus.com发表的一篇文章暗示了一种观点：源代码测试组织的失败显示了人们厌恶枯燥、机械的安全测试工作，相反，人们乐于发现软件破绽和漏洞，进而甚至发动攻击，然后因发现漏洞而沾沾自喜。
来自伯克莱大学一个研究生科研小组，从学术驱动的角度为开放源代码审计工作做了很多贡献，但其测试人员的水平和经验值得怀疑。
另一方面，微软公司却花钱雇佣专人在做代码检测工作，工作的成效直接影响其收入和奖惩。
微软安全商务和技术部门的高级程序经理 Michael Howard说，微软软件如果爆出漏洞或受到攻击，负责这部分代码测试的工程师的工作绩效也会受到影响。严格的奖惩制度会使测试人员非常谨慎。
Michael Howard说，微软的产品不仅仅只由微软来做代码评审，Windows XP SP2的代码就正在由外部机构进行严格的评审。用不同的编译器进行编译，是SP2代码评审的重要一环，因此，对编译器本身也要进行测试。
毋庸置疑，相当多的用户认为微软面对“安全”问题要么就是太愚蠢，要么就是太懒散，并期望微软能够尽快改善其软件的安全性，听这位产品经理的意思，似乎微软对于解决安全问题已高度重视并且成竹在胸。
然而，不管是微软软件还是开放源代码软件，漏洞都无可避免，大多数批评者批评的时候却忘记了一个基本道理：绝对安全的软件几乎是不可能的。
我承认当我在里根总统执政时期学习编程知识时，没有人告诉我还需要检测安全漏洞，而且我怀疑还有直到近年还有很多程序员头脑中依然缺乏安全意识。完美的代码检测绝非易事；不仅如此，程序员在一边撰写程序代码，一边思索软件实用性、易用性的同时，还必须为其“安全性”负责，这更非一日之功。
现在，安全观念已经深入人心，但还没有成为很多学校的教学课程，更糟糕的是，很少有人明白如何写一个安全的软件。
不久前，被泄漏的Windows 源代码中暴露的漏洞恰好说明了这种现状。这个漏洞是一个整数溢出错误，它可能潜在地引起执行任意代码的危险。
这批代码是三年半以前撰写的，那个时候很少有人意识到整数溢出是个潜在的安全隐患。以三年半以前的代码评审标准，整数溢出问题很容易被忽略。
微软就此发表声明，称该漏洞是经由IE 6源代码评审后期被发现并修改的。微软企图说服用户统统升级到IE 6，但用户却要求微软为IE 5发布补丁程序。
另一方面，近期Windows系统执行ASN.1协议时发生的错误同“OpenSSL ASN.1内存泄露”漏洞极为相似，尽管几乎所有开放源代码操作系统都采用ANS.1协议，却相对来说鲜为人知。
在这一点上，每个版本的OpenSSL都是可攻击的，这意味着问题已经存在多年而未被发现，原因就在于发现这些漏洞比较困难。
如果搜索计算机网络应急技术处理协调中心（CERT Coordination Center）的软件漏洞数据库，尤其是按照严重性来排序时，你会发现源代码和安全性之间的关系并非象人们想象的那么简单。
把源代码公开并不能确保代码本身的安全性，同样，封闭源代码也不能使代码本身变得不安全。
本文地址：http://com.8s8s.com/it/it25398.htm