介绍

安全 SDLC 是任何产品安全计划的组成部分。它使组织能够在其 ProdSec 成熟度之旅中取得成功。在这篇文章中，我将尝试将其分解为它所包含的不同活动，以及如何作为一名创始 ProdSec 工程师合理地实施它们。如果您直接阅读了这篇文章，我建议您阅读我之前的 2 篇文章——从头开始构建产品安全计划和产品安全路线图。让我们开始吧！

作为工程师，我们应该熟悉软件开发生命周期（SDLC）。

在高层次上，Secure SDLC 基本上是 SDLC 的扩展。您可以将其视为最佳实践的集合，允许组织在开发阶段早期主动减少发现的安全漏洞的数量和严重性，同时降低****开发成本（修复这些漏洞），而不是在软件部署在生产中。

换句话说，它使组织能够有效地发现、管理和降低对其自身及其客户的整体业务风险。

实施安全 SDLC 计划并将其推广到整个组织可能需要数月甚至数年的时间。作为创始 ProdSec 工程师，您很可能无法享受到这一点，因此可能需要一种轻量级的方法。我倾向于考虑它的方式是分阶段实施它-crawl和. 我将在下面对每个阶段进行高级概述，然后在每个阶段随后详细介绍活动的细节。重点将主要放在爬行阶段。和阶段现在还没有很好的定义。walk``run``walk``run

将其想象成您作为组织中的创始 ProdSec 工程师可以/应该做的典型活动，以使您的 ProdSec 计划成熟。在下表中，您将找到与 SDLC 阶段配对的安全 SDLC 活动的粗略分类、输入、输出以及对执行此操作的 ROI 的简要说明。之后，我将更详细地简要介绍这些活动。

接下来，让我们深入了解这些活动的一些细节。

快速风险评估 (RRA)

在我们开始考虑设计系统/软件之前，我们应谨慎考虑其风险状况，以便我们可以相应地确定优先级（基于我们的风险承受水平），因为并非 SSDLC 中定义的所有活动都适用于所有软件/在组织中构建的系统。

此外，作为创始 ProdSec 工程师，您需要对正在构建的产品/应用程序有某种可见性。记住这句话“你无法保护你不知道的东西”。除了这种可见性之外，您还需要某种框架来决定是否需要您注意某些事情，因为不可能以相同的严格程度保护所有产品，并且必须有某种基于风险的优先级。我相信，快速风险评估又名 RRA 可以帮助实现其中的一些。

理想情况下，快速风险评估或 RRA（受Mozilla 的 RRA、Better Appsec Post和ISACA 的模型启发）应该是 SSDLC 计划中实施的第一项活动。它的核心是收集一些关于将要存储、处理或访问的数据类型的基本信息（信封类型估计的背面）。除此之外，还可能捕获其他重要因素，例如 - 系统是否暴露在互联网上？什么是数据分类？等等等等。一旦您对这些有了大致的了解，您就可以建立某种标准/框架，以帮助评估特定功能/产品/应用程序可能给组织带来的风险。

这很重要，因为它可以让你无情地优先考虑你应该做的工作和你认为应该做的工作。执行 RRA 的结果应输入组织风险登记册，安全团队应根据整体风险评级提出建议的安全活动列表。现在，话虽如此，我相信这也是在整个组织范围内始终如一地推出的最困难的活动，因为文化在决定你将如何成功方面发挥着巨大的作用。

根据我的经验，你真的必须了解工程文化并相应地推动 RRA 的采用。例如，您将不得不不断要求人们填写 RRA，直到它真正渗透到工程文化中。你将不得不继续在 All Hands 上谈论它，直到它成为第二天性。您将不得不恶毒地监视有关正在引入的新服务的喋喋不休，并寻找合适的人来填补 RRA，如果他们还没有这样做的话。这并不容易，但如果始终如一地反复进行，您将很快开始看到结果。

填写 RRA 的标准

