Logo

菜单

发布于 2026-01-06 5 阅读
0

API 从开发到生产 - 第 10 部分 - CodeQL DEV 的全球展示挑战赛，由 Mux 呈现：展示你的项目！

API 从开发到生产 - 第 10 部分 - CodeQL

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

系列介绍

欢迎来到本博客系列的第十部分。我们将从最基本的 .NET 5 C# Web API 示例入手，并运用左移思维，逐步讲解从开发到生产的整个过程。我们将使用Azure、Docker、GitHub和GitHub Actions进行持续集成/持续交付 (CI/CD) 部署，并使用Pulumi实现基础设施即代码 (IaC) 。

本文我们将探讨以下内容：

  • SAST（静态应用程序安全测试）通过审查/扫描软件的源代码来识别漏洞来源，从而保护软件安全。

太长不看

静态应用程序安全测试是应用程序从开发到生产的必经之路。市面上有很多工具可供选择，总有一款适合您。借助 GitHub CodeQL，我们可以快速轻松地完成这项测试。

您可以提高在安全漏洞进入生产环境之前发现它们的几率。

GitHub 仓库

GitHub 标志 peteking /示例.天气预报-第10部分

本仓库是 dev.to 网站上“API 从开发到生产 - 第 10 部分”系列博客文章的一部分。基于标准的 .NET 标准天气 API 示例。

要求

我们将从第 9 部分结束的地方继续，这意味着您需要从GitHub 仓库 - 第 9 部分开始获取最终结果。

如果你一直追看这个系列文章，我鼓励你这样做，但如果你已经了解之前的文章内容，那就没必要继续追看。

别忘了确保已在您的代码仓库中设置了代码环境质量 (Code Climate Quality)。

介绍

正如我们在本系列博客文章和“左移”一书中讨论的那样，安全测试实际上是左移流程的一部分！我们需要进行安全测试，当然，我们希望实现自动化，并确保在流程早期就进行测试。市面上有很多工具可以扫描你的代码（静态扫描）；最新的工具是微软收购GitHub后推出的CodeQL。

在这篇文章中，我们将介绍如何使用 CodeQL 将 SAST 添加到我们的 API 中。

CodeQL 的一些历史

GitHub 于 2019 年收购了Semmle，收购金额未公开。Semmle 最初源于牛津大学完成的研究。

该技术基于查询及其语言 CodeQL，分析引擎能够查询大型代码库，以识别代码模式并搜索漏洞及其变体。

GitHub 现在已经将这项功能集成到其平台中，让操作变得无比简单😁

为什么SAST如此重要？

SAST 使发现常见漏洞变得简单，更重要的是，它实现了自动化。SAST 是提升工程师整体良好实践水平的绝佳途径。

通常情况下，工程师的数量远超安全人员，因此，对于任何公司来说，找到合适的代码审查人员，尤其是那些专注于安全方面的代码审查人员，都是一项相当大的挑战。静态应用安全测试 (SAST) 工具能够分析 100% 的代码库，速度远超人工代码审查。这些​​工具可以在几分钟内轻松扫描数百万行代码，并自动识别关键漏洞，例如 SQL 注入、跨站脚本攻击等等，且准确率很高。

SAST 有助于将安全性集成到软件开发生命周期的早期阶段，并促进左移文化的形成；在设计阶段或编码阶段检测专有代码中的漏洞，此时漏洞相对更容易缓解。

步骤 1

导航至您的 GitHub 仓库 → 安全 → 代码扫描警报 →点击“ 设置此工作流程”

博客-10-01

步骤 2

这将生成一个名为“GitHub Actions Workflow”的新文件，codeql-analysis.yml您可以随意更改名称，但我保留了它的名称。

这里最智能的地方在于 GitHub 会检测你仓库中使用的语言，在我们的例子中，它识别出了 C#；这当然是正确的🤓

需要注意的是，对我来说，它根据 GitHub 的识别cron生成了一个无效值。最后一位数字代表星期几，不知为何 GitHub 似乎不支持星期日……在这种情况下，我将其更改为下面的形式，将星期几设置为星期日。0 = Sunday1 = Monday

schedule:
    - cron: '44 23 * * 1'
