这一内容最初发表在The Code Curmudgeon网站上，作为“对遏制和应对安全漏洞我们能做些什么”这一系列的第二部分。
由安全漏洞引发的事件有增无减，尤其是在零售业。这越来越来让我产生个想法，索性把我的钱从银行取出来，存放在我的床垫下。我慢慢地过渡到使用ATM取现支付我的日常采购，现在我又回到携带更多的现金在身上的状态。
在这个博客中，我要阐述我们今天的软件如此脆弱的一些原因，以及我们就此能做些什么。
让我们从“为何我们没有安全的软件”的一些最常见的原因开始。以下内容排名不分先后:
- 缺乏安全系统性培训
- 缺乏安全性的意识
- 认为安全不是必需的
- 没有能够用心做好测试
这份列表看起来很复杂，但我会试着尽我所能把这些问题分开讲清楚。Parasoft作为软件测试专业方案提供商，首要关注的是软件安全，而不是网络安全或人身安全。虽然它们同样重要，但术业有专攻，Parasoft近30年一直致力于软件质量和安全领域相关的测试研究。
全系统性培训
很明显，安全系统性培训至关重要，但在软件市场中没有什么是理所当然的。我将更多地谈论在不久的将来有关“软件工程”的话题，但是现在只要记住编写软件不等同于熟知软件工程，大多数组织并不关注软件开发人员整体素质。当然，有很多的工程师，他们会编写代码，从事软件行业，但他们并不能够全局角度看待整个软件工程，无法把控软件安全。
所以，大部分的开发人员需要加强软件安全系统性培训。这意味着他们需要了解软件自动化预防的作用，以避免不安全的结构和行为。他们需要知道什么样的方法/代码可能攻击他们编写的软件代码 。他们需要了解软件市场有哪些安全标准和什么样的软件工具可以帮助他们达到这一点，如何让它们物尽其用。他们同样需要投入一定的热情和执着精神。
最近我在Denver的AppSec与一名安全机构的开发人员有过一些关于输入数据验证的讨论。可悲的是，他认为应用程序的某些部分是绝对安全的，因为他本人从没有想到会出现什么方式去攻击他们的软件系统。我们必须摆脱这种固有模式思维，且展开一系列的安全培训，增强必要的软件安全基本技能 。
安全性意识
当开发人员编写代码时，他们根本不会去考虑安全性问题。在自认安全的状态下，总是认为“这多安全啊”、“这怎么可能受到攻击?”、“当事情出错的时候会再说?”。
如果需要长期从事软件安全，则需要大量的基础专业知识。安全感总出自专业积累，如数据库专家、网络专家、系统管理员、开发人员等都成为高安全性应用程序生态系统的一部分，他们各自了解有关软件安全方面的专业知识。
软件市场上有一些常用的软件安全标准，比如最通用的资源是CWE。很多人曾听到过“CWE/ SANS Top 25”编码标准，这是他们目前列出的约800个问题中最危险的25个。CWE的这些安全列项能帮助我们更好地理解什么是安全性意识，因为他们依据技术上的影响列出安全Top 25，所谓的影响是指着如果我遗留这个弱点在代码中，会产生什么坏的结果，技术上的影响包括诸如不需要的代码执行，数据泄露和拒绝服务等。
每个CWE列项都明确地列出了你需要考虑的安全风险。当有人告诉我，他们不认为在他们的代码问题中有一个特定的弱点时，我通常会让他们去Google，如“未捕获的异常”和“CWE”这样的错误名称，然后转去相关的CWE列项，他们会发现这些错误是多么的危险。这些对程序员是致命伤。
不是必需的
安全观念的缺乏来自于没有把安全性作为一项严肃的需求，甚至都不作需求。我们必须开始为所开发生产的软件产品制定安全标准，并且通过强制方式保证团队切实遵守。
有些人说，安全性问题不是一个质量问题，他们错了。我明白他们的意思，安全需要专业思维和培训，但最终它绝对是一个质量问题。
添加软件安全需求到您的开发计划中是一件重要的事情。每个人都知道要做什么，并希望这将会得到适当的安排和测试。如果你以前从未考虑安全性问题，建议在软件项目标准中添加3个简单的安全性要求:
- 安全编码标准，如CWE前25或OWASP前10
- 安全性代码评审
- 安全性测试，如渗透测试
它不会覆盖一切，它也不会是完美的，但它会让你开始有一个非常可靠的基础。
用心测试
软件测试非常重要，甚至可以说软件产品如果没有经过测试就发布上市简直就是一种“犯罪”。但是近50多年来，我们一直认为产品后期的应付性测试工作并不能根本性地提高软件质量，它只是简单的走完必要流程，应付行政工作。
你必须确保自己在开始时，就尽力去提高质量或安全(记住，安全是一个质量问题)。质量和安全必须遍及整个开发过程。这一点貌似很老套，但Deming’s 14 点中仍阐述了有用有效的建议。尤其是第三点:
停止依赖检验来实现质量(安全)。通过最初构建质量[安全]到产品中，来消除检验质量基准的需求。
有些企业明白需要创建一个专业的软件安全团队(好主意)，但却只让他们在开发周期后期去做测试(坏主意)。如果你想让你的安全团队高效工作和体现应有价值，他们必须找到软件漏洞的根源。当他们测试过程中发现漏洞时，应该去追逐它的上游，消除问题的根源，然后消除所有其他相同问题的实例，而不只是庆幸在测试期间找到一个漏洞。
实用的建议
1. 记得去同时关注内部以及外部。许多当前的泄露是一个安全和物理访问的混合。这是黑客的杰作。
2. 遵循基本的、众所周知的安全实践。如果他们对你来说很陌生，那么从培训开始。
- 控制物理访问；
- 培训和监测社会工程，因为它仍然是常用的工作方式；
- 不要使用默认密码。重置您购买或安装任何东西。如果是供应商设置的，那么检查他们的工作。我知道一个有线电视提供商，他们使用一个基于客户地址的模板。可能大部分的客户没有意识到，他们的网络本质上是完全开放的。
- 加密私人数据。数据会在某种程度被他人获取，所以加密任何你不想分享的东西。密码是必须的，还包括电子邮件地址，社会保险号码等等。
- 监测可疑的流量和数据访问。市场存在许多可能没听到过的软件攻击方式，最近的一些漏洞监测报告说不良行为持续了数周或数月，但没有人注意到。
3. 我们必须找到一个更积极的方法。当前的趋势是自动化静态分析去发现漏洞，我们必从须开始就引入自动化预防策略，加强软件生命周期的全方位测试工作。
4. 要积极主动，我们就必须使用合适的工具、流程和技术培训人员，然后正式使用培训政策。培训政策，包括安全最佳实践、需求和测试。
在静态分析中，我们需要补充缺陷调查和更多的预防性规则，如严格的输入验证，而不是追逐潜在受感染数据。所有数据源，甚至自己的数据库，都应该验证。使用预处理语句和强大的验证,可以让你避免受到SQL资料隐码攻击。
我们需要开始寻找根源问题，而不是利用。解决漏洞问题。我们没有寻找特定的安装启用的静态分析规则，我们所有的就是一个没有被使用的根源最佳实践规则。
根本原因应该是足够了。不管我们是否有一个漏洞，弱代码是弱代码。花费在寻找漏洞并检查他们的有效性上的时间几乎覆盖全部，而且还肯定是超过构建可靠的软件。
用一个严格安全的编码标准去编码，比试图计算出你的代码是安全的, 或从一个虚弱且不安全的应用程序中找寻缺陷，更快速更容易。停止寻找漏洞而去建立安全性。给自己一个好的静态分析工具(或使用SEAMP)和CWE的副本，并开始使用。
