Kubernetes 漏洞的教训：供应链安全
发布时间：
2022-12-12 14:56
前言
去年年底在Kubernetes 编排系统中发现的缺陷，使人们意识到开源软件在企业中的价值和关键任务属性，也提醒我们必须注意保护上游开源项目。
自2015年发布以来，Kubernetes已经成为目前受欢迎的容器编排系统，无论公司是通过平台还是直接通过Kubernetes项目实现，都能获得极大的便利。
CVE-2018-1002105是一个特权提升问题，使用户可以拥有在Kubernetes Pod所运行的计算节点上的管理员权限。
使用Kubernetes作为商业平台一部分的公司甚至在问题发生之前就已经修复此漏洞。以下是应该将安全性转移到上游的原因。
开源带来的更广泛风险
使用Kubernetes的公司，必须独立完成这项工作。这项工作可能会比较轻松，也可能具有挑战，甚至不可能完成，这都取决于组织的资源。但是这样一来，使用商业供应商提供的开源软件的组织风险降低了，因为供应商可以提升供应链安全并提供持续的安全修复。
在企业中更广泛地使用开源，并没有完全减轻基于社区的支持模式带来的风险。当涉及到上游项目(或开源“源代码”)的使用时，尤其如此。
许多公司决定下载和使用开源软件来节省时间和费用，而不是购买或订阅基于开源项目的商业软件。他们可能会认为，在安全性和问责性方面所牺牲的，可以用节省的成本和敏捷性来弥补。
需要考虑的关键问题
这可能是对的，但如果你决定要追根溯源，一定要做好准备。公司需要问自己三个问题:
-
我们是否有方法来盘点组织中开源代码使用的范围?
-
当发现新的高风险安全漏洞时，我们是否有能力确定哪些存在风险，哪些没有风险?
-
我们是否有适当的方式来快速查找和修复漏洞，并快速将所有受影响的系统更新到包含修复程序的新版本?
以补丁管理为例。员工中是否有人有时间和能力来决定哪些开源项目需要修补，以及何时修补？如果修补的话? 公司可以自研或购买一个用于主动扫描的工具，但是打补丁不仅仅是确定需要一个补丁，还要安装补丁。
对更广泛的系统会有什么影响?是否会影响应用程序?补丁会破坏什么吗?简而言之，你不仅需要有进行修补的资源，还需要评估对特定环境的影响。
反复出现的漏洞
Gartner表示，到2020年底，99%的被利用的漏洞将继续是安全与IT专业人士在事件发生时所知道的漏洞。
这告诉我们，大多数组织没有一个主动的补丁策略，内部没有进行补丁的能力或资源，也不能确定哪些系统受到漏洞的影响，故意不打补丁，因为害怕它们会影响某些东西或全部东西。
然后是软件供应链。你正在使用的开源项目可能依赖于或包含其他开源项目，这使得确定漏洞修复是否可用变得更具挑战性。
当平台供应商在他们的平台中实现开源时，他们会审查代码，确认代码经过检查、深度测试、数字签名和安全分发，并提供了持续的安全更新。
即便如此，商业提供商可能会认为某些代码使用风险太大，因此他们会提供广泛的质量保证，并让软件通过严格的安全认证，例如使用通用标准（Common Criteria）和FIPS 140-2标准。
平衡风险、预算和工程资源
毫无疑问，开源推动了创新和敏捷性开发，促进直接与上游项目合作。但是组织需要对其全面审视。根据组织中所有利益相关者达成一致的风险策略，决定如何平衡安全风险、预算和内部工程资源。
当涉及到开源时，上游项目总是有意义的，就像组织总是需要安全和管理支持一样，同时也需要降低风险带来的安心。
© 2023 8590am发现海洋之神
