许多软件上线后出现的安全问题，都是可以在开发阶段就通过某些手段规避掉的。除了大环境上没有相关的体系或标准强制约束以外，即使开发人员或项目经理有意识在开发阶段添加一些基础的安全防护机制，但更多的情况下，则是无从下手。不知道问题可能会出现在哪里，也不知道如何防患于未然。
开发者可以从哪些角度来考虑安全？11月19日，由国内开发者社区SegmentFault举行的全国性开发技术交流大会SFDC（北京站），就首次以“安全”作为开发者大会的主题，进行探讨。
业务安全
如果暂时不考虑国家安全这个层面，那么网络安全的核心价值则在于对企业业务的支撑，同时这也是大部分企业的命脉所在。然而，不同于政治动机或经济利益驱使的具备较强入侵技术的黑客组织，黑（灰）产的目标则是通过一些操作简易的自动化工具，从业务逻辑漏洞本身出发，来大批量地搜刮本应属于消费者或侵害商家的利益。
未知攻焉知防？岂安科技的CEO罗启武，就作为第一位演讲嘉宾详细介绍了线上应用的业务常见的安全问题。
做业务安全，我们要默认每个人都是坏人，每个人的默认值都是负100分，然后通过一些安全机制去判断，慢慢修改对其的印象。
线上业务，在“产品宣传->用户注册->用户登录->订单生成->支付”这一大致流程中，企业要有能力判断注册的信息是否为虚假，登录行为是否异常，以及支付成功的判断机制是否会被绕过等安全问题。
1. 利用机器人实现低成本对短信接口数据的爬取，造成企业短信资费损失，正常短信发送延迟。
处理思路：在开发阶段，对用户申请短信验证码的频率、是否为单一IP源或代理IP以及访问路径做限制。
2. 用户账户方面，存在虚假手机号、身份证、银行卡号、IP、邮箱地址等虚假用户身份，以及因为其它站点的账号数据泄露而存在的近乎自动化的撞库行为（验证码可半自动化识别，IP地址也会有代理自动切换）。
处理思路：限制IP的登录频率，IP对应账户数量以及账户登录的频率，常用登录区域，以及是否有登录大量垃圾账号的行为。
3. 薅羊毛、恶意占用库存的订单，以及信用卡盗刷/拒付等虚假交易。
处理思路：结合设备指纹，通过实时/历史行为分析来构建用户画像 ，并结合黑产情报（失信黑名单，代理IP，欺诈电话平台等数据），对业务系统进行审核和支撑。
除了专做业务风控的岂安科技在对抗黑产上的现状和思路分享外，为阿里巴巴电商业务提供风控能力支撑的阿里聚安全，则在大的安全体系框架建设上有自己的实践经验。
安全问题之于业务来讲，经常是说的时候重要，做的时候次要，忙的时候不要。
据阿里聚安全高级安全专家方超介绍，保守估计国内黑产从业人员数量150万+，市场规模1000亿+。在整个产业链方面，有图片/手机验证码平台、社工库、代理软件等提供黑产基础服务的上游，也有进行垃圾注册、盗号、洗号等账号生产销售的中游，也有通过这些中游“生产”出的非法账号进行欺诈、盗窃、勒索、刷单等网络犯罪的下游服务。可见目前黑（灰）产业链已经非常完善。而在业务防控的难点，就在于：实时性要求高、黑产专业化、业务种类多、平台对安全软件的限制大、新手段层数不穷和攻防要求高（更多的是业务层面）。
在安全方面，阿里的团队规模和投入也远远大于中小企业，可以成体系/框架地进行安全性设计，并针对不同的风险，将内容、行为、账户、人、设备、基础数据等进行不同的组合，构建多维度的数据与识别能力。
另外，在移动应用安全安全方面，针对应用被破解的风险、接口盗刷、应用漏洞与应用仿冒方面，在移动应用设计、开发、测试和上线阶段进行了安全设计。特别，在开发阶段，对密钥、算法等核心安全组件强制要求进行分开存储，并试图在安全性与移动端的用户体验取得平衡，将安全能力固化在sdk中。
移动安全
在下午的移动安全专场，小编特意关注了两个移动安全议题。
首先是花甲科技CTO，同时也是开源工具 dex2jar 的作者泮晓波在移动应用反编译能力提升方面的思路。即利用Dalvik代码的执行机制，将标准公开的Dex指令文件和Dalvik VM，在保证指令语义和实现逻辑没有变化的前提下，全部转化为自动以的文件格式，从而减少攻击面，提高攻击者成功进行执行代码逆向的难度。
同时，作为花甲科技针对安卓系统应用的“安全增强”解决方案的一部分，结合S-TEE（《这家移动安全初创公司用软件实现TEE》），实现动态性的安全防护，而不再是一次性的应用加固。
安全性和应用性能是有矛盾的，要有个权衡。这个方案目前只会针对应用实现如登录、支付等关键功能的指令，进行保护。
同时，还有360 VulPecker Team的安全研究员潘宇带来的，对安卓操作系统已知漏洞的修复情况排查，以及未知漏洞挖掘上能力的分享。
在已知漏洞的修复排查方面，除了手动逆向外，还可以利用360 VulPecker Team根据某开源框架定制开发的VPS和VTS自动化监测工具，分别通过尝试漏洞触发和检测安全补丁变化内容，来验证漏洞是否存在以及是否成功修复。同时，后台根据程序的依赖图和特征，进行文件相似度比较。
在未知漏洞挖掘方面，则更多的是通过源码审计、模糊测试、符号执行（帮助fuzz）和逆向工程来实现。
目前这些工具还仅限在360手机开发部门使用，之后也会一直更新，并且可能会把这个能力开放出来，让所有安卓手机厂商操作系统的开发部门都可以用它开发出更高效更有安全强度的代码。这也是这个项目最高的价值表现。
系统架构层面的安全设计
来自华为的安全专家毛哲文，在安全架构设计这个层面，从系统安全、数据安全、网络安全、平台安全、物理安全、安全运维等角度，详细阐述了安全架构设计涉及的因素及实践体会。
安全需求，特别是来自业务自身的安全需求，需要我们在安全架构设计之初，就能够识别关键业务和关键资产，并定义系统的安全边界，对关键数据在系统中的流动进行分析，以及不同业务场景下的安全威胁和攻击面的分析。
开发者的目的是实现功能需求，尽快上线运营，但安全性的考量则是要让他们“刹车”。这与开发者的初衷是相悖的。而在对软件质量的考量上，即使有相关的标准和最佳实践加入了安全性这一要素，但是缺乏监督和惩罚力度的现状，也让企业在开发成本的限制下，置背后的安全风险和责任于不顾。这时，就非常需要安全圈通过SegmentFault这样一个开发者社区向开发者这个独立于安全圈的团体发声，告诉他们开发过程背后的安全隐患和解决问题的思路方法，并在一定程度上增强开发者在开发过程中的安全意识。这也是此次SFDC对安全和开发，这两个圈子结合的最大意义和价值所在。
