如何维护安全的 GitHub 存储库

  • 8 分钟

本文介绍 GitHub 存储库管理员可使用的一些基本安全工具和技术。

注意

以下内容不涵盖关于编写安全代码的基础知识，而是介绍 GitHub 存储库中的重要安全注意事项，以及在该存储库中使用的工具和功能。

安全开发策略的重要性

应用程序安全非常重要。 通讯社经常报道有关一些公司系统遭到破坏，以及私人公司和客户数据被盗的新闻。

在规划安全的开发策略时，需要考虑哪些问题呢？ 显然，我们需要防止信息披露给不应有权访问它的人，但更重要的是，我们需要确保信息仅在适当时候被更改或销毁。

我们需要确保对数据访问者进行恰当地身份验证，并且他们具有执行此操作的正确权限。 我们需要能够在出现问题时，通过历史或存档数据或日志查找证据。

生成和部署安全应用程序包含很多方面。 下面是三个需要注意的事项：

  • 存在一个常识问题：许多开发人员和其他员工成员认为他们了解安全性，但他们并不了解。 网络安全是一门不断发展的学科。 持续的教育和培训计划至关重要。

  • 必须正确且安全地创建代码：我们需要确保正确地创建代码，并安全地实现所需的功能。 我们还需要确保在设计功能时考虑安全性。

  • 应用程序必须符合规章制度：我们需要确保代码符合规定的规则和法规。 我们必须在生成代码时进行合规性测试，然后定期重新测试，即使在部署之后也是如此。

安全每一步

图像显示了一个 GitHub 盾牌，盾牌下写着 Security（安全）。

安全性不是可以在以后添加到应用程序或系统中的东西。 安全开发必须在软件开发生命周期的每个阶段进行。 对于关键应用程序和处理敏感信息或高度机密信息的应用程序，这个概念更为重要。

在实践中，若要使团队能够为自己开发的内容负责，流程需要在开发生命周期中左移或提前完成。 通过将部署时的终门中的步骤移到更早的步骤，可以减少错误，这样开发人员可以进展地更快。

过去，应用程序安全概念并不是开发人员关注的焦点。 除了教育和培训问题之外，组织强调快速开发功能，这也是原因之一。

不过，随着 DevOps 实践的引入，安全测试更容易集成到管道中。 安全测试应该只是日常交付过程的一部分，而不是由安全专家执行的任务。

总的来说，考虑到返工时间，在开发生命周期提早将安全性添加到 DevOps 实践中可以让开发团队提前发现问题。 提前发现问题实际上可以减少开发优质软件所需的总体时间。

左移只是流程的更改，它不是单个控制措施或特定工具。 它就是让所有安全性更加以开发人员为中心，并在开发人员所在的地方为他们提供安全反馈。

“安全性”选项卡功能

GitHub 提供的安全功能有助于确保存储库和组织中的数据的安全。 若要查找“安全性”选项卡，请执行以下操作：

  1. 在 GitHub.com 上，转到存储库的主页。

  2. 在存储库名称下，选择“安全性”。

屏幕截图显示 GitHub 中“安全性”选项卡的位置。

在“安全性”选项卡中，你可以向你的 GitHub 工作流中添加功能，以帮助避免存储库和代码库中出现漏洞。 这些功能包括：

  • 安全策略，允许你通过向存储库添加 SECURITY.md 文件来指定如何报告项目中的安全漏洞。
  • Dependabot 警报，当 GitHub 检测到你的存储库正在使用易受攻击的依赖项或正在使用恶意软件时通知你。
  • 安全公告，可用于以私密方式讨论、修复和发布有关存储库中安全漏洞的信息。
  • 代码扫描，帮助你查找、会审和修复代码中的漏洞和错误。

有关详细信息，请参阅 GitHub 安全功能。

注意

针对恶意软件的 Dependabot 警报公告目前为 beta 版，可能会更改。 只有 GitHub 已评审的公告才会触发 Dependabot 警报。

