2009年，哥伦比亚大学计算机科学教授Steven Bellovin说：“任何人……找到解决计算机安全问题灵丹妙药的可能性恰好是零。问题大部分出自有缺陷的代码，造成缺陷的原因各异、也没有单一的解决方案。事实上，我很怀疑会有真正的解决方案；有缺陷的代码是计算机科学最古老的未解难题，我认为这不会改变”。
本月出任联邦贸易专署(FTC)首席技术专家的Bellovin，在IT领域服务多年，包括在新泽西州Florham Park的美国电话电报公司（AT&T）实验室从事研究二十余年。他在其生平中解释说：“我研究网络和安全，以及二者间的冲突”。
对计算机安全问题，未来会有彻底的解决方案吗？《政府技术》（GT）杂志向Belllovin问了这个问题和其他问题。他谨慎地指出，这些仅是他个人的意见，不一定是FTC的意见。
GT: 三年前，您说过有缺陷的代码是计算机科学最古老的未解难题，并预期不会改变。现在您的观点有无变化？看来，随着基础架构变得 “更聪明”，我们将成为坏人更大的靶子，而潜在危险的后果也严重得多。例如，一个交叉路口的交通灯故障，可以让车辆堵塞若干公里。
Bellovin: 是的，我的观点没有变。到底该做什么仍属研究领域；即使我有些想法，但都极不成熟。我认为我们需要采用不同的架构来建立系统，这些架构在设计时就考虑到将会有安全失误。身份认证做不到这一点，在大多数破坏中，坏人绕过了强身份认证、而不是攻破了认证。
我自己的实用哲学是：程序将有安全缺陷，其后果呢？但这是个研究课题，不是给程序员的指南，更不用说用于最终场合了。您刚才提到交通灯出毛病，您问得太对了：一个部件出故障，系统的退路是什么？
GT: 为什么缺陷代码问题这么棘手呢？
Bellovin: 根本问题在于，智力难以掌控程序的复杂性。举例来说，雷鸟（Thunderbird）电子邮件程序。几年前我检查时，该软件约有六百万行代码。（这是很粗的估算值；我只对准确到“百万”有信心，但到底是六百万、还是三百万或一千二百万行，我说不准）。
假定我想写些在总结行里显示附件数的代码。该代码部分将必须利用极其复杂的已有代码部分，来扫描并解析整个邮件以确定每个附件开始和结束的位置。（因为规格说明书特别复杂，代码本身复杂得可怕。）我对现有代码的理解不会错吧？不懂会闯祸吗？能有多少个附件呢？假定我今天读现有代码、觉得它不可能处理多于99个附件，因而用了两位数来显示。尔后，其他人在不了解我那些代码的情况下修改了代码以便允许9,999个附件。我那些代码就处理不了了，因而产生了一个缺陷。该缺陷会被黑客利用吗？可能会、也可能不会，但问题有可能从这里发生。
更好的设计也许是，让处理附件的代码有办法告诉程序的其他部分附件的上限数；但这意味着大量的前瞻性。有时，程序员具备足够的前瞻性，有时又会缺乏；或许过去程序员曾有过，但经过多年需求已经变更了。
除此之外，还有粗心大意。我想回顾一件35年前的事，那时我在研究院、教一门编程入门课。出于复杂但可以理解的原因，某学生在操作系统指令中用了一个分号。（用的是IBM主机、那是打孔卡片时代。）
分号在程序里是必须的，但在命令行语言中则是禁止的。然而，负责命令行部分的程序员没有预见到分号，结果在处理该指令时（即每当系统试图运行该学生的那组卡片时），整台主机崩溃。学生遭人白眼，但实际上应归咎于程序员，因为他理应把代码写得更好：当有人提交分号等垃圾时系统不至于崩溃。
当今的程序改善了很多，但离完美还很远。您也许听说过“SQL注入攻击”，问题的发生，在于程序员未曾处理意想不到的输入。（这一点，http://xkcd.com/327/ 有幽默阐述。）
困难在于，除了“把代码写得更好”（Write Better Code）之外，对复杂性难题我们没有什么好办法。（“我忘记了”是相对容易解决的。）如今，“把代码写得更好”可能极有帮助。微软公司过去十年里在此方面大笔投资，用于程序员教育、自动检查工具、代码复审团队等。确实有帮助，可谓获益良多，然而，从微软公司的关键缺陷修复率来看，这与他们的目标距离还很远。也有很多“把代码写得更好”的想法，从上世纪七十年代初起，我一直在关注着各种百灵药上市。不用说，问题尚未解决。
GT: 新一代互联网标准IPv6是不是弱点少一些呢？
Bellovin: 它有一些小改进，但没有根本性的。当初设计该标准时，我们曾寄予厚望。实际上，在1994年前后，有人曾宣称它会更安全。不幸的是，如他们所说，该声明是“无效的”，有几个原因：首先，我们所说的“更安全”实际上是“内置了加密”，即现在被称作IPsec的虚拟专用网（VPN）协议。
这有几个问题。其一，如今我们对不安全性有了更深刻的理解。密码学是好东西，但解决不了缺陷代码问题。（1998年，作为National Academies研究的一部分，我分析了当时已经发出的每条CERT建议，85%描述的都是加密无法解决的问题：代码问题、配置错误等等。）其次，我们当时假定IPv6会很快得到实行，但事实并不如愿。在过渡期间，每个推出的操作系统都在IPv4代码中加入IPsec支持。这冲淡了IPv6原有的优势。
但IPv6仍有一些好东西，例如增强私密地址（privacy-enhanced addressing）、纯v6网对扫描蠕虫（那些通过在某个IP地址范围找到所有宿主传播的恶意软件）的相对免疫性等。但这些不过是小优点，需要与互联网服务供应商及其网管对IPv6运行与跟踪经验相对不足来综合考量。（跟踪是指当机器使用增强私密地址、需要其他措施才能辨别时，回答“哪台机器干了那件坏事？”的问题。）
GT: 那么，假如缺陷代码和您提到的问题继续存在，我们该何去何从？
Bellovin: 不存在完美的事物，并不意味着不存在“较好”或“较坏”的区别。良好实践会令我们受益匪浅，但别以为这样能彻底解决问题。