我不想这么说，但你必须相信你的 EM/Sr。工程师可以做出明智的判断，是否需要 RRA。这里没有正确或错误的答案。您可以为他们提供指导，但您最终必须依靠他们来做出决定。在提交任何代码之前，您可以尝试在您的 SDLC 中将此作为强制性步骤，但根据我的经验，通常会因此而观察到很多摩擦和混乱。

这是因为不同的团队使用不同的工具以不同的方式运作，除非您有一致的方式来全面集成 RRA，否则我认为花时间和精力尝试通过流程强制 RRA 是不值得的。我宁愿尽可能多地重复自己，直到有一点我不必再重复自己。

您可以将 RRA 作为人们可以填写的问卷表提供。并且，结果会直接发送给安全团队。任何项目管理工具，如 Asana 或 Jira 都可以提供帮助。您可以提供的指导可能如下所示：

何时填写 RRA

• 是否在任何端点/解析器/查询/突变中发生了变化？是 CRUD 操作吗？
• 更改是否引入了与内部或外部服务的任何全新通信？
• 更改是否会处理任何客户数据？
• 是否对可能直接或间接依赖于身份验证、授权等内容的核心组件之一进行了更改？
• 基础设施的部署方式是否发生了变化？

何时跳过 RRA

• 这是前端的外观变化吗？例如，更改页脚在网站上的外观。
• 它是一种不会影响任何业务逻辑或数据的静态更改吗？例如，在组织提供的服务中添加新选项。
• 更改主要适用于前端，后端代码没有重大更改吗？

RRA 问卷包括哪些内容？

以下是您可以通过 RRA 问卷获取的一些数据点。显然，每个组织都会有所不同，因此请随意以此为起点并根据需要进行修改。

• 一般信息
• 填写 RRA 的人的姓名
• 团队
• 产品名称
• 产品描述
• 网络曝光
• 仅限内部
• 可上网
• 间接服务（想想 Kafka 队列。它们无法在 Internet 上访问。它们也不仅仅用于内部使用。但是，服务使用 Kafka 流式传输事件并作为发布/订阅，因此它们将被视为间接服务。）
• 根据贵组织的数据分类政策，此服务/产品的最高数据分类级别是什么？一些可能的值可能是：
• 敏感的
• 受限制的
• 内部的
• 上市
• 身份验证要求
• VPN 或 MFA（多因素身份验证）
• 单因素
• 没有任何
• 可用性要求
• 正常运行时间少于 80%
• 80% - 95% 正常运行时间
• 超过 95% 的正常运行时间
• 机密性 - 未经授权披露信息/数据可能会导致：
• 1 - 对组织运营、个人资产的不利影响有限。
• 2 - 对组织运营、资产或个人的严重不利影响。
• 3 - 对组织运营、资产或个人造成严重或灾难性的不利影响。
• 完整性——对信息/数据的未经授权的修改或破坏可能具有：
• 1 - 对组织运营、个人资产的不利影响有限。
• 2 - 对组织运营、资产或个人的严重不利影响。
• 3 - 对组织运营、资产或个人造成严重或灾难性的不利影响。
• 可用性 - 对信息/数据或信息系统的访问或使用的中断可能会导致：
• 1 - 对组织运营、个人资产的不利影响有限。
• 2 - 对组织运营、资产或个人的严重不利影响。
• 3 - 对组织运营、资产或个人造成严重或灾难性的不利影响。

如何从 RRA 答案中计算风险评级？

下面只是我的看法。我知道它可能不适用于您的组织。我也知道它不是基于任何科学框架，因此可能不准确。但是，它对我来说工作得相当好，它可以告诉我某件事是否足够重要，以至于我不能关注——RRA 的目标。我希望至少，它会激发您构建更具体的东西。

ACR1首先，让我们根据收到的数据分类和技术要求答案来计算资产重要性等级（我们将其称为）：

ACR2接下来，让我们根据收到的机密性、完整性和可用性答案的损失来计算资产重要性等级（我们将其称为）：

一旦我们有了ACR1和ACR2，我们就可以根据下表得出一个总体风险评级（类似于您根据可能性和影响计算风险的方式）：

