针对GitHub的八项安全实践

译文
安全
本文和您讨论GitHub用户需要遵循的八种安全实践,以方便您为自己的代码保驾护航。

【51CTO.com快译】GitHub可谓世界上最大、最受欢迎的社交开发平台。根据其《2019年Octoverse的态势报告》(请参见-- https://octoverse.github.com/):GitHub当时拥有超过4000万名用户,而且该社区每天都在不断地壮大。

由于各类开发人员频繁地使用由该平台所提供的开源代码去构建软件,那么大量可以被重复使用的代码往往会增加漏洞从一个依赖项或存储库,迁移到另一个依赖项或存储库的潜在风险。可见,基于此类高度互连性,Github平台及内容的安全性显得尤为重要。每个贡献者和用户都应当专注于创建安全可靠的开发环境。

下面,我将和您讨论针对代码安全防护的八项实践。GitHub用户可以根据实际情况进行对标和实现。

加强访问控制

实施适当的访问控制是增强安全性的最佳实践之一。这不仅仅体现在GitHub上,对于任何需要保障代码安全性的环境皆是如此。

目前,GitHub提供了多种选项,让用户减少不当的泄漏风险。其中,我们最常用的当属最小特权(least privilege)模型。该模型仅向用户授予基本必要的权限。如下是我们在使用过程中,需要遵循的各种基本访问控制准则:

  • 限制存储库的创建,以防止用户在公共存储库中公开其组织的相关信息。
  • 启用分支保护和状态检查,以确保用户可以合并各种提交或安全地操作分支。
  • 禁用或有条件地允许fork私有存储库,以确保用户不会暴露或向未经授权方共享所在组织的代码。
  • 撤消那些不再属于贡献者的、所有非活动用户的访问权限。
  • 定期检查对GitHub项目的访问权限。
  • 确保用户不会共享GitHub帐户或密码。
  • 确保每个贡献者在其帐户上启用双因素身份验证。
  • 定期更换个人访问的令牌和SSH密钥。

永远不要在您的GitHub文件中存储密钥

您是否注意到:代码、配置文件或提交的消息,都可能成为被攻击的网关,向其他GitHub存储库泄露机密信息。

为了防止敏感数据被添加到存储库中,请考虑使用诸如git-secrets(请参见--https://github.com/awslabs/git-secrets)或vault(请参见--https://www.vaultproject.io/)之类的密钥管理工具。这些工具会扫描您的代码库,并在代码或配置文件中检测到敏感信息时,立即终止构建。

您也许会在意识到GitHub存储库里有敏感信息泄漏时,立即将其删除。但是,GitHub会在您的存储库中保留所有提交的历史记录。因此仅删除数据是远远不够的,您需要从GitHub存储库的历史记录中清除掉相应的文件(请参见--https://help.github.com/articles/removing-sensitive-data-from-a-repository/)。

同时,为了提高安全性,您也需要将那些已经泄露出去的密钥(包括:密码和令牌),及时设置为失效状态。

为脆弱的依赖项启用安全警报

随着从事的项目越来越多,GitHub用户会发现他们越来越难管理好纷繁复杂的依赖关系。不过幸运的是,GitHub为您提供了自动化安全警报的机制,可以帮助您检测到存储库中脆弱的依赖项。

Github安全实践

(源自https://github.blog/2019-12-11-behind-the-scenes-github-vulnerability-alerts/)

如上图所述,GitHub安全警报源自(美国)国家漏洞数据库(NVD,https://nvd.nist.gov/),GitHub安全公告(GitHub Security Advisories,https://github.com/advisories)和WhiteSource漏洞数据库。它们提供了200多种语言的漏洞数据。通过GitHub上提供的实时安全警报服务,用户可以更加安全地使用各种开源库。

验证GitHub应用程序

GitHub的市场里包含了丰富的由第三方开发人员和组织所编写的应用程序。我们往往需要仔细验证那些被添加到GitHub存储库中的每个应用程序。也就是说,在安装GitHub应用程序时,请注意遵循以下规范:

  • 强制执行最小特权原则。切勿向应用程序授予超出其要求的访问权限。
  • 对应用请求的访问权限始终保持谨慎的态度,要及时考虑到授予某项访问权限可能带来的损害。
  • 在给GitHub的访问主体授权时,请进行背景检查,以确保应用程序背后的组织或开发人员合法且可信。
  • 需要验证应用程序的安全状态是否可靠,以避免整体的安全态势遭受破坏。

根据木桶原理,应用程序的安全性取决于其最薄弱的链接,而GitHub存储库也是如此。因此,在授予应用程序对存储库的恰当访问权限之前,请务必验证它的来源,以确保其真实可信。

审核所有导入GitHub的代码

开发人员往往需要将外部代码导入GitHub中。那么,请在每次导入项目时,务必考虑对源代码执行完整性审核。这看上去非常繁琐,甚至对于一些较小的项目来说有些吹毛求疵,但是这是一种非常好的安全实践,可以在源头上避免向存储库中引入潜在的安全漏洞。

向GitHub导入代码可能带来的另一个风险是:代码中可能包含诸如密码之类的敏感信息。而如果将其存储到GitHub文件中,那么就会提高应用的整体风险值。可见,我们在将代码推送到GitHub之前,必须进行安全态势的审核与评估,以便发现其中的安全风险点。

值得一提的是:在被导入的过程中,代码实际上是从一种封闭的环境,转换到了一种可以被相互调用和影响的环境中。因此,环境的变化也会促使我们重新进行安全关系和执行层面上的审查。

对存储库使用自动静态源代码分析

您可以使用多种第三方工具,来分析存储库中的安全漏洞。其中最为常用的一种工具是WhiteSource Bolt(请参见--https://bolt.whitesourcesoftware.com/),该工具可以在GitHub市场中免费获取到。

WhiteSource Bolt为GitHub检测到的漏洞

WhiteSource Bolt通过扫描您的存储库,以检测出所有开源组件中的漏洞。与此同时,它还能提供详细的漏洞信息,以及对应的修复建议。

当然,您也可以使用其他开源的分析工具,对目标GitHub存储库开展自动化的,源代码级的安全分析。

根据组织的需求,选择合适的GitHub产品

大多数组织,特别是政府部门和金融机构,都会通过规定来限制其开发团队使用GitHub之类的社交开发平台,以防止其他方通过平台访问到本组织的源代码。

如果贵组织确有此项严格的规定,那么请考虑使用GitHub Enterprise(请参见--https://enterprise.github.com/home)。它允许用户在内部托管的GitHub存储库环境中执行各项操作。此举既允许内部开发团队访问到手头所有的项目,又不必担心被GitHub上的其他用户所“剽窃”到,因此,企业软件开发包会得到更加安全的保护。

为您的项目采用全面的安全策略

常言道,安全是一项集体的责任。如果您是一名企业安全经理,那么当务之急就是实施那些能够让所有利益相关者都应遵循的安全策略。理想情况下,您应该在计划阶段,就将安全和开发团队召集在一起,以确保他们能够通力协作。这样,在项目的开发过程中,实施安全控制将会变得更加容易。而随着人员意识的提高,各种所谓在存储库中直接存储密码的行为,也就不会频繁出现。

此外,通过清晰的记录,团队成员还可以及时报告,并协同解决存储库中暴露的各项安全问题。

总结

每位开发人员都应当专注于保护自己的代码,以及在GitHub中的安全问题。上述提供的各项安全实践,值得您和您的团队在开发过程中,持续尝试与践行。

您可以在使用GitHub原生安全服务的同时,实施适当的身份验证和访问控制,并通过集成其他工具的方式,来增强开发工作流程中的安全态势。当然,您也可以通过查看GitHub业务安全性(请参见--https://github.com/business/security)和GitHub安全性文档(请参见--https://help.github.com/articles/github-security/),来获取有关如何保护GitHub上程序代码的更多信息。

原标题:Stay Safe on GitHub: Security Practices to Follow ,作者:Dickson Mwendia

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

责任编辑:赵宁宁 来源: 51CTO
相关推荐

2020-09-03 07:00:00

Salesforce测软件测试

2022-12-21 08:20:01

2015-12-28 10:07:56

公有云退云云迁移

2015-06-15 11:00:41

2021-07-14 10:33:41

云计算数据安全云安全

2020-03-16 08:48:18

Kubernetes容器云原生

2023-08-03 00:06:21

2021-09-14 09:42:54

IT专业人员云安全认证

2016-09-23 20:20:10

2024-01-18 10:33:06

2022-07-12 13:41:38

云计算云安全

2019-09-23 08:56:06

网络安全技术信息安全

2021-11-29 13:36:34

云计算AWS云平台网络安全

2022-03-16 14:29:22

安全漏洞首席信息官

2010-04-30 14:32:46

2021-08-16 11:57:49

安全漏洞GitHubAllstar

2021-04-12 10:04:42

数据库安全漏洞网络攻击

2015-04-08 09:45:26

2010-09-08 15:35:35

2023-01-13 16:34:08

点赞
收藏

51CTO技术栈公众号