共计 5012 个字符，预计需要花费 13 分钟才能阅读完成。
GitHub 是开发人员工作流程中不可或缺的一部分。无论你去哪个企业或开发团队，GitHub 都以某种模式存在。它被超过 8300 万开发人员，400 万个组织和托管超过 2 亿个存储库应用。GitHub 是世界上最大的源代码托管服务平台。
GitHub 的应用便当与弱小反对坚固了其在市场中的主导地位。GitHub 用户群体无所不包，从业余小白到专业人士，从个人用户到大型企业组织，都在应用 GitHub。
应用 GitHub 就无需思考平安吗？
GitHub 提供了许多工具和存储库设置避免数据泄露。但产生平安问题的根本原因往往在于疏于监管和平安常识匮乏。依据 2019 年公布的一项钻研，在对公共 GitHub 存储库进行全面扫描后，该平台上共发现了超过 57 万个敏感数据实例，例如 API 密钥，公有密钥，OAuth ID，AWS 拜访密钥 ID 和各种拜访 token。这些裸露的次要危险包含但不限于经济损失、隐衷泄露、数据完整性受损以及不同水平的滥用。为进步代码仓库的稳健性，和帮忙开发团队施行平安优先，咱们将一起探讨 GitHub 平安实际。
为什么须要增强 GitHub 平安实际？
平安是所有软件开发团队都晓得且须要落实的事件，但往往被放在了最初一步，而粗率的做法和例行程序会升高基础架构和数据完整性的老本。GitHub 的市场位置、社区反对和普及率远超其余竞争对手，GitHub 也牵强附会地成为代码版本控制和利用开发流程的最强参照。但依据北卡罗来纳州立大学的一项钻研，对超过一百万个 GitHub 帐户进行为期六个月的间断扫描显示，蕴含用户名、明码、API 令牌、数据库快照、加密密钥和配置文件的文本字符串，是能够通过 GitHub 公开拜访的。其中包含超过 21 万 个 Google API 密钥、超过 26000 个 AWS 拜访密钥，以及总计超过 28000 个社交媒体拜访 token。
更令人担忧的是，GitHub 上有 542 个 Stripe Standard API 密钥公开可用。这些信息足以让歹意攻击者间接拜访具备实在客户详细信息的帐户，一旦造成攻打，将对企业的经济、声誉、数据完整性造成毁灭性打击。
GitHub 最佳平安实际
1. 切勿在 GitHub 上存储凭据和敏感数据
GitHub 的目标是托管代码存储库。除了在帐户上设置的权限之外，没有其余平安办法能够确保您的密钥、私钥和敏感数据保留在受控且受爱护的环境中。
Git code commit 保留了已增加和删除内容的历史记录，从而使敏感数据永恒保留在分支上。当分支合并和 Fork 时，潜在的数据或基础架构平安危险可能会呈指数级增长。升高此危险的最简略办法是，在提交到分支之前不要在代码中存储凭据和敏感数据。能够在 CI/CD 流水线中应用 git-secreits 等工具。另一个办法是应用秘密和身份管理工具，如 Vault 和 Keycloak。
2. 禁用 Fork
分叉（fork）是一种 git 技术，它容许开发人员在不波及原始代码的状况下创立代码仓库的正本。尽管 fork 非常适合试验和沙箱，但它也可能导致无奈跟踪敏感数据和公有凭据的最终地位。代码仓库最后可能是公有的，但 fork 能够疾速将所有内容裸露到公共空间中。危险随着每次分叉的产生呈指数级减少，通过裸露的敏感数据创立树状的安全漏洞链。为了避免这种状况产生，请禁用 Fork 存储库以帮忙升高敏感数据进入代码的危险。
3. 禁用可见性更改
有时开发人员领有的权限和权限比其角色范畴所需的权限更多。对于没有平安概念的开发人员来说，很容易不小心更改代码库的可见性。如果代码存储库中存在敏感数据，有权拜访此更改可见性功能的人员越多，则潜在的危险就越高。要避免此类情况，能够将更改存储库可见性的性能设置为仅对组织所有者凋谢，或容许管理员特权成员应用权限。
4. 验证 GitHub 应用程序
当初的开发团队有时由内部和第三方团队组成，因而验证 GitHub 应用程序波及跟踪第三方开发人员及其可拜访性级别。这也意味着，一旦他们来到我的项目，或者不再解决代码，就须要撤销他们的拜访权限。不同水平的可拜访性也应与他们在我的项目中的作用和参加水平挂钩。比方，代码审核只须要提取代码的能力，而不须要创立提交。只有在具备相应权限的人进行一系列检查和代码验证之后，才应进行拉取和合并申请。
5. 执行双重认证
双重身份验证（2FA）当初是帐户平安的行业标准。它也该当成为组织的规范平安要求，来避免通过不平安的帐户透露代码。2FA 在登录 GitHub 时减少了一层额定的平安爱护，并且能够通过组织的设置在组织级别强制执行。
当保留设置后，零碎可能会提醒无关未激活 2FA 的集体详细信息。这些信息将从组织中删除，并且只有在其帐户上施行 2FA 后能力从新增加。能够在组织的审核日志中查看已删除的成员。
6. 履行单节点登陆（仅限 GitHub Enterprise）
SAML 单点登录（Single Sign-On, SSO）是一项仅实用于 GitHub Enterprise 的性能。借助此性能，GitHub 上的组织能够通过显示授予对特定资源（如单个代码仓库、拉取申请和引发的问题）的拜访权限来管制可拜访性。这容许组织对代码推送、拉取和审阅过程的不同局部的可拜访性进行分段。SAML SSO 还容许企业设置已批准的身份提供商。这意味着，企业能够限度用户仅应用组织的帐户登录，而不是应用集体 GitHub 帐户。这可能无效缓解在向 GitHub 帐户授予可拜访性时可能产生的潜在平安危险。
7. 限度拜访容许的 IP 地址
对于大型企业而言，跟踪拜访用户既艰难又耗时。避免不必要的拜访的办法是限度通过 IP 地址的拜访。这意味着只有外部部署的成员或有权拜访公司保护的动态 IP 近程网络的成员能力进入企业的代码存储库和相干代码工作。要限度、治理和将 IP 地址列入白名单，在这里能够以 CIDR 表示法配置特定 IP 地址或范畴的列表。
8. 严格管理内部参与者权限
企业可能通过外包来放慢我的项目的停顿，或者引入内部专业知识来帮忙填补团队空白。内部成员的参加越多，相应的平安危险就越高。通过严格管理内部协作者和参与者，企业能够缩小冗余用户数量及其对代码存储库的可拜访性。治理内部协作者的一种办法是将拜访权限和权限授予权限集中给管理员。这样做还能够升高因为 GitHub 的长期拜访老本。
9. 及时撤销权限
一个好的安全策略，须要思考到团队成员来到企业或我的项目时，对应的权限进行怎么的批改和调整。这包含撤销不同类型帐户的可拜访性的工夫。有时团队成员可能仍须要拜访代码，但不须要参加，因而撤销更改权限或将其切换为维护者角色可能更适宜。此办法遵循最小特权准则，即授予执行特定工作所需的权限。这样做将确保每个有权拜访代码的人都只在其权限范畴内工作。
10. 要求提交签名
提交签名是对代码合并进行加密签名以进行验证和可跟踪性的过程。这对于代码审核跟踪十分重要，因为歹意攻击者伪装成其他人并不难，只需在 git 配置中更改其用户名和电子邮件地址并推送盘剥性代码合并。能够将 Git 设置为通过 GPG（GNU Privacy Guard）对提交进行签名，并在 git 配置中应用公有密钥配置提交。实现此操作后，您能够将 GPG key 增加到 GitHub。在提交时，提交旁边会显示一个“已验证”标记。
11. 执行提交前代码审查
强制执行代码审查能够避免恶意代码正式合并到分支中。代码审查也是检测代码异样的良好做法，可能帮忙企业防止导致将来的破绽和长期的平安危险问题。GitHub 有一个拉取申请工具，容许受权的团队成员在合并到根本分支之前探讨和查看潜在的更改。收回拉取申请时，能够将工作负责人附加到拉取申请，来告诉他们查看待处理的审核。
12. 增加 security.md 文件
security.md 文件是存储库的安全策略。此文件的目标是正式记录与平安相干的流程和程序，包含破绽报告、机密性要求、加密规范、令牌可拜访性、电子邮件地址的应用、HTTPS 要求、云的应用、CDN、备份、身份验证要求的过程以及数据完整性保护过程。security.md 文件能够作为开发人员的贵重指南。
13. 轮换 SSH 密钥和集体拜访令牌
SSH (Secure Shell) 密钥轮换可用作定期革除可能泄露的拜访密钥。最好在平安要求策略中对所有 SSH 密钥和集体拜访令牌设置到期日期。须要留神，尽管能够通过 GitHub 的 API 主动进行 SSH 密钥轮换，但更改集体拜访令牌是手动过程，只能由用户实现。要在 GitHub 上手动删除 SSH 密钥，在“SSH and GPG keys”下，能够找到以后所有拜访密钥的列表。
14. 审核上传到 GitHub 的所有代码
在应用程序构建过程中增加内部代码存储库很容易。除此之外，企业也会导入以往开发的软件中的旧代码。导入旧代码的问题是其安全性无奈保障。审核上传到 GitHub 的所有代码的要求可能十分耗时，但有利于应用程序和软件体系结构完整性的长期运行状况。
15. 查看 Github 审核日志中是否存在可疑流动
GitHub 有审核日志工具，可让企业的管理员疾速查看团队其余成员执行的操作。谁做了什么的详细信息能够帮忙标记可疑流动，并依据用户的操作、操作的基于国家 / 地区的地位以及产生的日期和工夫创立疾速跟踪配置文件。这三条信息能够帮忙管理员检测异样并疾速查明其起源。
16. 为易受攻击的依赖关系启用警报
随着软件我的项目规模的增长，依赖关系也变得更加盘根错节。而易受攻击的依赖项（尤其是组织内部的第三方依赖项）的危险最大，因为它们的状态以及对包或模块的更新形式不足管制。对于小型我的项目跟踪难度可控，但随着我的项目变得越来越大，这些依赖项很容易失落。GitHub 具备检测公共代码仓库中易受攻击的依赖项的性能，能够通过组织设置中的“Security & analysis”选项来启用警报。
17. 在预提交时采纳主动密钥扫描
在许多人的印象里，如果源代码是公有的，那么硬编码凭据也应该放弃平安。然而公有仓库不提供雷同级别的爱护和加密的保存库，也不提供对可拜访性轮换的雷同水平的管制。复制和散发源代码也不难。在 CI/CD 流水线中，速度是传输代码的要害。这可能会导致意外提交敏感数据。主动秘密扫描能够升高此类凭据意外裸露的危险。
18. 革除 GitHub 历史记录
GitHub 保留了每个已提交更改的日志。然而，如果敏感数据进入代码存储库可能会带来麻烦。清理 GitHub 历史记录的过程分为两个步骤。首先使代码中的任何令牌和密钥生效。第二步是应用 git filter-branch 命令革除和重写存储库的历史记录。进一步向上游更改提交很重要，因为它会影响所有曾经实现的后续提交。最好在运行 GitHub 历史记录之前合并并敞开所有拉取申请。
19. 启用 git 分支爱护
分支误删或 git squash 合并可能会导致数据失落，或者通过引入破绽在代码中造成数据泄露。分支爱护是一项 GitHub 性能，容许爱护特定的 git 分支免受未经受权的批改。这项性能的目标是为了确保协作者不会通过删除和强制推送等过程对分支进行永恒更改。其余分支爱护办法包含要求签名提交以确保真实性、可追溯性和拉取申请以避免未经受权的代码合并。
20. 将敏感文件增加到 .gitignore
随着我的项目规模和复杂性的增长，本地机失常工作所需的敏感数据也在减少。这些文件往往是惟一的，并且位于部署的服务器上，不对公众进行公开。在开发模式和本地主机中，软件开发须要拜访这些令牌和密钥。.gitignore 将确保您的敏感数据不会意外合并并推送到 GitHub 存储库。
21. 应用“Secrets Vault”服务
随着我的项目的增长，加密密钥、令牌、明码、证书和 API 密钥等的数量也会减少。与其将这些信息放在 GitHub 上，不如应用“明码保险库”服务。Vault 是一种用于爱护高度敏感数据的工具，同时提供对立的拜访接口。除此之外，Vault 还提供更严格的访问控制和审核跟踪，使管理员可能轻松检测破绽和违规行为。
参考链接：
Where the world builds software
https://github.com/about
How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories
https://www.ndss-symposium.or…