接下来，我们来探讨其中一些功能，并了解如何在软件开发生命周期的所有阶段分配安全性和运营责任。

通过 SECURITY.md 传达安全策略

GitHub 的社区利益非常可观，但也有潜在的风险。 事实上，任何人都可以公开提出 bug 修补程序，而这伴随着某些责任。 最重要的是负责任地披露信息，这些信息可能会在潜在的漏洞被修复之前导致安全漏洞。 希望报告或解决安全问题的开发人员会在存储库的根目录中查找 SECURITY.md 文件，以便负责任地披露其问题。 在此文件中提供指导最终可加快解决这些关键问题的速度。

要了解有关 SECURITY.md 的详细信息，请参阅将安全策略添加到存储库。

GitHub 安全通知

通过 GitHub 安全通知，存储库维护人员可私下讨论和修复项目中的安全漏洞。 存储库维护者协作处理修补程序后，可发布安全通知，向项目社区公开披露安全漏洞。 通过发布安全通知，存储库维护者可使其社区更轻松地更新包依赖项并对安全漏洞的后果进行调查。 GitHub 将已发布的公告存储在“常见漏洞和暴露 (CVE)”列表中。 此列表用于自动通知受影响的存储库，这些存储库使用了存在所列漏洞的软件。 有关详细信息，请参阅关于存储库安全公告。

通过 .gitignore 将敏感文件排除在存储库之外

开发人员很容易忽略提交中包含的文件。 有时这些被忽略的文件是良性的，例如中间生成文件。 但是，始终存在有人无意中提交敏感数据的风险。 例如，有人可能会提交 API 密钥或专用配置数据，而恶意参与者可能会使用这些数据。 有助于避免此类风险的一种方法是生成和维护 .gitignore 文件。 这些文件命令客户端工具（如 git 命令行实用工具）在聚合用于提交的文件时忽略路径和模式。

下面的示例说明了忽略文件的一些常见用例：

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

存储库可能包含多个 .gitignore 文件。 设置继承自父目录，新 .gitignore 文件中的重写字段优先于其文件夹和子文件夹的父设置。 尽管在项目具有更易于与父级分开维护的特定要求（比如不应忽略的文件）时，将 .gitignore 文件添加到项目目录中会很有帮助，但大部分的精力通常都投入到了维护根 .gitignore 文件。

要了解有关 .gitignore 的详细信息，请参阅忽略文件。 还可以在 存储库中查看为各种平台提供的入门 .gitignore 文件集合。

从存储库中删除敏感数据

虽然 .gitignore 文件在帮助参与者避免提交敏感数据方面很有用，但这只是一个很好的建议。 如果开发人员有足够的积极性，他们仍然可以绕过它添加文件，有时文件可能会因为不符合 .gitignore 文件配置而被忽略。 项目参与者应始终注意包含不应包含在存储库或其历史记录中的数据的提交。

重要

应假设任何时候提交给 GitHub 的任何数据都已泄露。 仅覆盖提交还不足以确保数据在将来不可访问。 有关如何从 GitHub 删除敏感数据的完整指南，请参阅从存储库中删除敏感数据。

分支保护规则

可以创建分支保护规则，为一个或多个分支强制实施某些工作流。 例如，可以要求所有合并到受保护分支的拉取请求都要经过批准审查或通过状态检查。

可利用保护分支的工作流来执行以下操作：

  • 运行生成来验证是否可生成代码更改
  • 运行 Linter，检查是否有拼写错误且是否与内部编码约定一致
  • 运行自动测试，检查代码是否有任何行为更改
  • 等等

添加 CODEOWNERS 文件

通过将 CODEOWNERS 文件添加到存储库中，可将单个团队成员或整个团队作为代码所有者分配到存储库中的路径。 接下来，这些代码所有者需要对向其配置的路径中的文件的任何更改进行拉取请求评审。

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

可在存储库根目录中，或者在 docs 或 .github 文件夹中创建 CODEOWNERS 文件。