技术雷达新趋势：软件供应链安全和开源软件经济学受到前所未有的重视
技术雷达是 Thoughtworks 每半年发布一次的技术趋势报告，它持续追踪有趣的技术是如何发展的，我们将其称之为条目。技术雷达使用象限和环对其进行分类，不同象限代表不同种类的技术，而环则代表我们对其作出的成熟度评估。
经过半年的追踪与沉淀，Thoughtworks TAB（Thoughtworks 技术咨询委员会）根据我们在多个行业中的实践案例，为技术者产出了第 25 期技术雷达。对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。
Thoughtworks 一直以来都是开源软件的粉丝。因为 Eric Raymond 发表的著名文章《大教堂与集市》，开源软件普及开来，提高了开发者的能动性，并用众包的形式修复错误，以及创新。然而，商业化的尝试呈现出当前生态系统巨大的经济复杂性。
例如，Elastic 为了要求从中获利的云服务提供商做出回馈，更改了许可证，这导致 AWS 在 2021 年 9 月将 Elasticsearch 复刻为 OpenSearch。这表明商业开源软件要守护竞争的护城河有多么困难（同样的问题也适用于免费的闭源软件，因为 Docker 一直在努力寻找合适的商业模式，我们目睹了一些公司在探索 Docker Desktop 的替代品）。
有时，权力动态会反过来：由于 Facebook 资助了开源软件 Presto ，Presto 的贡献者得以保留 IP（知识产权），并在他们离开公司后将其重新命名为 Trino，这实际上得益于 Facebook 的投资。大量关键基础设施都不是由企业赞助，这会让情况会变得更加混乱，通常只有在发现关键安全漏洞时，这些企业才会注意到他们对无偿劳动的依赖程度（就像最近发生的 Log4J 问题）。
在某些情况下，通过 GitHub 或 Patreon 资助业余爱好者和维护者，可以提供足够的动力来产生影响；但对其他人而言，它是在他们的日常工作之上，增加了额外的责任感，并会导致倦怠。我们仍然是开源软件的坚定支持者，但也认识到经济学正变得越来越离奇，并且没有简单的解决方案来找到正确的平衡。
众所周知的重大安全事故 —— Equifax 数据泄露、SolarWinds 攻击、Log4J 远程零日漏洞攻击等等，都是由于软件供应链的管理不善造成的。开发团队现在意识到，可靠的工程实践也包括项目依赖项的验证和管理，因此本期技术雷达上出现了许多与之相关的条目。这些条目包括一些检查清单和标准，如软件工件供应链层级（SLSA）：一个由谷歌主推，旨在为供应链的常规威胁提供指导；以及 CycloneDX：一个由 OWASP 社区推动的另一套标准。我们还介绍了一些具体的工具，如 Syft，它能够为容器镜像生成软件物料清单（SBOM）。
黑客越来越多地利用安全领域攻防不对称的特点，并且结合日益复杂的黑客技术进行攻击 —— 这意味着他们只需要找到一个漏洞即可，而防御者必须确保整个攻击面的安全。在我们努力保持系统安全的过程中，改善供应链安全是我们应对措施中的关键部分。
蓬勃发展的框架似乎成为了技术雷达中一种常见的模式：一个基础的框架变得流行起来，紧接大量工具的浮现创建出一个针对常见缺陷和改进的生态系统，最后以几个流行工具的巩固而结束。然而，React 的状态管理似乎在抵制这种通用的趋势。自从 Redux 发布后，我们看到源源不断的工具和框架以略微不同的方式来管理状态，每一种都有不同的权衡取舍。
我们不知道原因，我们只能推测：这是 JavaScript 生态系统似乎提倡的自然流失吗？或者是 React 存在的一个有意思且看似易于修复的潜在缺陷，鼓励着开发人员多做实验吗？还是文档阅读格式（浏览器）与在它之上托管的应用程序所需要的交互性（和状态）之间存在永远无法匹配的障碍？我们不知道原因，但是我们期待下一轮的尝试，来解决这个看似永恒的问题。
从企业数据资产中挖掘更多价值的愿望，驱动了我们目前所看到的在数字技术方面的大部分投资。这项工作的核心通常集中在发现并访问所有相关数据上。几乎只要企业在收集数字数据，它就一直在努力将其合理化并编目到一个单一的、自上而下的企业目录。然而一次又一次，这一直觉上吸引人的概念与大型组织中固有的复杂性、冗余性和模糊性的残酷现实背道而驰。最近，我们注意到人们对企业数据编目重新产生了兴趣，以及大量相关巧妙新工具的雷达条目提议，例如 Collibra 和 DataHub 。这些工具能够对跨仓库数据谱系和元数据提供一致的、可发现的访问，但它们不断扩展的功能集也延伸到了数据治理、质量管理、发布等方面。
与这种趋势相反，远离自上而下的中心化数据管理，走向基于数据网格架构的联合治理和数据发现的趋势也在增长。这种方法对期望和标准进行集中设置，而数据管理则根据业务领域线来划分，解决了企业数据的固有复杂性。面向领域的数据产品团队控制并分享自己的元数据，包括可发现性、质量和其它信息。此时，编目只是一种为搜索和浏览而展示信息的方式。生成的数据编目更加简单且更易维护，从而减少了对功能丰富的编目和治理平台的需求。
随着软件复杂性的不断增加，软件依赖项的威胁路径变得越来越难以守护。最近的 Log4J 漏洞表明了解这些依赖关系有多困难——许多没有直接使用 Log4J 的公司在不知不觉中就变得脆弱，因其生态系统中的其他软件依赖于 Log4J。软件工件供应链层级，又称 SLSA（读作 “salsa”），是一个由联盟组织策划的，为组织机构提供防范供应链攻击的指南集。该框架衍生于一个 Google 多年来一直使用的内部指南。值得称赞的是，SLSA 并没有承诺提供“银弹”，即仅使用工具确保供应链安全的方法，而是提供了一个基于成熟度模型的具体威胁和实践的清单。这威胁模型是很容易理解的，其中包含了真实世界发生的攻击实例，并且要求文档中也提供了指南，帮助组织基于日渐增强的稳健性水平为其行动措施排定优先级，以改善他们供应链的安全态势。我们认为 SLSA 提供了适用的建议，并期待更多组织机构从中学习。
当汇总新一期技术雷达的时候，我们时常被一种似曾相识的感觉所倾倒。随着开发框架的涌现，服务器端驱动 UI 技术引发了一个热议话题。这项技术允许移动端开发者利用更快的变更周期，而不违反应用商店关于重新验证移动应用的任何政策。我们在之前的雷达中从赋能移动开发跨团队扩展的角度介绍过这项技术。服务器端驱动 UI 将渲染分离到移动应用程序的一个通用容器中，而每个视图的结构和数据由服务器提供。这意味着对于过去那些需要经历一次应用商店发布之旅的修改，现在只需要简单改变服务器发送的响应数据即可实现。需要说明的是，我们不推荐对所有 UI 开发都使用这种方式。我们的确陷入过一些可怕的过度配置的困境，但是在 AirBnB 和 Lyft 这样巨头的背书下，我们怀疑不只是我们 Thoughtworks 厌倦了一切交给客户端。这一领域值得关注。
对于那些我们正在使用 Terraform 的项目来说，在需要检测潜在安全风险时，tfsec 已经迅速成为默认的静态分析工具。它很容易被集成到 CI 流水线，而且拥有一个持续增长的检查库，可以用来检查所有主要的云供应商和诸如 Kunernetes 的平台。鉴于它的易用性，我们相信对任何 Terraform 项目而言，tfsec 都会是一个非常好的补充。
Cloud Carbon Footprint (CCF) 是一款通过云 API 来查看 AWS、GCP、Azure 云平台上碳排放的可视化工具。Thoughtworks 的团队已经成功使用这个工具 与多个组织合作，其中包括能源科技公司、零售商、数字服务的供应商和使用人工智能的公司。云平台提供商意识到，帮助客户理解在使用云服务时产生的碳排放的影响是很重要的。所以他们开始自主构建类似的功能。因为 CCF 是独立于云架构的，它允许使用者在一个位置查看多个不同云服务商的能源使用和碳排放情况，同时将碳足迹转化为对现实世界的影响，比如排放量相当于多少次航班， 或者多少棵树。在最近的发布中，CCF 已经开始包含针对 Google 云和 AWS 云上可能的节能与减少二氧化碳排放的优化建议，以及支持更多类型的云实例，比如 GPU。考虑到现在这个工具已经备受关注和持续增加新功能， 我们对未来把它挪入试验状态充满信心。
近些年来，Linux 内核已经包括了扩展的伯克利数据包过滤器（eBPF），一个提供了将过滤器附加到特定套接字能力的虚拟机。但是，eBPF 远远超出了包过滤的范围，它允许在内核的不同点位上触发自定义脚本，而且开销非常小。虽然这项技术并不新鲜，但随着越来越多的微服务通过容器编排来部署，eBPF 逐渐自成一体。Kubernetes 和服务网格技术（如 Istio ）被普遍使用，它们采用“边车” （sidecars） 来实现控制功能。有了诸如 Bumblebee 这样使 eBPF 程序的构建、运行和发布变得更加容易的新工具， eBPF 可以被看作是传统边车的替代品。Cilium 的维护者甚至宣布了边车的消亡。基于 eBPF 的方法减少了一些由边车带来的性能和运维上的开销，但它不支持如本地终结 SSL 会话这样的常见功能。
当 Cloudflare Workers 发布的时候，我们着重介绍它是一个面向边缘计算的早期函数即服务（FaaS）方案，实现方案十分有趣。去年（2021 年）四月发布的 Cloudflare Pages 并没有特别引人注目，因为 Pages 只是众多基于 Git 的网站托管解决方案中的一个。虽然 Cloudflare Pages 的确有一个大多数替代方案不具备的有用功能——持续预览。不过，现在 Cloudflare 已经将 Workers 和 Pages 更紧密地集成了起来，创建了一个运行在 CDN 上的、完全集成的 JAMstack 解决方案。键值存储和高度一致的协调原语让新版 Cloudflare Pages 更具吸引力。
根据长期使用 Testcontainers 的经验，我们认为它是创建可靠的环境来运行自动化测试的默认选项。Testcontainers 是一个拥有多种语言版本 的库，并且 docker 化了常见的测试依赖——包括了不同种类的数据库，队列技术，云服务和 UI 测试依赖（例如 web 浏览器），还具有按需运行自定义 Dockerfile 的能力。它与类似 JUnit 的测试框架兼容，而且足够灵活，可以让用户管理容器的生命周期和高级网络，并迅速建立一个集成测试环境。
Zig 是一门新的语言，它与 C 语言共享了许多属性，但是具有更强的类型，更简便的内存分配，以及对命名空间和众多其他特性的支持。然而它的语法，比起 C 更容易让人想到 JavaScript，这点会引起一些人的反对。Zig 的目标是为大家提供一种非常简单的语言，可以直接编译以减少副作用，并且程序执行是可预测和易于追踪的。Zig 还提供了 LLVM 交叉编译功能的简化接口。我们的一些开发同事发现这一特性非常重要，以至于他们尽管没有使用 Zig 编程，但是仍然把它当做一个交叉编译器使用。Zig 是一种新颖的语言，对于正在考虑或者已经使用 C 语言的应用程序，以及需要显式内存操作的底层系统应用程序，值得一试。
欲获取整版技术雷达，请点击左下角 [阅读原文] 进行查看或下载
程序员的自白：我如何让失败项目起死回生，变成价值 270亿美元的应用程序？
保卫腾讯云，专访云鼎实验室董志强（Killer）团队 | 卓越技术团队访谈录
GitHub热榜项目“程序员延寿指南”一周获上万Star；快手前副总裁巨额受贿案宣判；小红书辟谣大裁员：正常人员汰换 | Q资讯
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员