开发安全铁三角
为了能更好地理解今天所讲，请大家先回顾一下之前“开发安全铁三角纵横谈”内容。
安全编码
安全设计之后，进入安全编码环节，安全编码环节的“规”主要就是安全编码规范了。从技术难度来说，安全设计比安全编码难多了，从管理来说，则正好相反。因为参与设计的人通常都是少数，而且一般都是骨干，水平相对较高，而参与开发的人员比设计的多得多，水平也参差不齐，所以管理很困难。总体来说，在这个环节有两个极端的想法，一种是要把安全编码规范用好，解决开发过程中的所有问题；另外一种就是编码规范落不了地，完全没有用。这两种想法正是安全编码处境尴尬的原因，一方面赋予太多希望，另一方面实践中有很多限制，导致太多失望。要改善安全编码的管理，本质上两条：（1） 规范的归规范，指南的归指南
安全编码规范是明确编码安全要求的，不是去告诉你怎么安全编码的，告诉程序员怎么安全编码，应该叫安全编码指南，指导程序员去日常编程。做规范的时候，考虑是要求明确、适度，不去考虑实现问题，那个留给做指南的去考虑（安全编码指南部分在本专题的安全能力提升部分去讲）。（2） 定位准确
安全编码规范类似宪法，必须要有，明确开发团队在编码安全时要考虑什么内容，用什么思路去实现。但不能指望它去解决所有问题，导致负担太大，反而效果最差。实际的安全编码规范(部分)如下：第三章 应用安全
第六条输入验证应统一，应对业务参数和其他输入均验证。
第七条输出时需进行实体转换，防止嵌入可执行脚本风险。
第八条用户认证应保持唯一性，防止被破解。
第九条登录和交易应使用图形认证码等方式。涉及敏感信息的外部系统连接必须使用身份验证登录，未登录用户不能访问任何账户信息。
第十条密码应采用国密算法加密，保证密码强度高不易被破解。如果采用手势密码，需使用我行的手势密码控件安全加密传输，键盘应至少为3*3的矩阵要求。
第十一条会话安全应使用较强的会话标识符并进行有效性限制，禁止在cookie存储敏感信息。
第十二条访问控制按照最小授权原则并遵循。
第十三条系统中如果使用第三方组件，建议使用稳定的版本。
第十四条处理错误和异常情况期间，应防止信息泄露。对每个重要的行为都进行日志记录。
第四章 网络与通信安全
第十五条信息传输应使用强壮的加密算法和安全协议保护客户端与服务器之间的连接，保证传输数据的机密性和完整性。
第十六条客户敏感信息涉及跨境传输过程中需要进行加密传输。
从以上安全编码规范样例可以看出，安全编码规范强调结果和大的思路，比如解决防SQL注入，它不是说防SQL注入要过滤什么，要做编译化查询，它强调的是要统一验证，要完整验证，这个是符合开发团队的思维模式，是考虑整体高效解决问题的模式。回答开发团队在安全编码时，要注意什么，思考的关键点等，这是安全编码规范的使命，其他则留给别的制度和方法去解决。
下一章节我们聊聊安全测试等环节的内容。