尽管行业目前高度依赖自动化扫描工具，但现实是：安全漏洞并非只源于代码编写错误，很多时候是应用逻辑层面存在结构性缺陷。
对很多开发者而言，安全往往被视为繁琐的管理流程。但在专业开发环境中，它必须被视作构建流程中实用且不可或缺的一环。
本文将跳出基础清单式思维，讲解如何为云原生应用构建由开发者主导的专业威胁建模方案。
内容速览→
现代安全环境假定网络边界已经遭受了攻击。这种观点的转变从根本上改变了你必须在应用程序内部建模信任的方式。你再也不能因为一个请求源自你的内部网络而简单地信任它。
传统的威胁建模倾向于将VPC（虚拟专用云）视为一个“安全区域”。专业的零信任方法将这一假设替换为每个API调用都是一个潜在的故障点。你必须为每个请求进行授权建模，并验证每次数据交换。虽然这种 rigor 的实现具有挑战性，但它可以防止攻击者在你的系统中水平移动，并确保应用程序验证每个身份。
Log4Shell 事件突显了现代开发中的系统性漏洞。日志库，曾经被认为无害，成为了远程代码执行的入口。你不能将第三方库视为“黑盒”；它们必须被视为你可能遭受攻击的脆弱部分。这需要“深度依赖”分析。如果一个库拥有过度或可能不必要的权限，它就代表了一个战略风险，必须在设计阶段解决。它能授予的最少权限集，同时仍然能够正常工作？
RAD Studio屡获殊荣的数据库InterBase拥有许多高级安全功能。探索InterBase 15安全功能这里。
在任何专业工作中，资源都是有限的。你不能同时减轻每一个威胁；这是需要优先考虑的地方。许多团队可能会在此 falter，依赖于未能考虑高影响事件的简单方法。
标准评分模型通常无法考虑“黑天鹅”事件——这些罕见的事件可能会对企业的运营造成灾难性的后果。专家们现在根据业务背景和“利用成本”来分类风险。如果一个漏洞对攻击者来说成本低廉，那么它就构成高风险，无论其感知影响如何，因此应成为你的优先事项。使用混合排名模型以确保你将精力集中在最重要的地方。
许多团队错误地单独使用外部工具来减轻威胁——例如，在保留底层不安全代码的情况下添加MFA。一种更专业和可持续的方法是采用安全编码模式。通过解决根本原因在源代码中，你将建立一个本质上具有弹性的系统。外部补丁应被视为临时措施，而不是解决基本设计问题的解决方案。
详细内容请参考：Effective Threat Modeling for Software Applications
