一些经验，来自于实践。推导的过程就不累述了。
软件的安全来自于设计，这个观点肯定不会有人反对了。但如何在软件的开发过程中引入安全设计，这是一个工程实践的问题了。
微软在这方面走的很早，实践方面可以参考微软的人写的一本书：
《XX 我忘记了》
这本书对开发过程中安全设计流程写的很清晰。这个流程很全面，成本当然也就很高了。我在近两个月的工作，总结了比较适用于我们部门的一个流程和更细节的一些实施方法，供大家参考。
建立安全设计的基本原则。
这些基本原则不要太多，要精简。否则，条条框框一大堆，没有人喜欢去学习。
建立基本原则的另一个目的是为后继的流程建立起基本的评估基线。例如：为什么要加上这个限制，原因在于符合某条安全设计基本原则。
1 Minimize attack surface area 最小化你的攻击面
2 Establish secure defaults 模块在缺省情况下就要具备一定的安全性
3 Principle of Least privilege 最小特权原则
4 Principle of Defense in depth 纵深防御
5 Fail securely 局部失能不可以破坏全局，异常处理应降低外部影响
6 Don’t trust services 不要信任外部的服务
7 Separation of duties 职责分离
8 Avoid security by obscurity 不要通过隐藏来获得安全
9 Keep security simple 使安全机制简单
10 Fix security issues correctly 不要补漏洞，开出新漏洞
为各种程序实现场境建立安全设计指南
例如，为进程权限的升权降权编写开发指南； 网络应用场境的程序应该如何设计才能保障安全等等。这个工作量较大，也需要编写人员经验要足够丰富。这个工作对我来讲，很有难度，放在了最后开始。
在设计阶段进行威胁建模
威胁建模的流程已经是很标准了。在实施中，最大的问题是，如何建立威胁分析表，就是针对每个威胁类别（STRIDE），预估可能的具体的威胁。这个对于开发人员是一个很大的挑战。
我为部门建立了一个威胁清单，这个清单来自于CWE。大约有270多种，有了这个清单，进行威胁建模分析就轻松很多。
这个清单一方面扩展了大家的视野（原来有这么多种攻击方法），一方面更为统一，大家使用一致的“语言”来描述威胁。一方面描述也更为精确。
有了这个清单做为 guide ，再分析自己负责的模块，思路会更顺畅。
以渗透为目的的代码审计
渗透测试通常都是黑盒的。费效比一般。在开发接近尾声时，进行代码审计，挖掘出漏洞，效果相当不错。因为这是白盒条件下的渗透，审计人员对产品比较熟悉，效果相当不错。（我自己夸下自己）
基本上，平均每天能发现一个漏洞，两天一个高危漏洞。特别是最近，在一些已经被检查过很多遍的老模块里，发现两个高危漏洞。
以上，就是我们最近的实践活动。附上CWE清单，中文版。而且，原文是很晦涩的，我还加上了描述，更进一步帮助开发人员理解。
