如何维护安全的 GitHub 存储库

在这里，我们将讨论 GitHub 存储库管理员可用的一些基本安全工具和技术。

安全发展战略的重要性

应用程序安全性非常重要。 新闻服务经常报道有关公司系统和私人公司和客户数据被盗的一些违规事件。

那么，规划安全发展战略时要考虑的问题是什么？ 显然，我们需要保护信息不被披露给不应有权访问它的人，但更重要的是，我们需要确保信息仅在适当时被更改或销毁。

我们需要确保正确身份验证谁访问数据，并确保他们有正确的权限访问数据。 通过历史数据或存档数据或日志，我们需要能够在出现问题时找到证据。

生成和部署安全应用程序有许多方面。 以下是需要考虑的三个事项：

• 有一个一般的知识问题：许多开发人员和其他员工假设他们理解安全性，但他们不理解。 网络安全是一个不断发展的纪律。 正在进行的教育和培训计划至关重要。

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

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

每个步骤的安全性

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

在实践中，要让团队负责他们开发的内容，流程需要 向左转移，或在开发生命周期的早期完成。 通过在部署时将步骤从最终关口移动到早期步骤，可以减少错误，开发人员可以更快地移动。

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

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

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

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

安全选项卡功能

GitHub 提供安全功能，可帮助确保存储库和跨组织的数据安全。 查找安全选项卡：

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

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

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

• 安全策略允许您通过向存储库添加SECURITY.md文件，指定如何报告项目中的安全漏洞。
• 当 GitHub 检测到存储库正在使用易受攻击的依赖项或恶意软件时，Dependabot 警报会通知你。
• 可用于私下讨论、修复和发布有关存储库中安全漏洞的安全公告。
• 代码扫描 有助于查找、会审和修复代码中的漏洞和错误。
• 机密扫描功能能够检测存储在存储库中的令牌、凭证和机密信息，并能够在推送操作之前对其进行拦截。 默认情况下，公共存储库上启用了推送保护。

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

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

通过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 文件添加文件，有时文件可能会因为不符合 .gitignore 文件配置而被忽略。 项目参与者应始终关注包含不应包含在存储库或其历史记录中的数据的提交。

分支保护规则

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

您可以使用保护分支的工作流来：

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

拉取请求中的所需审阅者数

在代码合并到重要分支之前，可以要求评审来提高存储库安全性。 所需的审阅者有助于强制实施质量、安全性和责任。

若要配置必须的审阅者，请执行以下操作：

1. 导航到 GitHub 上的存储库。
2. 在存储库名称下，单击 “设置>分支”。
3. 在要保护的分支旁边，单击“ 添加规则 ”或编辑现有规则。
4. 选择“在合并前需要拉取请求审阅”。
5. （可选）检查：
   • 需要代码所有者的评审
   • 在推送新提交时撤销过时的拉取请求审阅
   • 需要得到最后一次推送操作人员以外的其他人的批准

在没有管理员权限的情况下，无法绕过所需的评审。 它们确保在合并之前由另一个参与者或指定代码所有者审查建议的更改。

有关更多详细信息，请参阅 “关于受保护的分支”。

添加 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 文件。