5.5 安全传输

在供应链风险管理的核心是信任的概念，或信任的验证。这包括对软件来源或出处的信任，相信它不包含超出我们风险容忍度的组件或库，相信在到达我们之前没有发生变化，相信我们即将安装的是我们所预期的产品。

安全传输机制可以有多种类型，但我们常谈的是传输层安全性（TLS），它是安全套接字层（SSL）的后继者。TLS的任务是将数据从点A安全地传输到点B，并确保高度的信任，以保证内容保持机密性和完整性没有受到损害——信任信息的发送和接收方是我们所认为的那些终端，而且数据在传输过程中未经修改。虽然TLS也用于加密和保护数据流的保密性，使得透明性的任务更加困难，但它也使得操纵数据流变得更加困难。这是一个在透明性和安全性之间有意识的权衡领域。虽然你不能再直接查看数据流中的活动，但如果你信任源头并且数据没有发生变化——也无法发生变化——那么你就可以信任到达目的地的内容。

不幸的是，这些信任决策的根源是证书颁发机构（CA）基础设施。这种机制建立了一个支撑互联网运行的信任网络。它是一个相对集中的生态系统，因为如果CA被破坏，他们签发的TLS证书或代码签名证书也可能被破坏。然而，CA机制提供了一个合理的保障，即执行这些攻击所需的难度对于大多数组织的威胁模型来说是足够的，因此基于TLS的决策通常被认为是安全的。

如前所述，对手通常会滥用加密通道来隐藏他们的恶意流量。然而，由于现代TLS协议的特性，特别是使用完美前向保密等技术，使得解密和重新加密传输变得困难，甚至对防御者来说也是如此。这将潜在的风险限制在点A和点B之间，而消除了中间30多个网络跳点作为潜在的攻击点。

同样，我们需要能够信任用于风险决策的声明。我们如何知道软件物料清单（SBOM）或构建声明是合法的？透明日志和区块链技术提供了在交易起点（例如点A）上的透明性和信任，一些实现甚至可以实现端到端的透明性和信任。但是，我们如何确保通过网络传输的数据保持不变呢？幸运的是，利用TLS隧道可以帮助回答这些问题。

那么，如果软件和声明没有通过这种方式进行保护呢？这是否意味着它们是不安全的？即使在今天，许多现代的Linux发行版也并未通过TLS来保护其软件仓库的流量，而是依赖于GNU隐私卫士（GPG）签名来确保软件的完整性。在这种情况下，你需要根据自身的风险承受能力做出判断。不过，可以说，即使在2023年，如果你要求所有软件都通过TLS进行传输，很多企业软件的使用也会受到影响。

在TLS使用更加普及之前，我们认为这可能只是针对除了最关键软件以外的一种“可选项”。尽管实施TLS存在一些挑战，但像零信任（Zero Trust）这样的运动正在推动端到端加密，作为组织应采用的最佳实践和实施方式。

此外，越来越多的组织正在努力采用双向TLS（mTLS），它使用与TLS相同的协议，但进行双向验证而非单向验证。这意味着，在建立连接和进行数据交换之前，服务器和客户端的身份都需要得到验证。