最后，一旦您获得了总体风险评级，您就可以确定可以执行哪些额外的 SSDLC 活动：

• 如果风险评级为Negligible或Low，则无需采取进一步行动。
• 如果风险等级为Moderate，则必须进行技术设计审查。
• 如果风险等级为High，则必须进行技术设计审查和威胁建模。
• 如果风险评级为Critical，则必须进行技术设计审查、威胁建模和渗透测试/手动评估。

您实际上可以自动化此过程，例如 EM/Sr。工程师可以通过链接访问 RRA 表格。他们填写答案并提交。您自动应用上述框架并计算整体风险评级。您将其添加到风险登记册，并在相应的积压工作中为所需的安全活动创建票证。通过这种方式，您简化了工作量，并以某种轻量级的方式自动化了基于风险的优先级排序过程。您现在可以专注于只处理最重要的工作而不会不知所措。

技术设计/架构审查

我相信任何科技公司都应该强制编写 RFC / 技术设计 / 设计文档。如果不是这样，我会尝试与适当的利益相关者合作，首先制定这样的流程。

如果这样的流程已经存在，那么重点应该放在工程师在编写这些 RFC 时需要填写的一些安全问题上。这些问题将涵盖应用安全控制、网络安全控制、数据安全问题、云安全控制和事件响应措施等领域。拥有 DFD（数据流图）也应该是此类文档的要求。DFD 在了解不同服务和组件如何相互集成方面对安全架构审查有很大帮助。它有助于理解不同的威胁边界，最终将在此之后的威胁建模步骤中使用。

此过程的主要目的是在我们的工程师已经在考虑其服务/产品的技术设计时收集特定于安全的信息。通过提问的方式收集这些信息不仅会激励我们的工程师主动思考安全隐患，而且还会极大地告知安全团队围绕实施设计和整体架构所做的一些决策。

这进一步使安全团队能够突出任何潜在的关注领域和/或在适当的情况下提供安全最佳实践建议。总体而言，这对每个人来说都是双赢的局面，因为它有效地避免了在设计级别而不是在部署后引入设计缺陷，从而节省了解决问题的时间和精力，并使开发人员保持高效率.

一些示例问题（并非详尽无遗）：

验证

• 是否所有新资源都受到身份验证策略的保护？
• 您的服务是否设置了任何 cookie 或自定义标头？
• 您的新服务使用标准身份验证模式还是自定义模式？
• 如果您的服务依赖于第三方，该第三方如何针对组织的服务进行身份验证？

授权

• 您的服务中的每个经过身份验证的资源是否都仅限于一组细粒度的用户角色 (RBAC)？
• 每个请求是否都完全重新验证授权细节？
• 如果服务使用 JWT，JWT 是否正确解码和验证（签名）以具有已知算法、已知发行者、受众等？JWT 是否会根据需要进一步检查适当的权限？

输入验证/清理

• 该服务是否接受最终用户的任何输入？如果是这样，您是否使用任何框架/库来防止一些常见的注入攻击 - 跨站点脚本、SQL 注入等。

加密

• 该服务是否处理任何敏感的用户/客户信息？
• 该服务是否存储任何用户/客户数据？如果有，是否已加密？
• 该服务是否在数据库中存储任何用户/客户数据？如果是，是否从密钥管理器解决方案（例如 Vault）获取到数据库的连接字符串？
• 该服务是否实施任何加密/解密/加盐/散列？如果是，它是否使用推荐的算法？

日志记录

• 该服务是否按照组织的审计日志记录标准实施日志记录？

监控/警报

• 该服务是否有适当的监控和警报？

威胁建模

如果您是 ProdSec 的创始工程师，我个人一直在努力寻找一种方法来与您的工程同行持续进行威胁建模。如果您对此有有效的想法，我很想听听！

这是迄今为止我在 SSDLC 计划中最喜欢的活动/主题。威胁建模是一项活动，可以根据您的需要简单或复杂。各种受人尊敬的行业资深人士已经详细讨论过这个问题，所以我不会过多介绍它是什么，但我要做的是通过一种非常有效的方法。

