Jeremy Schneider：杂项学习：SBOM、来源证明与认证
内容提要
作者推进CNPG-Extensions项目，为容器镜像提供来源证明和SBOM，以便扫描许可证与漏洞，并探索pgrx扩展的Rust依赖图。他反思Postgres扩展管理、贡献门槛与信任问题，强调AI虽能写代码，但长期维护和人类责任更重要，并认为OpenSSF评分卡值得参考。
延伸解读
SBOM与来源证明的实践价值
作者为CNPG-Extensions项目引入SBOM和来源证明，旨在让扫描器准确报告许可证和比对漏洞数据库。对于pgrx扩展，他尝试在SBOM中纳入完整的Rust依赖图，以便Trivy等工具能发现深层依赖中的RUSTSEC漏洞。这提醒我们，软件供应链安全需要关注依赖树的每个层级，而不仅仅是顶层包。
Postgres扩展管理的信任与贡献门槛
作者反思了CloudNativePG扩展管理中的开放问题：贡献门槛多高、需要多少审查、如何避免“路过式”的大块代码贡献成为负担，以及如何决定是否信任贡献者。他考虑将CNPG-Extensions作为低门槛选项，但不确定是否可行。这反映了开源项目中平衡开放性与可持续性的常见挑战。
AI编码时代的人类责任与长期维护
作者强调，AI虽能帮助编写代码，但不会改变计算的基本原理。他提醒，代码发布容易，但长期维护（如Log4Shell事件后重建）需要人类投入。选择项目时，应关注背后的人是否认真、有承诺，或自己愿意承担全部责任。OpenSSF评分卡可作为评估项目健康度的参考。
Q&A
CNPG-Extensions项目的主要目标是什么？
CNPG-Extensions项目旨在为容器镜像提供来源证明和SBOM，以便扫描许可证和漏洞，并探索pgrx扩展的Rust依赖图。
为什么作者认为SBOM和来源证明对容器镜像很重要？
它们能让用户对容器镜像内容更有信心，使扫描器能准确报告许可证，并将软件版本与漏洞数据库对比。
作者在管理Postgres扩展时遇到了哪些开放性问题？
如何管理Postgres扩展与CloudNativePG的集成、贡献门槛多高、需要多少审查、贡献者应有多少承诺、如何避免可能成为负担的随意贡献以及如何决定是否信任某人。
作者对AI编写代码的看法是什么？
AI擅长编写代码，但长期维护和人类责任更重要。需要关注背后的人类是否投入和坚持，或者自己愿意承担全部责任。
OpenSSF评分卡在文章中起什么作用？
作者推荐OpenSSF评分卡作为评估项目维护和安全的参考，认为它值得一读。
作者如何管理多个并行的工作流？
作者使用五个不同的git分支，每个分支从上一个分支派生，并在上层分支变更时进行变基。代理允许他启动长时间测试，12小时后检查结果并做设计决策，但并行工作流带来大量心智负担。