Enter fullscreen mode Exit fullscreen mode

博客-10-02

有关 crontab 格式的更多信息，请参见此处。

提交更改后，请转到“操作”选项卡查看运行情况。

您可以看到，左侧是一个新的工作流程，它在 4 分 4 秒内执行完毕！

博客-10-03

你会注意到它已经进行了自动构建；根据其语言检测，CodeQL 会尝试构建你的代码，它的镜像包含大量的 .NET SDK，足以涵盖所有内容。

博客-10-04

即使只是为了大致了解这里发生了什么，也值得查看一下构建输出。

📄自动构建
这意味着它会构建我们的 API 两次，没错，两次！这样可以吗？
不太理想，但是……目前我对此没有意见，它会与我们的容器构建并行构建，关键是要扫描代码，所有构建的内容都会被丢弃，我们不需要它们，只需要结果。

鉴于我们使用的是 Docker 容器，这并非最佳方案，但是有一种方法可以将其集成到 Docker 中，但目前文档还不够完善，需要深入研究——我很有可能会尽快对此进行调查，当然，也会为此写一篇博客文章。

有关容器中 CodeQL 的更多信息，请参阅“在容器中运行 CodeQL 代码扫描”。

步骤 3

我们可以配置一些默认情况下未启用的功能，例如额外的查询。

我保留了默认查询，并添加了一些扩展功能。在我们的案例中，我添加了扩展安全性、安全性和质量查询，当然还有 C# 👍

此配置只需写入一个 yaml 文件即可。

  1. codeql在文件夹下创建一个名为“.”的文件夹.github。
  2. 将以下代码复制并粘贴codeql-config.yml到名为“-”的新文件中，暂时无需提交更改，因为步骤 4 中还有另一处更改。

代码
codeql-config.yml

name: "default"

languages: csharp

queries:
  - name: Extended Security
    uses: security-extended
  - name: Security and Quality
    uses: security-and-quality
Enter fullscreen mode Exit fullscreen mode

第四步

我们需要在工作流中引用新的 CodeQL 配置文件。

在工作流步骤中Initialize CodeQL→在其with子句中添加新行，如下所示：

代码
codeql-analysis.yml

config-file: ./.github/codeql/codeql-config.yml
Enter fullscreen mode Exit fullscreen mode

博客-10-06

步骤 5（额外）

如果你和我一样，非常喜欢分支保护规则和 GitHub 状态检查，那么你可能需要创建/修改分支保护规则，使你的两个工作流都必须在合并之前通过。

最后，提交你的更改。

博客-10-07

步骤 6

如果您返回“安全”下的“代码扫描警报”，希望您不会看到任何警报！

通过支持开放的 SARIF 标准，其他工具也可以在这里发布它们的结果。

这意味着即使你以后扩展了工具集，你仍然可以获得相同的 GitHub 原生体验！是不是很棒？

博客-10-08

步骤 7（额外）

既然我们现在在“安全”选项卡中，我赞赏您确保已开启Dependabot警报。

我们学到了什么？

我们已迅速启用 GitHub CodeQL（一款 SAST 分析引擎）来扫描我们的 API。它操作简便，并提供了一个统一的界面，方便您查看代码中的任何安全漏洞。如果您最终使用其他产品，只要这些产品与 GitHub 和开放的 SARIF 标准集成，它们就可以将分析结果推送到您代码库的 GitHub 安全区域。

我们明白它会再次构建我们的 API（但会并行构建），但这并不是什么大问题，因为我们只是想要结果，而不是该工作流程的构建过程。

安全应该始终是工程设计流程的一部分。

动态应用程序安全测试是另一种安全测试形式，关键在于它是动态的而非静态的——我们这里就不详细讲解了，但静态应用程序安全测试 (SAST )和动态应用程序安全测试 (DAST) 结合使用确实很有价值。以后我可能会在另一篇文章中详细介绍 😉

接下来

本系列第 11 部分将讲述：

  • 基础设施即代码
    • 普鲁米

更多信息

文章来源：https://dev.to/peteking/api-s-from-dev-to-production-part-10-9j1
5 个 Web 开发播客，无论你是...
2025 年 JAMstack 技...