有些人对威胁建模工具发誓，而有些人只是通过与他们的工程同行开始对话并跟随对话来了解它引导他们的方向。对我来说，我喜欢有一点结构来说明我对事物的看法（如果你还没有弄清楚的话），所以我使用STRIDE框架作为我的指导原则，但我仍然非常喜欢通过询问来保持对话吨的问题。这种方法非常轻量级，在我看来似乎效果很好。

这里的想法是对逻辑系统组件之间的不同边界进行一般的高级理解，列举一些潜在的攻击向量，识别现有和缺失的安全控制并确定它们的优先级。技术设计文档（上一步）中的 DFD 图可以作为这里的起点。

可能值得一提的是，为了扩大产品安全团队的规模，工程团队最好在安全团队的支持和指导下进行自己的威胁模型。但是，在组织达到安全成熟度级别之前，安全团队应该投入时间和资源来领导威胁建模会议并教育工程组织如何进行威胁建模。这可能是我建议一开始就花时间进行的唯一一种安全培训/教育。换句话说，在安全培训方面，教您的工程师如何进行威胁建模和像攻击者一样思考会大有帮助。

我将尝试简要介绍以下示例：

下图来自这个youtube 视频。Jonathan Marcil 是威胁建模大师，应该给予应有的评价。我将使用他在本次演讲中的示例，并希望将其简化。我强烈建议观看他的演讲。

步骤1：

以显示不同组件之间连接的方式绘制架构图 (DFD)。理想情况下，如果你从左到右或从上到下，它会在视觉上更令人愉悦，而不会分心。保持此图专注于威胁建模范围内的核心组件。即使它们可能有其他依赖项，也没有必要显示所有这些依赖项。例子：

第2步：

添加有关组件、技术堆栈之间的协议的信息以及有助于威胁建模过程的任何其他必要信息。例子：

第 3 步：

现在，使用STRIDE框架，开始集思广益，当您发现现有和缺失的安全控制措施时，不良行为者可能会如何尝试窃取资产并在图表中标记它们。例如，在上图中：

• S (Spoofing) = 来自浏览器的请求是如何被 Electrum Wallet 认证的？如果没有，请将其标记并通过图例突出显示为缺少的安全控件，如下所示。如果有身份验证，则不必标记它（以使图表不那么混乱）。话虽如此，您也可以选择将其突出显示为现有的安全控制，以保持积极的基调。冲洗并在所有被威胁建模的核心组件上重复。
• T（篡改）=电子钱包和 ElectrumX 之间如何维护请求的完整性？是否有某种基于哈希/签名的完整性检查来确保请求未被篡改？
• R (Repudiation) = 组件之间的请求是否被记录？它们是否被运送到中央日志服务器？是否有任何组件未启用日志记录？
• I（信息披露）= 电子钱包是静态加密的吗？
• D（拒绝服务）= Exchange API 上是否有任何速率限制控制以防止有人发送垃圾邮件？
• E（特权提升）= 移动应用程序以什么特权与 Exchange API 通信？或者，换句话说，交换 API 如何检查来自移动应用程序的请求的授权权限？

第4步：

一旦您浏览了整个架构并确定了一些缺失的安全控制，通过确定风险（可能性 x 影响）并将其与业务风险容忍度水平进行比较来确定它们的优先级，牢记收入影响和所需的努力水平减轻/修复缺失的安全控制。

静态分析安全测试 (SAST)

根据 Microsoft 的 SDL，SAST 是“在编译之前分析源代码以验证安全编码策略的使用”。SAST 可用于执行静态代码审查以及检测与默认编码标准的安全偏差。集成 SAST 扫描的理想位置是在提交代码时跨组织代码库的每个 PR。我是Semgrep作为 SAST 工具的忠实粉丝。SAST 扫描的反馈循环应该相对较快，因为您希望在开发人员尝试将代码提交到存储库时立即提醒他们潜在的错误。

