Editor’s note: 以下是Adobe赞助的博客文章.
应用程序安全(AppSec)团队面临的最大挑战和机遇之一是有效地扩展. 关于软件开发生命周期(SDLC)中的安全性的“左移”建议强调早期的过程纠正，以帮助嵌入安全控制并减少SDLC中稍后引入的更改的潜在成本(图1)。. 然后向左转移需要通过审查需求中产生的工件来发现潜在的安全关注和安全控制的需要, architecture, design and coding phases.
Figure 1: 在SDLC中更早地合并安全性(左)可以降低成本. SDLC的早期阶段描述了预期的系统(例如.g.(如设计)与现实相反.g., code). 当我们在SDLC中向左移动时，自动化友好性也会降低.g.(描述设计/需求的工件是自由文本文档).
Unfortunately, outside of the coding phase, 在早期阶段添加安全性主要是手工活动. 这限制了产品的安全覆盖范围和探索深度，通常表现为产品组合中的潜在盲点(图2)。. 当我们通过SDLC左边的阶段时, 工件描述了在实现时可能表现不同的“预期的”系统功能. 翻译意图的分歧(e).g.(如需求/设计)变为现实.g.(代码)是引入了多少错误(包括安全性). Finally, 工作流的最新表示形式是作为体系结构在生产环境中执行的代码, 设计文档和它们的威胁模型很难跟上步伐.
For scaling AppSec creatively, 我们提出了“学右改左”的口号. 我们增加了需求的威胁建模, 架构和设计文档用于早期的路线修正，自动化主要集中在代码上, configuration and logs. 自动化有助于两种类型的覆盖. 一是涉及的项目数量(广度)，二是获得的知识类型(深度)。. Also, “向左移动”意味着您将手动焦点转移到周期的早期，并放弃手动测试, which was to the right. 当您将人的注意力转移到左边时，自动化有助于不完全放弃测试阶段.
如图3所示，自动化项目检测一个特定的弱点/属性 all workflows in the pyramid. 除了发现将意图转化为现实的分歧, 这是一种有效的方法，可以启动对话并纠正尚未与安全团队接触的产品的安全状态. 虽然自动化可能不会覆盖所有的安全领域, 一个典型的手动安全审查可以, 同时也适用于更多的工作流和更好的扩展性. 随着时间的推移，自动化项目可以通过一次探索一个安全领域来改进安全覆盖范围. 自动化探索的平衡主题的创造性极大地帮助为业务带来实用价值. 自动化还补充了手工AppSec审查所提供的深度，提供了大规模的特定问题或主题的覆盖.
自动化项目应该探索与业务风险优先级相关的主题. 这种风险通常是通过投机活动来确定的.g.，威胁建模)和数据驱动的练习(例如.g.、过往事件、保安问题). 并不是所有的优先级风险都适合自动化项目. Typically, 在许多工作流中表现为相同/相似变体的风险是实用自动化项目的理想选择. For example, 帮助消除代码库中的秘密归结为查找与正则表达式集合匹配的关键字，这是自动化项目的一个很好的候选, 然而，查找不充分的授权检查所需的设置/用户帐户可能因工作流程而异, 而且大规模的自动化可能会很麻烦.
Both dynamic (live traffic, logs) and static (code, 配置)工件非常适合自动化项目. 风险显示的方式为自动化项目的动态或静态工件的适宜性提供了指针. For example, a missing security header (say, “严格-传输-安全”)可以从实时流量和代码中检测到, 而不安全的嵌入凭证或使用弱加密库只能通过分析代码来找到.
自动化应该与人工审查携手并进. For example, 如果秘密管理薄弱普遍存在, 手动AppSec审查可以强调正确处理机密的必要性-将其存储在经批准的平台中, defining/enforcing access control, securely deploying in production, rotation, etc. 战术自动化项目可以在源代码中找到秘密, 这样就可以大规模地确定AppSec需要改进的具体实例，或者受影响的产品需要采用更强的安全控制并与安全团队合作.
另一个例子是，配置集合可以成为有利可图的目标. 这样的集合可以为许多工作流编码安全属性(例如.g., API网关上服务的配置文件可能会捕获身份验证/授权意图). 这些文件上的自动化允许安全团队考虑由这些集合表示的所有工作流上所需的行为. 需要特别注意限制自动化项目报告的误报，因为这会直接影响安全团队的可信度和完成工作的能力. 一些额外的运行时检查对消除误报大有帮助. For example, 一个简单的POST请求可以验证后端是否实现了自己的身份验证，而不是依赖于API网关. 而这些额外的步骤可能会降低自动化交付的速度, 从长远来看，这样的纪律可以使业务专注于实际风险，并且可以成为产品和安全团队的双赢.
最后，或许也是最重要的一点，安全团队应该把目光放在真正的目标上.e., effective risk reduction. While automation identifies risks, 必须对其进行有效的跟踪，以实际改善安全状况(这是另一天的主题), perhaps). Suffice it to say, 自动化的责任不仅限于识别风险，而且还延伸到最有效的AppSec程序中. For example, 如果人工参与者需要验证和关闭自动化项目创建的票据, 那么AppSec团队面临的可伸缩性挑战就会以另一种形式重新出现. 我们正在通过在自动化生成的Jira票据中添加智能来处理这个问题, 为自动验证和关闭门票铺平道路. In the most generic form, 我们考虑的是自动化项目的整个生命周期——从开始到结束, 识别并解决尽可能多的规模挑战. Over the last many years, Adobe安全团队已经投资于构建核心功能，这些功能大大提高了安全自动化的有效性和深度. For example, 我们开发的安全自动化框架(SAF)允许我们对web属性运行特定的检查 Marinus 允许我们列出所有可公开访问的Adobe web属性. 这样的功能在启用自动化项目方面大有帮助, 同时也创造可能的新机会.g., correlation/prioritization). Last but not least, 与产品团队的有效合作和周期性的创新爆发极大地帮助了AppSec计划.
In summary, AppSec程序需要明智地找到关注软件开发生命周期各个阶段的适当平衡. 而把焦点放在左边则可以提前修正航向, 创造性地利用权利可以提高澳门赌场官方下载对风险的覆盖范围和探索深度. 通过向右翼学习来影响左翼，可以作为额外的好处纠正现有工作流程，并为避免未来可能出现的错误铺平道路.
