安全三要素：机密性（加密），完整性（数字签名），可用性（DDos攻击）
安全评估：资产等级评估=》威胁分析=》风险分析=》设计安全方案
在安全评估中的威胁分析和风险分析又该如何做呢？微软给出了两个较为成熟的模型帮助我们进行分析：
STRIDE模型和DREAD模型
威胁分析就是把所有威胁都找出来。怎么找呢？有一些比较科学的方法，比如使用模型帮助我们思考，哪些方面可能有威胁存在。
这里介绍一个DREAD模型，它最早是由微软提出来的，它包含6个单词，我们在进行威胁分析时可以从以下6个方面去考虑：
| 威胁 | 定义 | 对应的安全属性 |
| Spoofing（伪装） | 冒充他人身份 | 认证 |
| Tampering（篡改） | 修改数据或代码 | 完整性 |
| Repudiation（抵赖） | 否认做过的事 | 不可抵赖性 |
| Information Disclosure（信息泄露） | 机密信息泄露 | 机密性 |
| Denial of Service（拒绝服务） | 拒绝服务 | 可用性 |
| Elevation of Privilege（提升权限） | 未经授权获得许可 | 授权 |
如何更科学的衡量风险呢？这里再介绍一个DREAD模型，它也是由微软提出的。DREAD也是几个单词的首字母缩写，它指导我们应该从哪些方面判断一个威胁的风险程度。
| 等级 | 高（3） | 中（2） | 低（1） |
| Damage Potential | 获取完全验证权限，执行管理员操作，非法上传文件 | 泄露敏感信息 | 泄露其他信息 |
| Reproducibility | 攻击者可以随意再次攻击 | 攻击者可以重复攻击，但有时间限制 | 攻击者很难重复攻击过程 |
| Exploitability | 初学者短期能掌握攻击方法 | 熟练的攻击者才能完成这次攻击 | 漏洞利用条件非常苛刻 |
| Affected users | 所有用户，默认配置，关键用户 | 部分用户，非默认配置 | 极少数用户，匿名用户 |
| Discoverability | 漏洞很显眼，攻击条件很容易获得 | 在私有区域，部分人能看到，需要深入挖掘漏洞 | 发现漏洞极其困难 |
在DREAD中每个因素都可分为高、中、低三个等级。在上表中每个等级分别以3、2、1的分数代表权重值，因此我们可以具体计算出某个风险的风险值。
《 “STRIDE模型和DREAD模型” 》 有 29 条评论
SDL中的密码学应用
http://www.freebuf.com/articles/database/134783.html
开发团队面临的三大安全挑战
http://insights.thoughtworkers.org/three-security-challenges-of-develop-team/
`
挑战1：一次性的安全检查无法匹配持续性的交付
挑战2：缺乏自动化、自助化的支持，安全实践落地难
挑战3：高耸的部门墙让开发和安全团队难以进行高效的协作
开发团队可以通过自动化，显著降低安全实践的实施难度和成本，把一次性的安全检查转变为持续性的安全质量反馈。对于安全团队，也应当向着开发团队迈进一步，打通开发和安全部门之间的隔离，以更加紧密和高效协作的方式，共同确保应用具备更高的安全质量。
`
【安全那些事儿】金融科技SDL安全设计checklist
https://mp.weixin.qq.com/s/MR3SmOLj834LK4RBMcZ2pg
`
SDL安全设计checklist目的
1、安全设计和安全编码
指导开发人员安全设计和安全编码实现，提高安全质量
2、安全测试
指导测试人员安全测试：提供测试案例参照与测试结果校验
3、安全配置
指导运维人员安全配置：面向操作系统、中间件、数据库等进行安全配置
`
威胁建模介绍
https://xianzhi.aliyun.com/forum/topic/2061
`
威胁建模介绍
1 谁做/需要做威胁建模？
2 什么是威胁建模
3 在软件开发安全生命周期中进行威胁建模
4 为什么要做威胁建模？
5 如何做威胁建模
5.1 图表
5.2 威胁分析
5.3 缓解措施
5.4 威胁建模过程
6 实际的威胁建模示例
7 威胁建模工具
8 攻击库
参考
`
【软件安全设计】安全开发生命周期（SDL）
http://blog.nsfocus.net/sdl/
`
一、安全开发生命周期（SDL）是什么？
SDL介绍
SDL安全活动
二、安全设计核心原则
2.1 攻击面最小化
2.2 基本隐私
2.3 权限最小化
2.4 默认安全
2.5 纵深防御
2.6 威胁建模
三、STRIDE威胁建模方法
3.1 STRIDE介绍
3.2 威胁建模流程
3.2.1 数据流图
3.2.2识别威胁
3.2.3 缓解措施
3.2.4 安全验证
四、总结
五、参考文献
`
STRIDE威胁建模漫谈
https://www.secrss.com/articles/3298
`
安全属性：
机密性：保证机密信息不被窃取，窃听者不能了解信息的真实含义。
完整性：保证数据的一致性，防止数据被非法用户窜改。
可用性：保证合法用户对信息资源的使用不会被不正当的拒绝，如DOS攻击。
补充：
鉴权：身份验证，建立用户身份。
授权：明确允许或拒绝用户是否能访问资源，访问哪些资源。
认可（不可抵赖)：用户无法在执行某操作后否认执行了此操作。
十个安全设计原则：
原则1：最小攻击面
原则2：默认安全
原则3：权限最小化
原则4：纵深防御
原则5：失败安全
原则6：不信任第三方系统
原则7：业务隔离
原则8：公开设计
原则9：简化系统设计
原则10：使用白名单
威胁建模的通用原则步骤：
第1步：标识资源
第2步：创建总体体系结构
第3步：分解应用程序
第4步：识别威胁
第5步：记录威胁
第6步：评价威胁
STRIDE是微软开发的用于威胁建模的工具，或者说是一套方法论，它把威胁分成如下6个维度来考察：
Spoofing（伪装）
Tampering（篡改）
Repudiation（抵赖）
Information Disclosure（信息泄露）
Denial of Service（拒绝服务）
Elevation of Privilege（提升权限）
`
大数据威胁建模方法论
https://www.cdxy.me/?p=797
`
威胁建模本质上是一个自动化从数据中提取信息的过程。从各组件的可复用性和价值进行考虑，将完整的威胁检测模型解耦成五层进行介绍。数据在各层之间按顺序传递，完成从原始数据到上层知识的冶炼。
· 数据层：负责原始数据的采集、清洗，保证数据的稳定性与可用性，”数据基础决定上层建筑”
· 异常层：清洗掉系统内部的正常行为，为数据降噪，在不损失有价值信息的前提下降低后续步骤的分析成本
· 威胁层：从异常中识别威胁，产出IoA/IoC
· 事件层：从入侵事件维度聚合IoA/IoC、异常信息、威胁情报等标注数据，降低运营人员hunting成本
· 运营层：将安全运营人员对事件的运营结果反馈到模型内部，使模型能够”自我进化”
数据层
日志
如何选择日志
异常层
异常与威胁的关系
异常数据清洗的价值
过滤冗余信息
理解业务
威胁层
从异常到威胁
信息穿透
事件层
马赛克调查墙(Mosaic Investigation Wall)
威胁情报可视化
不止于外部威胁情报
运营层
难以消灭的误报
将人工运营结果反馈到模型
`
基于DREAD模型的漏洞等级计算
https://mp.weixin.qq.com/s/-gHMhj1Qdl1N5rCne61m4Q
`
一、选型
如前文所述，已知的漏洞计算模型包括cvss，dread，owasp，还有各大src现在应用的方式，真正准备进行标准化前针对各个模型进行了初步的调研。
调研前首先明确，这套模型需要明确几个概念：
1.目标对象
是用在SRC收集漏洞上，而不是单纯的内部扫描器稳定产出的结果，这就意味着收到的漏洞可能场景更复杂，更难以按照类型单一标准化。
2.目标人群
外界的白帽子是第一优先用户，内部安全工程师是第二用户，内部的各个业务方包括开发运维测试是第三用户。也就是说，这里面大部分的用户都是非企业安全建设的用户。
3.漏洞等级的定义
依据是——“可能带来的影响”。可能带来的影响，既不是指某类漏洞的危害（这里指漏洞的等级不止需要考虑该漏洞本身，同时要考虑这个类型的漏洞实际影响的业务等多个维度），也不是已经带来的影响（已经带来影响的，可能已经是安全事件了）。
4.漏洞类型的范围
除了传统的Web安全漏洞，系统网络安全漏洞和移动客户端的安全漏洞，可能还需要包括业务安全、业务逻辑，第三方平台信息泄露等，因为随着安全的发展，出现的各种新型安全问题越来越多，也超出了原本技术漏洞的范畴，是更广义上的漏洞。
二、等级计算
DREAD模型的计算方式：等级=危害性+复现难度+利用难度+受影响用户+发现难度
已有的等级计分分数标准，结合DREAD的等级计算方式，最终适配出来的分数是：
等级[忽略(0),严重(10)]=(危害性[0,4]+复现难度[0,4]+利用难度[0,4]+受影响用户[0,4]+发现难度[0,4])/2
三、等级定义
1.危害性（Damage）
2.复现难度（Reproducibility)
3.利用难度（Exploitability）
4.受影响用户（Affected Users）
5.发现难度（Discoverability）
四、问题和校正
`
https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model)
https://www.jianshu.com/p/3534c30c0a83
http://www.sohu.com/a/123809332_505884
http://www.aiuxian.com/article/p-1962153.html
安全代码审查的checklist
https://www.softwaresecured.com/secure-code-review-checklist/
`
信息收集(Information Gathering)
配置(Configuration)
传输安全(Secure Transmission)
认证(Authentication)
会话管理(Session Management)
授权(Authorization)
数据验证(Data Validation)
应用输出(Application Output)
密码学(Cryptography)
日志管理(Log Management)
`
A list of web application security
https://github.com/infoslack/awesome-web-hacking
应用安全测试的魔力象限(Magic Quadrant for Application Security Testing)
https://www.gartner.com/doc/reprints?id=1-4RBB1XO&ct=180216&st=sb
`
Static AST (SAST) technology analyzes an application’s source, bytecode or binary code for security vulnerabilities typically at the programming and/or testing software life cycle (SLC) phases.
Dynamic AST (DAST) technology analyzes applications in their dynamic, running state during testing or operational phases. It simulates attacks against an application (typically web-enabled applications and services), analyzes the application’s reactions and, thus, determines whether it is vulnerable.
Interactive AST (IAST) technology combines elements of SAST and DAST simultaneously. It is typically implemented as an agent in the test runtime environment (for example, instrumenting the Java Virtual Machine [JVM] or .NET CLR) that observes operation or attacks and identifies vulnerabilities.
Mobile AST performs SAST, DAST, IAST and/or behavioral analysis on byte or binary code to identify vulnerabilities in mobile applications.
`
业界代码安全分析软件介绍
https://mp.weixin.qq.com/s/yGvwRF5Q9YLHo1LZqfBqtQ
`
应用安全分析类型按照使用场景分为四类方向：
1、静态AST（SAST）技术通常在编程和/或测试软件生命周期（SLC）阶段分析应用程序的源代码，字节代码或二进制代码以查找安全漏洞。
2、动态AST（DAST）技术在测试或运行阶段分析应用程序的动态运行状态。 它模拟针对应用程序（通常是支持Web的应用程序和服务）的攻击，分析应用程序的反应，从而确定它是否易受攻击。
3、交互式AST（IAST）技术同时结合了SAST和DAST的元素。 它通常作为测试运行时环境中的代理实现（例如，测试Java虚拟机[JVM]或.NET CLR），用于观察操作或攻击并识别漏洞。（可以发现iast类似于rasp，可以同扫描器结合起来将安全检测融入产品，通过类似于打桩的机制判断漏洞真实性。）
4、Mobile AST对字节或二进制代码执行SAST，DAST，IAST和/或行为分析，以识别移动应用程序中的漏洞。
静态代码审计目前比较好的案例有Android方面改造的静态检查组合sonarLint + findbugs + Android Lint 。但是对于服务器端代码质量和安全方面都检测手段还是严重不足的。目前的开源工具普遍适用于表现在对代码检测，而不是安全检测，发现着重于bugs而不是vulnerabilities。
优秀公司实践：
· Google
使用gerrit这样的代码review系统基本保障质量，曾经使用过数年的各项商业软件。Error Prone用在Google的Java构建系统中，发现并减少各种严重Bug。
· 阿里
消息显示阿里内部SDL推行较早，使用称为stc的软件，s一直在做推进安全编码，也有自研源码扫描器。主要是项目周期短，发布快，项目又多，安全人员少，只能尽量走自动化路线，但是像漏洞和代码分析，架构设计安全审计这些，自动化目前还无法办到。
· 华为
华为使用商业安全工具平台，有自定义规则，但是没有自研产品。
细分商业领域产品厂商
gartner关于应用安全测试方面的魔力象限：
Coverity (Synopsys)
Fortify (Micro Focus)
AppScan (IBM)
Checkmarx (https://www.checkmarx.com/)
Veracode (https://www.veracode.com/)
`
开源工具介绍
https://github.com/google/shipshape
https://github.com/google/error-prone
https://github.com/facebook/infer
http://magic.360.cn/zh/index.html
https://spotbugs.github.io/
https://github.com/find-sec-bugs/find-sec-bugs/
【干货分享】 宜信SDL的深入探究与实践
https://mp.weixin.qq.com/s/o7tLw8nnNEw3mqRmi0adIA
`
宜信SDL整体解决方案参照微软模型做了一些调整，对于SDL活动项、SDL敏捷化和傻瓜化的实现路径进行调整和补充。
1、安全需求分析
2、威胁建模
3、安全设计技术规范与CheckList
4、安全组件/平台
5、安全编码规范
6、代码白盒安全扫描平台
7、渗透测试
8、系统黑盒/被动/PoC扫描平台
流程化→制度化→工具化→平台化 +敏捷化、傻瓜化
SDL工作的其他感悟：
安全即服务
融洽的安全服务关系
安全敏捷与DevSecOps
SDL作为安全服务并不排斥安全绩效考核，如果SDL团队既有考核的话语权，同时又能放下身段，具有安全服务的理念和能力，一定可以将SDL工作开展的更顺畅更有效果。
SDL没有固定形态，一切SDL活动的执行都需要因地制宜， 但核心的SDLaaS的理念需要长期支持，贯穿到SDL团队日常的每一项活动中去，终有一天，安全团队与各业务团队面临安全问题时，携手前行，相互支持，荣辱与共，最终为业务搏出一个安全而又明亮的前程，我想这是我们所有SDL工作者的共同愿望。
`
SDLC-DREAD威胁评级模型
https://blog.csdn.net/qq_29277155/article/details/89948772
`
威胁建模工具是 Microsoft 安全开发生命周期 (SDL) 的核心要素。潜在安全问题处于无需花费过多成本即可相对容易解决的阶段，软件架构师可以使用威胁建模工具提前识别这些问题。因此，它能大幅减少开发总成本。此外，我们设计该工具时考虑到了非安全专家的体验，为他们提供有关创建和分析威胁模型的清晰指导，让所有开发人员都可以更轻松地使用威胁建模。
通过使用Microsoft threat-modeling工具进行威胁建模后，我们需要对威胁进行评级，进行优先排序。
0x01威胁评级DREAD
0x02 CVSS（通用漏洞评分系统）
0x03 OCTAVE
`
Threat Risk Modeling(OWASP翻译4)
https://www.jianshu.com/p/3534c30c0a83
`
当你开始设计一个web应用时，进行应用风险建模是必需的；否则你将因没有关注真正的风险控制而浪费资源，时间和金钱。有许多种途径进行风险建模，列表如下：
以软件为中心的威胁建模
以安全为中心的威胁建模
以资产或风险为中心的威胁建模。
`
基于DREAD模型的漏洞等级计算
https://www.anquanke.com/post/id/161442
`
一、选型
二、等级计算
三、等级定义
1. 危害性（Damage）
2. 复现难度（Reproducibility)
3. 利用难度（Exploitability）
4. 受影响用户（Affected Users）
5. 发现难度（Discoverability）
四、问题和校正
`
安全架构评审实战
https://mp.weixin.qq.com/s/YQn1FQICk1esxvBCHZntFA
`
确定一个应用的安全状况，最直接的方法就是安全评审。安全评审可以帮我们发现应用系统中的安全漏洞，也能了解当前系统，乃至整个防护体系中的不足。完整的安全评审会包含安全架构评审、安全代码审核和安全测试三个手段。
安全架构评审，着眼于发现安全设计的漏洞，从宏观的视角整体评价一个应用的安全性，快速识别业务系统核心安全需求以及当前安全防护机制是否满足这些需求，是投入产出比最高的活动。因此安全架构评审，直接影响整个安全评审的质量，并为安全编码和安全测试指明重点。
本文通过从方法论到实际模型，对安全架构评审过程进行阐述。不论你是安全从业人员对第三方应用系统进行安全评审，还是作为产品的研发人员、架构师，依据本文提到的方法深入学习、反复实践都能提高自己的架构评审能力。
理论篇：安全架构设计的特点
遵循安全设计原则
● 纵深防御
● 最小权限
● 默认安全
● 注定失效
● 适用性原则
● 开放性设计
安全防护的三大支柱
● 事前：防御与保健
● 事中：监控和响应
● 事后：恢复和止损
安全控制技术武器库
● 认证和访问控制：如IAM、会话管理，都属于这一类，是最直接建立网络世界信任的一种机制。原则上，任何跨边界的访问，都需要认证和权限控制。这里又涉及到人机之间的UI和机器间的服务调用两类访问的控制。
● 加密：加密是除认证之外数据保护的又一利器，包括传输加密和存储加密。加密方案具有复杂度高、实现难度大、业务影响深的特点。因此加密方案必须精心设计，建议采用外部已经成熟的方案，如TLS/https、KMS/HSM等。此外，加密还是其他防护技术的基础：认证凭据密码、会话ID的创建，保存都需要密码学介入。密码学就提一点，千万别自创算法。
● 日志、审计和风控：这块主要属于事中和事后范畴。当下一般企业都有自建日志中心，数据处理能力也都能上升到PB级别。日志能否覆盖所有的访问入口，能否针对异常行为触发告警是一个核心的能力。
● 网络隔离：传统的网络防火墙以及主机防火墙，或者网络ACL，这类因为业务无关性，控制效果非常好，但也非常复杂，维护成本高，加上对纵深防御，以及零信任网络理解的偏差，导致很多互联网公司把防火墙边缘化。近年出现的SDN技术，可以通过软件自动对访问规则进行定义编排，实现ACL自助化的趋势，让防火墙又能够产生更好的效果。
实践篇：实施安全架构评审
安全需求分析
安全目标综述
通用安全需求
常规的安全需求包括：
● 身份认证的安全需求
● 会话安全需求
● 权限控制安全需求
● 日志审计安全需求
● 数据加密安全需求
● 网络以及其他隔离安全需求
● 基础设施安全需求
● 安全编码相关需求
`
默安科技云舒：十五年后，重谈安全开发体系
https://mp.weixin.qq.com/s/zbrisbW6IvsFcZDQD4ZGKw
`
4.1 SDL的本质
SDL的目标主要是两个，增强安全性和降低成本。某种意义上，如果将“增强安全性”当作必须满足的要求，那么降低成本就成了SDL的唯一目标了。这里的成本主要是漏洞修复成本。
漏洞发现得越晚，修复成本越高，如果是线上运营的系统被爆出漏洞，修复成本除了下线、修复、重新上线导致的业务损失成本、人员成本之外，甚至还包括了消除公关事件影响方面的成本。所以需要在产品上线之前建设安全开发体系，尽可能早的发现、解决安全问题。最直观的做法就是安全部门在产品上线前拿漏洞扫描器扫描一下，有问题打回去改造。
这里其实就是SDL的本质所在，安全前移。
完整的开发体系，可能包括产品需求设计、架构设计、编码、测试、安全检查、上线运营等几个步骤，更早些年是用漏扫扫描线上系统，后来意识到了越早解决成本越低，就在上线前扫描，往前移了一步。继续深入下去，安全还可以进一步前移，上线前安全审查期前移到QA测试期，前移到开发期，前移到产品需求期。
安全前移的挑战在于目标群体其实是不懂安全的，比如QA，比如研发，这就要求安全部门通过一系列产品赋能给他们。相对应的安全产品，可能是黑盒扫描（DAST：动态应用安全测试）、灰盒扫描（IAST：交互式应用安全测试）、白盒扫描（SAST：静态应用安全测试）、威胁建模，以及全流程的开发安全培训。
总结起来SDL的本质就2个关键词——前移、赋能（赋能是实现安全前移必须的条件）。
4.2 如何落地
安全部门想落地SDL，要永远记着一句话：SDL项目不是安全自己的项目，是安全和产品、研发、QA一起的项目。做SDL的基调，得先明白这几个部门之间的关系，再定下来。
所以做SDL的基调就是柔和低侵入、低误报多建议。柔和是指一定要依附在企业原有的开发测试平台来做，安全相关的产品接入SVN接入Jenkins接入Jira，支持LDAP等第三方认证，努力去适应他们的体系，减少需要对方改变或者操作的地方。同时，安全产品要将误报控制在非常低的限度，并且提供非常简洁清晰干脆的解决办法，这一点也是能把安全赋能给QA和开发的先决条件。说难听点，误报了研发和测试都会感知到，马上来找麻烦，误报也确实也影响到了他们的本职工作。漏报了他们不知道，也不会影响他们的工作，而且即使知道了也不会主动出来找安全部门打自己。
基调有了，那么，威胁建模、SAST、IAST和DAST等4个产品，怎么落地效果最好且最经济就非常清楚了。我的判断是先IAST再SAST然后威胁建模。至于DAST可以不放进SDL项目中，而是由安全人员自己运营，检查线上运营中的业务。
4.2.1. IAST
先做IAST是因为相比SAST它的误报更低，相比DAST，它实施使用更简单，扫描更全面，而且和QA原本的工作结合更容易。我认为IAST最好需要提供4种接入模式：代理模式、流量镜像模式、插桩模式以及日志平台模式，确保能够适应企业复杂的业务场景。其中代理模式和插桩模式是必需的。
4.2.2. SAST
SAST最大的问题就是误报和漏报同样突出。一个系统，有20个漏洞，SAST扫描一下可能报告100个漏洞，其中10个是真的漏洞90个是误报。在大部分公司里面，以现阶段这种研发与安全的关系，肯定是用不起来的。另一个角度，SAST可以发现的这10个漏洞，IAST一般也能发现。这么看，SAST似乎毫无价值，是不是不要做？不是，还是得做。因为SAST可以把漏洞的发现和修复闭环在研发阶段，连QA都无需介入，是将安全继续前移了一大步。那么关键问题就是怎么做，既能够保留成本低的优势，又能去除误报漏报带来的危害呢？
4.2.3. 威胁建模
安全再往前移一步就到了产品设计环节，对应的安全就是威胁建模。其实以现在的技术水平，安全越往前移，控制力度越差，对产品最终的安全提升越小。IAST是效果最好的环节，SAST是锦上添花，威胁建模就是花上再添花了。
通过问答式表单，让PD选择产品功能需求，系统自动生成一份安全需求文档，然后架构师依据这份文档来进行安全设计。问题在于生成的这个安全需求文档是纯粹的指导性意义，没有任何可以自动检查的手段，容易流于表面。
所以建议是最后做，不缺钱的时候，有总比没有好。
4.3 简单总结
SDL方案要柔和、低侵入，不改变研发和QA的工作习惯，不增加他们的工作量，认证、使用方式都要接入原本的研发流程系统，不能另起炉灶。安全测试优先控制误报，允许漏报，所有的修复建议和方案要以安全组件库为基础，细化到用哪个函数的程度。
先上IAST，把安全做到80分。然后上SAST，锦上添花做到85分。安全培训贯彻始终，基于安全组件库来讲安全，做到有的放矢。最后，有钱可以搞搞威胁建模。
`
聊聊对目前Passive IAST的思考
http://rui0.cn/archives/1175
`
Passive IAST原理
# 核心
利用Instrumentation API我们可以提供一个Agent代理用来监测和协助运行在JVM上的程序，可以在程序启动前修改类的定义。简单来说就是在运行的应用中织入一个我们的程序。而在这个程序中我们就拥有了获取当前应用的上下文，在应用运行中实时分析数据流以及调用栈的能力，同时也可以通过ASM对已经加载的class进行分析与修改。
在织入我们检测的逻辑代码后，被动式IAST主要是通过污点跟踪的方法来对漏洞进行检测，因为是实时数据流，所以这里我们称为动态污点传播分析。这是与静态扫描中污点分析的一个小区别，而其优势和劣势也主要在这里。
# 插桩&ASM
插桩技术是在保证目标程序原有逻辑完整的情况下，在特定的位置插入代码段，从而收集程序运行时的动态上下文信息。目前基于插桩技术实现Java程序的动态交互安全监测已经有一些实现形式，如RASP，IAST。在Java中插桩通过Instrument以及字节码操作工具(如:ASM,Javassist,Byte Buddy等)实现。细节此处也不展开了，具体可以参考这篇文章插桩技术在Java安全中的应用简述
# 动态污点传播
污点分析可以抽象成一个三元组的形式,其中，source即污点源，代表直接引入不受信任的数据或者机密数据到系统中；sink即污点汇聚点，代表直接产生安全敏感操作(违反数据完整性)或者泄露隐私数据到外界(违反数据保密性);sanitizer即无害处理,代表通过数据加密或者移除危害操作等手段使数据传播不再对软件系统的信息安全产生危害。污点分析就是分析程序中由污点源引入的数据是否能够不经无害处理,而直接传播到污点汇聚点。如果不能，说明系统是信息流安全的；否则，说明系统产生了隐私数据泄露或危险数据操作等安全问题。简单来说就是我们安全中常说的：一切输入都是有害的。
Passive IAST优势
大致原理也已经简要说了一些，我们再转过头来看看被动式IAST优势，以及它主要是覆盖什么应用场景。
# 优势：
漏报率低，采用污点分析
检测中无重放数据，不会产生“脏”数据
检测精度高，可以结合数据流以及请求上下文来分析
支持代码层面的分析
支持数据包加密场景
实时性强，同时可以构造验证漏洞请求包
操作简单，方便漏洞定位与修复
解决应用系统安全测试与效率的矛盾
# 应用场景：
用于SDL中安全测试环节
适用于上线前的测试，测试人员无需了解安全
针对APP存在数据流量加密
安全人力缺乏状况
`
论企业如何快速建立SDL流程
https://mp.weixin.qq.com/s/fIfMGD5HvjN_MVlVb3yriQ
`
要想做好企业的SDL建设，个人认为三个因素至关重要：公司制度、团队支持、SDL工程师。
* 公司制度：大部分公司处于初始阶段，没有任何安全建设方面的经验、文档以及工具，甚至公司高层对这方面严重忽视，摆个样子就行，这导致SDL实际落地非常困难，基本就是摆设。如果公司之前已经有相关的实施经验，那么推动起来要方便的多，SDL工程只需要在原有的基础上优化拓展就行了。
* 团队支持：目前大部分公司都有自己的安全团队，没有的可能也有相应的外包人员。日常的渗透、审计工作基本就是这部分人在完成，其实这是SDL建设的中坚力量，整个SDL工程最多最繁杂的流程全部依靠这部分人员。
* SDL工程师：第三个重要因素就是SDL工程师，作为SDL建设中最关键的部分，SDL工程师意味着整个落地效果的关键因素，SDL工程师的人选必须具备综合处理能力，不然很艰难。
整个SDL过程流程并不复杂，复杂的是具体实施细节，大概概况相关的难点，当然了，任何方案都不可能满足所有的实际需求，企业还是需要根据自身的实际情况去选择落地SDL，寻找适合自己的才最重要：
1、 第三方框架防治问题，可以维护自己的三方框架库，定期安全检测。
2、 扫描误报过高，大量数据筛选困难，可以建立优化整体规则库，重点关注中高危漏洞，配合工具扫描+人工筛查的方式进行，增量扫描可排除误报后无需扫描。
3、 阻挡业务正常流程，可根据实际情况，做到适度安全，有选择的对业务放行。
4、 业务太多，人员不够，可以针对重点项目实行SDL流程，以工具及其它人员配合的方式减少SDL工程师不必要的工作量，以达到SDL工程师作为验收者的目的。
5、 跨部门协作困难，可以说法公司高层制定相关流程，指定对接人。
`
SDL已死，应用安全路在何方？
https://mp.weixin.qq.com/s/tYRiKiI7bjgyzQguMA1mrw
`
# 前言
* 在安全行业，SDLC（软件安全开发生命周期）已经死了，如果各位安全从业人员还在追求所谓的微软最佳实践，立足的根本理念已经落后；如果信息安全管理者还看到下属做此类SDL的规划，那就是在浪费组织宝贵的预算。由微软早期提出的SDLC已经不适应现在的网络安全生态，不要照猫画虎不成反类犬，不要神化SDL理念，要看到与时俱进的安全风险，关注真实的风险治理。定位业界最佳实践可以是安全团队的追求，但更要立足于企业在大趋势下的安全背景。业界追求技术卓越的公司已经放弃了单纯在SDLC方向的投入，只有那些低头走路的小伙子，依旧在故纸堆里寻安全。
应用安全仍是重点投入领域
SDLC遇到的问题
* 安全并不是安全团队可以独立解决的事情
* 加强设计和部署阶段的投入是大势所趋
* SDLC适合软件开发，云和devops定义了新时代
* SDLC没有实现让业务承担责任
* 落地过程中缺乏协同性
* 缺少拥抱和激励安全的文化。
* 以大多数公司的基础安全建设来说，还不配做SDLC
真实的安全开发生命周期
* 软件安全开发真正要思考的问题。
* 为业务团队赋能
* 自动化能力的方向
* 重新审视纵深防御
* 教练的角色
* 让漏洞利用时间更长
ROI量化分析
`
秦波：大型互联网应用安全SDL体系建设实践
https://mp.weixin.qq.com/s/STBzFf-NtfbDEA5s9RBdaw
`
【嘉宾简介】在互联网荒芜时期蹒跚前行，作为安服老兵曾实践和标准化一些服务类型：渗透、评估、应急、培训，也是国内某top安全产品（第一款 waf）的早期研究人员，留下一些教材、国标、专利、工具和技术文章。2017加入滴滴，网络安全部负责人，包括SDL、移动安全、渗透蓝军、反入侵团队，从零开始建设 SDL 体系，经历了工具化 -> 平台化 ->自动化阶段。
● 其实SDL方法论早在十几年前就已形成了多个流派和最佳实践，以微软和McGraw的BSI两大流派尤为著名，前者在微软落地实践了OS和Office系列取得了卓效成就，这里就不赘述了，后者也在IEEE、searchsecurity多个学术机构发表技术见解，获益良多。
第一阶段 工具化（ 时间节点 170615 – 181115 ）
这个阶段万事开头难，由单兵作战改成确定的3个工作流（黑白盒漏洞导向、安全设计导向、应急导向）。落地细化部门规范和基本方法，建立基本工作框架。同时对现有环境全面梳理：
* 业务架构是什么：技术栈、业务形态、研发流程、常见漏洞类型、事件复盘（有些问题是短期解决不了的，涉及到业务技术底层的改造，悬挂风险）
* 发布频率
* 代码类型分布
* 资产范围
* 修炼内功
* 知识库、方案库标准化积累
* 外部漏洞分析，提高召回率，为插件做准备
* 需要沉下心来做工具开发。
* 漏洞处理流程
* 代码安全标准
* 新项目上线安全规范
* 第三方系统安全评估规范第三方
* SAAS服务安全评估标准设计安全标准
* SDL项目分级标准与执行标准
* 公共组件使用标准
总结一下这个阶段的特点：我们由原来的疲惫奔赴救火应急以及 DSRC 漏洞审核的局面，得到了极大的缓解。工作流基本 run 起来了，工具每天自动运行和闭环修复，标志点是检出率超过了 50%。
第二阶段 平台化（时间节点 181115 – 191015 ）
这个阶段的标志物是SDL平台上线到基线上线阶段。
我们自研了SDL平台，并逐步与研发相关活动流程打通。平台最开始就为了解决两个问题：1.整合工具链；2.对接研发流程。后续我们开始在SDL 活动的数据沉淀和打通、漏洞分析统计、资产管理等方面都做了扩展，总人力应该超过 3 个人年，但是非常值得的。这个阶段对常见漏洞的讨论都比较少了，召回率和精准率都趋于稳定了。重点关注：
* 标准化与人效提升
* 自动化运营
* 数据打通与沉淀
* 知识体系
* 指标体系
第三阶段 自动化（ 时间节点 191015 – 201215 ）
20%的人力完成 80%的日常运营，人效进一步提升，门槛进一步降低。
* 漏洞处理自动化闭环
* 代码审计
* 预发/测试环境
* 线上定期
* 安全评估自动化
剩下的80%的人：
* 攻防研究
* 业态、架构研究
* 非标准大项目的整体评估
* 工具链完善和扩展
* 流程前置和深化
* SDK和培训延伸到RD桌面
大致内容就这么多，我提炼得比较简洁。希望大家提问，互相启发。
`
构建企业级研发安全编码规范
https://mp.weixin.qq.com/s/PNvCvV4gYJkfIsKJ1ccneA
`
闭环思维和能力相辅相成。
本文主要介绍如何构建一套基于安全基础库所制定的安全编码规范以及如何在DevSecOps中进行落地，从而在日常研发中增强业务整体的安全性。
1、为什么需要安全编码规范+安全基础库？
大部分安全漏洞很大程度上是由于代码编写风格随意、编程语言特性理解不当、相关API使用不当造成的。为了解决这类问题，甲方安全部门往往都会整理一份安全编码规范文档来指导业务线规避不安全的代码写法，或者尝试使用静态代码扫描来识别代码漏洞。
不过，在各大公司中存在的“安全编码规范”大多数情况下仅仅是一份文档， 没有融入到研发链条中，无法有效地进行落地。同样的，单纯的静态代码漏洞扫描的局限性也有很多，比如在实践过程中难以维持误报、漏报的平衡，而且业务线的同学看到漏洞报警后，往往只关注如何处理漏洞报警本身，无法达到改变不安全编码习惯的目的。
由于传统安全编码规范仅凭罗列错误的代码写法、漏洞修复建议无法真正意义上指导业务线写出安全的业务代码。因此在我们DevSecOps安全实践中，将安全编码规范与安全基础库两者进行融合，同时配合使用代码静态分析手段对不符合规范的代码进行提交阻断，将安全编码规范检查落地到研发链条中，实现效果最大化。
2、构建有效的安全编码规范检查机制
有尽可能全面的SDK支持；
有全面的安全编码规范文档/说明；
能嵌入到代码提交环节做检查/拦截，然后提示阅读文档/使用SDK；
结合静态/动态代码扫描。
3、如何设计安全基础库
一个好的安全基础库需要满足以下条件：
（1）安全防护对研发透明：业务线无需主动判断在何处进行主动调用，最好将安全防护机制嵌入到框架层面
（2）覆盖的业务场景全面：由于安全机制需要融入到正常功能实现中，因此需要覆盖尽可能多的框架、类库、业务场景
（3）具备良好的兼容性：为了将安全基础库大规模推广，需要与现有的开发环境进行适配，具备良好的兼容性与持续升级保障
（4）具备先进的漏洞防护思路：安全防护机制应该做到健壮、全面、严密
（5）保证良好的调用风格：安全基础库中的API调用风格需要避免误用导致漏洞的情况，比如以绑定参数的键值对数组取代直接传入字符串的形式
4、总结
DevSecOps过程中的各种治理措施和工具一定是要向前靠拢，即尽可能将安全措施前置到研发周期最开始的阶段，问题发现的越早，修复成本就越小。而安全编码规范就是要作用于代码编写、代码入库这种比较靠前的研发阶段。通过安全编码规范+安全基础库+自动化静态代码检查相结合的形式，业务线可以在实现产品功能的过程中无感知地引入安全加固代码，显著提高代码安全性，从源头上解决大量的问题，值得甲方安全团队进行尝试。
`
简单理解污点分析技术
https://www.k0rz3n.com/2019/03/01/%E7%AE%80%E5%8D%95%E7%90%86%E8%A7%A3%E6%B1%A1%E7%82%B9%E5%88%86%E6%9E%90%E6%8A%80%E6%9C%AF/
`
1. 0X00 前言
2. 0X01 污点分析基本原理
2.1. 1.污点分析定义
2.2. 2.识别污点源和汇聚点
2.3. 3.污点传播分析
2.3.1. (1)显示流分析
2.3.2. (2)隐式流分析
2.4. 4.无害处理
3. 0X02 污点传播分析的关键技术
3.1. 1.污点传播中的显式流分析
3.1.1. (1)静态分析技术
3.1.2. (2)动态分析技术
3.1.2.1. 1.硬件
3.1.2.2. 2.基于软件
3.1.2.3. 3.混合型
3.2. 2.污点传播中的隐式流分析
3.2.1. (1)静态分析技术
3.2.2. (2)动态分析技术
4. 0X03 污点分析在实际应用中的关键技术
4.1. 1.Java Web 框架上的污点分析技术
4.2. 2.解决 JavaScript 上的污点分析
5. 0X04 总结
污点分析可以抽象成一个三元组的形式，其中，source 即污点源，代表直接引入不受信任的数据或者机密数据到系统中；sink即污点汇聚点，代表直接产生安全敏感操作(违反数据完整性)或者泄露隐私数据到外界(违反数据保密性)；sanitizer即无害处理，代表通过数据加密或者移除危害操作等手段使数据传播不再对软件系统的信息安全产生危害。污点分析就是分析程序中由污点源引入的数据是否能够不经无害处理，而直接传播到污点汇聚点。如果不能，说明系统是信息流安全的；否则，说明系统产生了隐私数据泄露或危险数据操作等安全问题。
`
What are the Microsoft SDL practices?
https://www.microsoft.com/en-us/securityengineering/sdl/practices
`
Practice #1 – Provide Training
Practice #2 – Define Security Requirements
Practice #3 – Define Metrics and Compliance Reporting
Practice #4 – Perform Threat Modeling
Practice #5 – Establish Design Requirements
Practice #6 – Define and Use Cryptography Standards
Practice #7 – Manage the Security Risk of Using Third-Party Components
Practice #8 – Use Approved Tools
Practice #9 – Perform Static Analysis Security Testing (SAST)
Practice #10 – Perform Dynamic Analysis Security Testing (DAST)
Practice #11 – Perform Penetration Testing
Practice #12 – Establish a Standard Incident Response Process
`
实践之后，我们来谈谈如何做好威胁建模
https://mp.weixin.qq.com/s/kNfTBoeFu90QPvYbPcR_OQ
`
1、写在前面
1.1 什么是威胁建模？
计算机发明后不久，人们就发现需要为这些信息系统处理威胁。早在1994年，NSA和DARPA就提出了攻击树、威胁树的概念，1999年微软内部发表了名为《The threats to our products 》的文章，为定义Windows全系产品面临的安全威胁正式提出了STRIDE助记符，随着2002年比尔盖茨著名的《可信任计算备忘录》宣言，微软承诺改善软件产品安全性，随即正式在SDL（安全开发生命周期）中采用了威胁建模。
威胁建模数十年来不断取得认可，业内有STRIDE、Trike、OCTAVE等多种方法论实践。安全行业普遍认识到，在研发团队的安全例行活动中，对于一些拥有重要数据资产、安全事件影响力大的系统除了要进行常规的渗透测试、黑白盒代码扫描之外，更应该系统地定期开展威胁建模活动并对业务赋能。
1.2 威胁建模的价值
识别体系化的结构缺陷：大多数安全问题是设计缺陷问题，而不是安全性错误。威胁建模能帮助识别这些设计缺陷，从而减少风险敞口，指导安全测试，并降低因安全漏洞而造成的品牌损害或财务损失的可能性。
节约组织安全成本：通过对威胁进行建模，并在设计阶段建立安全性需求，降低安全设计缺陷导致的修复成本。在需求管理和威胁分析阶段与业务开发团队高效互动，释放安全团队的专业能力，专注于高性价比的安全建设。
落地DevSecOps文化：通过威胁建模跑通开发和安全工具的流程集成，把风险管理嵌入产品的完整生命周期，从而推动形成完整的DevSecOps工具链。
满足合规要求：威胁建模是国际安全行业通用的方法论，通过向管理层和监管机构提供产品的风险管理活动的完整记录，帮助团队遵守全球法律法规要求如PCI DSS、GDPR、HIPAA、CSA STAR等。
1.3 遇到的挑战
普及威胁建模流程和技术可以有效提升企业安全建设水平，作为互联网公司实施敏捷软件开发流程，威胁建模活动也应尽量便捷，但实际工作起来并不简单，落地过程中也会遇到不少挑战，按优先级排序，挑战如下：
* 缺乏优秀的自动化建模工具；
* 安全团队没有时间和精力对每个应用都实施建模；
* 缺乏对威胁建模足够的了解，知识库涉及不同领域、专家经验难以共享；
* 建模活动、输出结果没有融入业务的敏捷研发流程；
* 简易的建模活动基于问卷或者表格记录分析，并没有实际的更新、积累和进一步分析。
2、准备威胁建模
2.1 能力要求
2.2 评估流程
3、实施威胁建模
绘制数据流图，识别定义威胁、处置威胁、验证风险得到正确处理是威胁建模的四个常用步骤。
3.1 数据流关系图都不准确，尽量有用而已
3.2 识别威胁是互动过程
3.3 处理威胁是重中之重
3.4 验证威胁达到闭环
4、如何评价这件事做得好坏
威胁建模不能立竿见影，建模没有什么特别的，对于业务方来说应该是同编码、测试、交付一样很普通的工作，安全也仅仅是日常工作的一部分。事情的主要目标是建立产品的安全属性，可以通过最终的安全缺陷改进情况、评审覆盖度、修复解决率作为过程指标，安全成熟度、安全事故数作为结果指标。实施投入威胁建模本身已经是一件技能很复杂的事情了，对参与人员引导做正确的事，不需要设置发现威胁数等硬性指标。
威胁建模在于对评估可能的风险、分析潜在攻击者的手法、攻击路径，提升产品的抗攻击韧性方面有独特的优势。这项方法论根本没有什么最佳实践，没有单一的“最好”或执行威胁建模的“正确”方法，而是为了满足解决这些威胁而实施的一系列复杂和多维度的权衡，唯有不断修正迭代才能完善。但如果没有威胁建模过程参与，组织不会清楚现有系统的安全现状。不管怎样，一旦你取得阶段性的成果，组织内部就认识到这样的协作可以对改善总体安全状况产生较大的作用，是高性价的投入，就可以克服关于威胁建模耗费人力、周期长、难点大这些阻力的声音，从而真正从事预防性的安全建设。
5、经验教训
通过制定的威胁建模计划同业务部门深入开展合作，团队完成了数十个项目的评估，发现了数百个高危设计缺陷，从而试图解决两类核心问题：1、人为操作导致的安全风险，2、安全融入基础架构。识别提炼出孵化出特权账户管理平台、服务鉴权、执行沙箱、全程票据、安全知识库等安全子项目。当然建模的效果有好有坏，我们仍需学习、调整、迭代。总结了如下的经验教训：
* 关注真实的威胁，从技术威胁入手延伸到业务威胁；
* 安全没有银弹，使用其他应用安全措施补充威胁建模；
* 见木不见林，致力于高效的建模，而不纠结于细节；
* 关注安全的沟通协作，改善研发解决安全问题的思维方式，胜于投入精力在安全测试。
`
https://michenriksen.com/blog/drawio-for-threat-modeling/
https://github.com/cncf/financial-user-group/tree/master/projects/k8s-threat-model
http://ceur-ws.org/Vol-413/paper12.pdf
https://community.iriusrisk.com/
https://aws.amazon.com/marketplace/pp/ThreatModeler-ThreatModeler/B07S65ZLPQ
https://threatdragon.org/login
http://mozilla.github.io/seasponge/#/
https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
http://www.owasp.org.cn/owasp-project/OWASP_Top_10_Proactive_Controls_V3v1.1.pdf
http://www.woshipm.com/it/1663882.html
https://developer.ibm.com/zh/components/redhat-openshift-ibm-cloud/articles/threat-modeling-microservices-openshift-4/
https://docs.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach
https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
https://csrc.nist.gov/publications/detail/sp/800-154/draft?ref=wellarchitected
https://github.com/google/end-to-end/wiki/Threat-model
https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
关于大型互联网企业DevSecOps体系构建的总结与思考
https://mp.weixin.qq.com/s/13VZsnv6dtJD550qmLGfaQ
`
最近几年随着软件供应链攻击和数据安全事件的频繁出现，企业面临着重大的软件供应链安全和数据泄露风险，这间接促使了越来越多的企业开始关注DevSecOps，并且期望借此来解决相关的安全风险。
在开始今天的分享之前，先简单介绍一下DevSecOps的定义，这里主要采用援引于DoD（美国国防部）的一段定义，即DevSecOps实际上是一种旨在统一软件开发、安全、运维运营的有组织的软件工程文化和实践。
DevSecOps is an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops).
由于DevSecOps理念是将安全防御思维贯穿到整个软件开发和运维运营阶段，这就使得DevSecOps体系的构建变成一个可能的解决数据安全和供应链安全的有效途径。今天的这篇文章主要来谈谈大型互联网企业DevSecOps体系构建的总结和思考，为了方便读者理解笔者将会以一个虚拟的公司Parana来做说明。
# 组织与文化
导读：正如DoD的定义中所讲，DevSecOps不是指具体的技术或者工具平台而是一种软件工程文化和实践，因此对于期望构建DevSecOps体系的企业来说首先需要建设这样的组织和文化。
# 流程与工具
导读：有了相应的组织和文化，接下来就是如何通过流程和工具将DevSecOps的理念固化下来，并持续运作。本节将从计划、开发、编译与测试、发布与交付、部署与运维、监控与反馈几个阶段进行介绍。
# 实践与安全
导读：DevSecOps流程的各个阶段中也面临着一些常见的威胁类型，本节将重点讲讲Parana公司的应对策略和落地措施。
`
每天扫描超 300 亿行代码，DevSecOps 在华为的落地与实践
https://www.infoq.cn/article/TbVZ4dOOQOq2WVemT3J2
`
# 从 DevOps 到 DevSecOps
针对 DevOps 领域的安全治理问题，Gartner 提出了 DevSecOps 概念。简言之，DevSecOps 是一种旨在将安全性嵌入 DevOps 链条中的每个部分新方法，它有助于在开发过程早期而不是产品发布后识别安全问题，目标是让每个人对信息安全负责，而不仅仅是安全部门。
# 对于 DevSecOps 的未来发展，章可镌分享了几个个人观点：
* 更左移
更左移，以期待更早地发现问题。以前有人说“质量是设计出来的”，他认为安全质量也可以朝这个方向去努力。“我们看到，很多初创公司或挣扎在生存线上的公司可能并不太关注安全，或仅关注 Ops 段的安全”。而有能力的公司会把安全控制向左移到 Dev 阶段。一开始，关注点会在后端测试阶段；再进一步，他们会追求在编码阶段就杜绝引入安全问题，考虑 Security as Code。更有追求者会在设计甚至需求分析阶段就考虑到尽可能多的安全威胁因素并制定消减措施。
* 更开放
DevSecOps 秉承了 DevOps 的开放思想。章可镌认为谈到安全，他理解为生态开放、心态开放。
生态的开放：兼容并包，例如提供开放的集成能力（可以集成第三方，也能被第三方集成）、工具能力二次开发。不仅是规则定制，甚至可以将分析过程的中间结果也开放出来，以满足更灵活的定制化需求。
心态的开放：理解安全是更专业的话题，需要专业的解决之道，愿意学习安全知识而非抗拒，比如安全设计与编码规范。
* 更高效
从安全角度看，对“高效”的诉求尤其强烈。对此有深入理解的人认识到有一些安全的工作无法避免人工操作，这也意味着需要更长时间。举个例子，设计阶段的安全分析工作还没有太好的自动化工具，那些更专业的安全服务目前还无法实现全自动化。SAST 基于编译的增量分析还需要解决不少的问题，当提高检查敏感度参数时，就需要安全团队的专家协作进行代码人工检视以及工具告警的人工排查。如何更高效地确保产品生命周期的安全，这将是 DevSecOps 的永恒课题。
`
Microsoft 威胁建模工具
https://docs.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool
https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
风险缓解
https://docs.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool-mitigations
`
审核和日志记录(Auditing and logging)：谁在何时做了什么？ 审核与日志记录是指应用程序如何记录安全相关的事件
身份验证(Authentication)：你是谁？ 身份验证是某个实体证明另一实体的身份的过程，这通常是通过用户名和密码等凭据完成的。
授权(Authorization)：该怎么办？ 授权是指应用程序如何提供对资源和操作的访问控制
通信安全(Communication security)：在与谁对话？ 通信安全可确保以尽量安全的方式进行所有通信
配置管理(Configuration management)：应用程序的运行身份是什么？ 它连接到哪些数据库？ 如何管理应用程序？ 如何保护这些设置？ 配置管理是指应用程序如何处理这些操作问题
加密(Cryptography)：如何保守机密（保密性）？ 如何防止对数据或库（完整性）进行篡改？ 如何针对必须强加密的随机值提供种子？ 加密是指应用程序强制实施保密性和完整性
异常管理(Exception management)：当应用程序中的方法调用失败时，应用程序会采取什么措施？ 透露的信息量有多大？ 是否向最终用户返回友好的错误信息？ 是否向调用方传回有用的异常信息？ 应用程序是否正常失败？
输入验证(Input validation)：如何知道应用程序接收的输入有效且安全？ 输入验证是指应用程序在进一步处理之前筛选、清理或拒绝输入。 请考虑通过入口点限制输入，通过出口点为输出编码。 是否信任数据库和文件共享等源中的数据？
敏感数据(Sensitive data)：应用程序如何处理敏感数据？ 敏感数据是指应用程序如何处理必须在内存中、通过网络或在持久性存储中保护的任何数据
会话管理(Session management)：应用程序如何处理和保护用户会话？ 会话是指用户与 Web 应用程序之间的一系列相关交互
`
从SDL到DevSecOps：腾讯云是如何更早地收敛安全漏洞的？
https://mp.weixin.qq.com/s/gfjwVs5Ckeqxc2-WqaZyqg
https://cloud.tencent.com/developer/article/1640879
`
随着云计算被普遍运用，微服务等基础架构的成熟，同时企业业务高速发展带来的对开发运维更高效的要求，企业开发运维模型也从传统的瀑布模型演变到敏捷模型再到DevOps。
而安全模型也随之改变，但其核心一直都是贯穿始终以及更前置的安全。其中“DevSecOps”是Gartner在2012年也提出的DevOps模式下的安全概念，人人为安全负责，让业务、技术和安全协同工作以生产更安全的产品。
# 从漏洞与威胁防御说起
假如问大家“如何收敛产品中的安全漏洞”，可能得到的答案是安全测试；而如果问题改为“如何减少产品中漏洞产生”，那么答案可能是“减少漏洞代码”。
其实两个问题得到的答案对应的是两种防御理论，一个是漏洞防御，一个是威胁防御。
# 更前置的安全
回到软件安全开发，不管是SDL还是DevSecOps，其中主要强调的一个就是安全前置或者安全左移，就是更早的在软件开发生命周期嵌入安全动作，就能更容易的收敛安全漏洞问题。
越早的收敛漏洞成本越低，而软件安全开发模型就是用于解决的方案。
# 安全开发生命周期(SDL)
SDL由微软提出并应用一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程，侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。
SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段：需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。
# DevOps与DevSecOps
对于DevOps来说，有个核心元素就是CI/CD，所以到DevSecOps，大家会发现在CI/CD嵌入安全也是一个重要环节。
相对于SDL，DevSecOps不再是一个单纯的安全开发模型，也不仅仅是关注开发阶段，它所强调的是人人为安全负责，人人参与安全，安全嵌入到开发到运维的每个阶段。
所以首先从角色角度，安全团队不再置身于业务之外，也不再是安全团队兜底安全，安全是一个开发、安全、运维、QA一起协作的过程
`