介绍

在上一篇文章中，我写了关于使用爬/走/跑方法实现轻量级安全 SDLC程序的文章。在爬行阶段，我介绍了快速风险评估、技术设计/架构审查和威胁建模等活动，这些活动可以作为创始产品安全工程师实施。我在那篇文章中没有涉及的第 4 部分是实现一个轻量级但超级有效的 SAST（静态分析安全测试）工作流程。因此，这篇文章将是 SAST 的所有内容。

在我的 AppSec 职业生涯中，我使用过很多 SAST 工具——IBM AppScan Source、HP Fortify、Brakeman、Bandit 和 Snyk 等等。如果我们从这个列表中剔除 OSS 工具，那么在运行和维护一个成功的 SAST 程序时，一些商业工具的成本一直很难证明是合理的。公平地说，这主要适用于资源和预算始终是已知限制的小型组织。对于拥有专门团队和 SAST 预算的更大、更成熟的组织，我认为这没什么大不了的。

事实上，像 Meta 这样的公司已经编写了自己的SAST工具，并且多年来取得了令人难以置信的成果。这表明仅购买 SAST 工具并在您的环境中实施并不能削减它。必须以非常周到的考虑和对工程组织的同理心来培养和照顾它。

作为一名创始 ProdSec 工程师，出于显而易见的原因，编写自己的 SAST 工具是不可能的。现在，假设您有充分的理由购买昂贵的 SAST 工具并最终购买了它。之后会发生什么？您很可能会花费数小时的宝贵时间来对结果进行分类和微调，结果却意识到在整个工程组织中采用它是另一项艰巨的工作。这很快就会变成它自己的全职工作——你很可能没有报名参加。在我爱上Semgrep之前，我对 SAST 工具的信念已经很久了。

简而言之，如果您还没有将 Semgrep 视为您的 SAST 解决方案，我建议您停止阅读这篇文章并先看看它。此外，作为免责声明 - 这篇文章既不受 R2C 人员的赞助也不受其影响，所以我在这里的意见都是基于我使用它的经验。此外，对于它的价值，我将介绍如何使用 OSS 工具（包括 Semgrep 的社区层扫描引擎和 OWASP 的 Defect Dojo）实现 SAST 扫描。但是，如果您真的想要生产级 SAST 解决方案，我强烈建议您升级到 Semgrep Team Tier 版本。如果您能获得预算批准，那是完全值得的:)。如果不，继续阅读以了解如何仅使用 OSS 工具和您选择的 CI 工具来实施高效的 SAST 解决方案（我将在本文中使用 Github Actions）。那么，让我们开始吧！

核心组件

有4个核心组件：

• Github作为您的代码存储库，托管要扫描的代码以及您的自定义Semgrep 规则
• Github Actions作为您的 CI 工具
• Semgrep CLI作为您的 OSS SAST 扫描器，在不同模式下使用您的自定义规则（评论、监控和阻止）
• OWASP Defect Dojo作为您的 OSS 漏洞管理工具。

请注意，这里的 Defect Dojo 文档非常好，我不会介绍如何设置它。我将假设您已经启动并运行它并且可以在端点上访问它。如果您只是尝试一下，Docker Compose 可能是您开始使用NGROK 之类的东西来获取 HTTPS 端点的最佳选择。然后，您可以在 Github Action 中将该端点用作环境变量。更多信息请参见“设置机密”部分。此外，这正是我为这篇文章所做的。

请注意，下面的架构是一个示例，描述了运行自定义Semgrep 规则的能力——这是您将获得最大 ROI 的地方。如果您想运行 Semgrep 规则注册表中可用的默认规则，您可能可以通过直接从文件中的存储库中拉取它们来returntocorp/semgrep-rules实现semgrep.yml。我不会在这篇文章中讨论这个问题。

上图应该是不言自明的，但如果不是，下面是工作流程的要点：

1. 很棒的开发人员提交代码并发出请求请求 (PR)。或者，代码被直接推送到指定路径的主分支。
2. Github Action 被触发。
3. Semgrep 规则是从托管规则的 Github 存储库下载的。

如果 Github 事件类型是 PR，则 Semgrep 会针对 diff 代码运行。

如果 Github 事件类型是推送到指定路径的主分支，则 Semgrep 将针对整个 repo 运行。

1. 调查结果被发送到缺陷道场。
2. Github Action 基于 cron 计划触发，并下载代码进行扫描。
3. Semgrep 针对整个 repo 运行，并将结果发送到 Defect Dojo。

设置密钥

您需要在需要扫描的存储库中设置一些机密。如果您想在多个 repo 上运行它，您可以将它们设置为组织密码，而不是存储库密码，这样您就不必为每个 repo 设置它。这些机密在本节下面解释的 Semgrep 工作流文件中使用/引用。秘诀是：