这里的诀窍是 - 您如何平衡扫描，同时确保工程工作量最少，同时提供价值。您可以考虑分阶段推出此功能，即临时运行规则，查看结果，将其微调到您可以绝对确信它不会产生任何假阳性或假阴性的程度，然后才引入它在阻塞模式下的每个 PR/CICD 管道上。Semgrep 允许我们这样做，因为它能够编写自定义规则。稍后再详细介绍！

除了扫描应用程序代码库外，您还可以通过 SAST 工具实施基础架构即代码 (IaC) / 策略即代码扫描。这将使在存储库级别检测公共 S3 存储桶变得稍微容易一些，而不是在它们已经公开后检测。

我不会在这篇文章中深入探讨 SAST，因为我的下一篇文章将是关于 SAST 的，敬请期待！

这就是爬行阶段。作为创始 ProdSec 工程师，如果您一开始将大部分时间集中在这 4 个领域（快速风险评估、技术设计/架构审查、威胁建模、静态分析安全测试），您很可能会与工程部门建立融洽的关系org 并且会对开始您的 ProdSec 之旅产生重大影响。下面提到的步行和跑步阶段自然会在您实施这些活动并进行几个月/季度之后进行。随着本系列的进展，我将简要介绍步行和跑步阶段，并提供更多详细信息。

默认情况下，爬行阶段的所有活动都包含在步行阶段。下面列出的活动是除此之外的。

第三方依赖扫描

这需要扫描代码库以查找第三方依赖项中的任何漏洞，包括但不限于开源库。集成此扫描的理想位置是代码库中的每个 PR。你可以使用 Dependabot 之类的东西来帮助你。查看 Netskope 安全团队的这篇文章，了解如何去做。

动态分析安全测试 (DAST)

根据微软的 SDL，DAST 是“完全编译软件的运行时验证，以测试完全集成和运行代码的安全性”。一旦软件/代码成功通过 PR 批准阶段并部署在准备测试的暂存环境中，您可能希望对运行时应用程序运行某种 DAST 扫描，以检测任何潜在的漏洞。

DAST 扫描可以集成到 CICD 管道中，以便它们完全自动化，目的是捕捉低垂的果实（缺少缺少的标头或标志）和易于扫描的通用配置错误。对于无法轻松自动扫描的问题，我们可以手动运行快速 DAST 评估，以捕捉在早期阶段特定应用程序的威胁模型中识别的潜在高优先级错误。

DAST 扫描的反馈循环是这样的：一旦发布 PR → CICD 启动 → staging env 启动 → DAST 运行 → 然后将结果发回。

渗透测试

根据可用资源和/或预算，您可以聘请外部咨询公司对您的应用程序进行渗透测试，也可以在内部进行。这里的目标应该是从业务风险的角度关注最重要的事情，即执行一个有时间限制的黑盒安全评估，重点关注威胁建模期间确定的关键领域。

默认情况下，爬行和步行阶段的所有活动都包含在运行阶段。下面列出的活动是除此之外的。

密钥扫描的预提交检查

这涉及扫描诸如意外向 Github 提交密钥之类的事情。即使在提交之前，您也希望捕获它们。集成此扫描的理想位置是在本地开发人员工作站上，这样一开始就不会将机密信息提交给 Github。除此之外，您还可以将其集成为提交后检查，但在 PR 获得批准之前。这种多层方法将确保您在多个地方进行检查以最终发现此类错误，即使它们未能在一个特定的地方被捕获，遵循纵深防御策略。

漏洞赏金计划

从业务投资回报率的角度来看，启动漏洞赏金计划是获得安全研究人员/漏洞猎手报告的大部分低悬成果的好方法，而不会导致银行余额大幅下降。不仅如此，您还可以创建定制的范围和重点领域，并增加奖励和奖金，以吸引高质量的研究人员加入您的计划，并让他们发现和报告具有现实世界漏洞利用的更具影响力的错误。

就是这样的人！我知道这很多，但希望这一切都有帮助。与往常一样，如果您有任何问题或想分享您的战争故事，请与我联系。