我们从 SolarWinds 黑客事件中什么也没学到

包签名、仓库与依赖信任

• 几条评论批评 PyPI 移除了 PGP 签名，以及各大包仓库普遍缺乏稳健的签名/验证机制。
• 有人依赖发行版打包（.deb）和本地镜像而不是 PyPI，认为这样能进行更好的签名检查，并修补损坏的包。
• 企业工具（例如类似 JFrog/Sonatype 的工具）会在不同生态系统中对组件进行哈希和标记，被视为有用的权宜之计，但在公共仓库中并不广泛 उपलब्ध。
• 过度依赖 GitHub 作为 CI、包来源和代码托管的事实支柱，被视为一种系统性风险。

扫描、通用工具及其局限

• 人们对能够分析二进制或源码、以发现供应链攻击的服务很感兴趣，但许多人怀疑其有效性和可扩展性。
• 能够检测“可疑”包行为（静态/动态分析）的工具已经存在，并且正在积极开发中。
• 普遍认为，通用包管理器在大规模场景下不可行。

经济、激励与责任

• 评论者强调，组织想以最低成本获得“足够好”的安全；真正的加固在经济上并不吸引人。
• 罚款和监管压力可能有帮助，但也可能巩固大型供应商，并伤害小公司和开源项目。
• 有人认为，我们应该通过隔离和缩小影响范围来设计能够容忍被攻破软件的系统，而不是假设所有软件都能变得安全。

能力模型、沙箱与操作系统设计

• 标准化的 capability 模型被视为理想方案，但在政治和技术上都不太可能，而且容易被厂商滥用（例如重新定义 capabilities 以保护商业模式）。
• 也有人强调隔离与冗余，并将其类比为安全关键系统：单点故障不应拖垮整个系统。
• 讨论还涉及移动端权限模型（iOS/Android）、侧载，以及“锁得很死”的“安全”平台与用户自由之间的权衡。

供应链安全与证明

• 有人提出使用加固、隔离的构建系统，以及标准化元数据/证明（例如 in-toto、Witness），来跟踪和验证供应链步骤。
• 讨论了带远程证明的机密计算，作为一种证明制品是由特定源码、使用特定工具构建而成的方法，即使主机已被攻破也如此。
• 这会把攻击面转移到编译器和构建工具本身，因此人们开始关注内存安全编译器和可复现构建。

运营现实与合规

• 实践者指出，对于高级威胁，预防手段有限；现代实践更侧重 EDR、日志、SIEM，以及对入侵后的行为进行检测。
• 企业网络被描述为混乱的环境，存在许多遗留约束和用户体验取舍。
• 安全问卷和勾选式合规被批评为过时，且与云原生架构不匹配，不过也有人在尝试简化这些流程。