接触点，作为一个通用的概念，是指在任何新生事物——原动的、认知的或者情绪的——快速增长的浪潮刚要涌现之前出现的那些可以预见的时机。
——T. BERRY BRAZELTON
 
    本书的一个主要目标就是探索和描述一组软件安全的最优方法，我把它们叫做接触点。实施软件安全要求机构对建造软件的方式做一些修改。好消息是，这些修改并不是根本性的、翻天覆地的或者费用高得难以承受。实际上，我们所有要做的常常只不过是采用一组简单明了的最优工程方法，这些方法可以结合到现有的开发过程中。在软件开发生命周期中集成软件安全最优方法，是软件安全的三根支柱的核心。
    我所建议的软件安全最优方法具有坚实的软件工程基础，并且在整个软件生命周期中都明确地考虑到了安全情形。这意味着认识和理解一般风险、基于安全的设计，以及对所有的软件工件进行完整客观的风险分析和测试。在这些活动的过程中，应该根据第2章介绍的RMF来追踪和监视软件风险。本章简明地介绍了软件安全接触点（实际上是一种从5万英尺高处得到的俯视图），并提出了它们的采纳次序。
    图1详细说明了软件安全接触点，并指出了在软件开发过程中软件工作人员应该如何将这些接触点应用到不同软件工件中。这个图也用来装饰本书封底。这样就意味着理解如何在需求、体系结构、设计、编码、测试、确认、测量和维护中采用安全工程方法。
图1  轻量级软件安全最优方法，称为接触点，被应用于不同的软件工件中。这些最优方法是根据效率和重要性来编号的。注意，在此仅仅引用软件工件，以避免针对任何特定过程的争论。
 
    虽然在图中这些工件是根据类似于传统的瀑布模型的方式来摆放的，大多数机构现在都遵循某种迭代方法，因此，随着软件的发展，接触点将不止一次地被循环使用。无论如何，集中讨论工件，我们就能避免扩大的过程问题的争论（包括曾经出现的关于哪种软件过程是实用的和轻量型的激烈争论）。
    我在第1章中讨论过，应该把软件安全接触点设计成与过程无关的。即不论你使用何种软件过程来建造你的软件，都可以应用接触点。哪怕你只是生成一组最小规模软件工件（至少每一个项目都应该产生代码吧！），你也能应用接触点。
    过去我常常以从左至右的次序来介绍软件安全接触点。虽然这样做并无不妥之处，但是，一种更好的讲解方法是，根据软件安全接触点的自然功用来对它们进行排序，并依序进行介绍。有的接触点的威力比其他的更强大，并且你应该首先采用威力最强大的接触点。

    下面按照有效性列出了所有的接触点：
1．代码审核
2．体系结构风险分析
3．***测试
4．基于风险的安全测试
5．滥用案例
6．安全需求
7．安全操作
 
    我列出的次序并不一定适用于每一个机构。实际上，这种次序反映出以代码为中心的机构多年来在应用这些方法时的偏见。因为这个原因，代码审核出现在体系结构风险分析的前面。但是，实际上这两种排在最前面的接触点都是非常重要的。如果进行代码审核而略过体系结构风险分析，你将不能完全地解决软件安全问题。再回到我在第1章中的定义，导致安全问题的软件缺点可以分成两类：缺陷和瑕疵。
    代码审核的目的是找出缺陷。体系结构风险分析的目的是找出瑕疵。如果你略过其中的任何一个，你都极可能仅仅解决一半的问题（牢记缺陷/瑕疵各占一半的事实）。在任何情况中，排在最前的这两种接触点的位置都可以交换，而且不失一般性。
    至于其余的接触点，我所提供的评级标准是以在许多不同类型的机构中应用接触点的多年经验为基础的，这些机构包括从大型的独立软件供应商到巨型的信用卡财团。这些接触点的次序并不是绝对的。但是，任何改变这种次序的企图，比如，在进行代码审核之前进行***测试，就很可能不会像我建议的方式一样取得成功。具有讽刺意味的是，现在可以在大多数处理软件安全的机构中发现他们是“首先进行***测试”，特别是在那些由安全部门推行软件和应用程序安全的机构中。这种次序反映了对待安全的被动反应方法，也是我一直都在反对的方法，我主张将安全作为一种必需的部分，并且让真正的建造人员参与安全过程，。
    在有些情形中，大型机构可以同时采用多种接触点。关于在大型企业中采用接触点的更多信息，参见第10章。
 
注释：
1.原注：本章的一小部分最初以标题“安全的软件的7个接触点” [McGraw，2005]发表在2005年9月的SoftwareDevelopment杂志中。
2.译注：柏利•布莱泽尔顿（1918-），美国著名儿科医生和作家。