• ACCESS_TOKEN = 您的个人访问令牌，用于从您的私人仓库中获取 Semgrep 规则。如果您将规则托管在公共回购中，您可能不需要这个。
• DD_TOKEN = 将调查结果发送到缺陷 Dojo 的 API 令牌。您可以从 Defect Dojo UI 中获取它。
• DD_DOMAIN = 您将托管您的缺陷 Dojo 实例的域。

Semgrep 规则的类别

我基本上复制了Semgrep 应用程序中可用的相同类别

• 监控规则- 这些有助于识别您想要简单监控但不评论 PR 或阻止 PR 的漏洞。这些可能是您试图获得信号并在您想要开始评论/阻止 PR 之前继续微调它们的那些。
• 评论规则- 这些有助于识别您希望在 PR 上发表评论的高保真漏洞。但是，如果您不是 100% 确信这些将始终是 True Positives，或者如果您认为还有其他案例您认为您没有涵盖，那么可能不值得阻止 PR。
• 阻止规则- 这些有助于识别您 100% 确信为真阳性的高保真漏洞，因此如果触发 PR，则应阻止它们。示例：你可以有一个规则来检测硬编码的密钥（你肯定知道不应该在代码中的东西），如果被触发，你可以很有信心地阻止 PR。

Semgrep 工作流文件

我们在上一节中介绍了 3 类 Semgrep 规则。在上面的部分中，我们还介绍了我们希望 Semgrep 运行的 3 个场景Architecture。您可能想知道 - 我们如何确定在什么场景下运行什么类型的规则？阅读以下内容以了解：

• 对于 Github 事件类型不是 PR 的 2 种情况，即当有人在指定路径处推送到主分支时，或者当您希望扫描按特定计划运行时，您可以运行所有 3 类规则并报告由于最终用户/工程师并没有真正看到任何东西，因此直接将发现结果发送给 Defect Dojo，这更像是在后台进行的扫描，即 CI/CD 管道中的工程师没有反馈循环。
• 对于 Github 事件类型为 PR 的场景，您仍然希望运行所有 3 类规则并将结果报告给 Defect Dojo。在此之上：
• 对于监控规则，你不想在 PR 上留下任何评论，也不要阻止 PR。执行此操作的命令是semgrep ci || true. 有关更多上下文，请参阅此内容。
• 对于评论规则，您只需要在 PR 上发表评论，而不是阻止 PR。这个命令也semgrep ci || true和上面一样。但是，还有一些额外的步骤来检索 JSON 中的结果，解析它并使其在 PR 评论上可读，然后最后在 PR 上留下评论。
• 对于阻止规则，您可能希望阻止 PR。执行此操作的命令是semgrep ci. 由于该步骤在 PR 本身上显示为失败，因此无需为此在 PR 上发表评论。人们可以直接进入扫描详细信息，查看失败的步骤及其背后的原因。

所有这些都可以在需要扫描的存储库目录semgrep.yml内的文件中定义。.github/workflows你可以从这个repo 中获取文件。另外，请注意此 repo 包含要扫描的所有文件。

我尝试在下图中从高层次上解释每个步骤的作用：

Semgrep 规则仓库

如果您看到上面的架构，您会注意到 Github Actions 工作流从不同的 repo 下载 Semgrep 规则。monitor您可以将其视为您的中央存储库，您可以在其中以不同的模式（comment和block）管理所有 Semgrep 规则。还有一个scripts包含胶水脚本的目录，例如 - 从 Github Action 发送结果到 Defect Dojo 或解析来自 Semgrep 的 JSON 输出并使其可读以显示为 PR 上的评论。您可以通过在此处导航来了解此 repo 的结构。

演练

场景 #1 - 推送到主分支

视频地址: https://www.youtube.com/embed/b_4uW3cZ2uM

场景 #2 - 按计划运行

在场景 #2 中运行的扫描步骤与上面的场景 #1 完全相同。唯一的区别是，在这种情况下，与推送到主分支（如上面的场景＃1）相比，工作流本身是根据 cron 计划（在此处指定）触发的。此外，当您导航到 repo 中的Actions选项卡时，您应该会看到如下所示的内容（请参阅突出显示的红色部分，表明该操作按计划运行）：

场景 #3 - 发布 PR 时

这可能是您在推动有效的 SAST 工作流中可以实施的最具影响力的方案。这是因为工程师的反馈循环是即时的，使用自定义规则（跨不同语言）具有简单监控、发表评论或阻止 PR 的灵活性。

最后

这就是这篇文章的人！在这篇文章中，我介绍了一些关于 SAST 规则的基本示例，因为重点更多地放在工作流上，而不是规则类型。在下一篇文章中，我计划介绍一些自定义规则，这些规则可以用来识别诸如授权漏洞之类的东西。敬请关注！