第17章 安全开发流程（SDL）
17.1 SDL简介
安全开发是从根源有效地解决安全漏洞问题，而已在软件的生命周期内，这样的开发模式成本更低。
SDL过程：
q 培训
所有的开发人员必须接收适当的安全培训，了解相关的安全知识。
q 安全要求
明确项目的安全要求。
q 质量门/bug栏
质量门和bug栏相当于确定安全和隐私质量的最低可接受级别。
q 安全和隐私风险评估
评估项目中的安全现状和威胁模型
q 设计要求
在产品设计初期考虑安全问题
q 减小攻击面
减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减少攻击面包括关闭和限制对系统服务的访问，应用“最小权限原则”，以及尽可能的进行分层防御。
q 威胁建模
建立威胁模型分析项目或产品可能遇到的攻击，以及给出解决方案
q 使用指定的工具
q 弃用不安全函数
q 静态分析
q 动态程序分析
q 模糊测试
模糊测试是一种专门形式的动态分析，它通过故意想应用程序引入不良格式或随即数据诱发程序故障。
q 威胁模型和攻击面评析
需求发生改变时，安全模式也需要相应改变
q 事件响应计划
产品的发布需要留下开发人员的联系方式，以及相应的文档，方便日后解决问题。
q 最终安全评估
q 发布/存档
17.2 敏捷SDL
敏捷sdl的思想其实就是以变化的观点实施安全的工作。需求和功能可能一直在变化，代码可能也在发生变化，这要求实施SDL时需要在每一个阶段更新威胁模型和隐私策略，在必要的环节迭代模糊测试、代码安全分析等工作。
17.3 SDL实战经验
准则：
q 与项目经理进行充分的沟通，排出足够的时间
q 规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏
q 树立安全部门的权威，项目必须由安全部门审核后才能发布
q 将技术安放写入开发、测试的工作手册
q 给开发工程师培训安全方案
q 记录所有的安全bug，激励程序员编写安全的代码
17.4 需求分析与设计阶段
应该建立安全编程的代码库，以及一些比较常见的安全编码问题。
17.5 开发阶段
Sun 的安全编码指导方针:
q 小心使用 特权代码
q 小心处理 静态字段
q 最小化作用域 (scope)
q 小心选择 公共 (public) 方法和字段
q 适当的 包 (package) 保护性
q 尽可能使用 不可变 (immutable) 对象
q 永远不要返回对包含敏感数据的内部数组的引用
q 永远不要直接存储用户提供(user-supplied)的数组
q 小心使用序列化(Serialization)
q 小心使用本地方法(native methods)
q 清除敏感信息
Java 安全反模式
q 忽略那些全模式的代码不经意间就会造成漏洞
典型的 Java 安全编码反模式(Antipatterns):
忽略语言特性 (例如整数溢出 (Integer Overflow) )
不注意使用序列化, 不注意使用 特权代码
将字段和方法定义到不适当的可见性作用域
在非终态 (non-final) 静态字段中的隐蔽通道(Covert Channels)
17.6 测试阶段
参考资料：http://blog.csdn.net/Test_sunny/article/details/4653783
http://51CTO提醒您，请勿滥发广告!/ceshi/ceshijishu/aqcs/2013/0715/206456.html
http://51CTO提醒您，请勿滥发广告!/ceshi/ceshijishu/aqcs/2012/0329/204547.html