本文旨在对近日在日常聊天和开源社区工作时候的一些OpenSSF相关话题进行反思。
本文的创作目的并不带有批评，攻击等任何意味。只是想通过并不严肃的风格来讨论软件供应链安全相关的这个严肃问题。
综述
本文将在时间跨度，纵向技术栈，周期角度来进行一些描述，发现，和讨论，并不加以总结或给出定论/结论。
时间跨度
先跑下题，思考，谁会真正的去在代码层面实现OpenSSF？
在我看来，考虑到Pipeline as code，真正维护pipeline的工程师Devops。最大概率是要亲自上手去更新pipeline，从而将openSSF相关的功能纳入软件构件过程考量的。
那我们不妨问他们一个问题：
你有在pipeline中结合OpenSSF的短期，中期，长期规划么？
从短期来讲
可能我们需要一个OpenSSF badge，来彰显我们项目…
但是：
我们可能要遇到或者思考一个更加棘手的问题。如果我的项目不是给生产使用的，纯工具类项目，我是否要严肃的通过所有OpenSSF问题清单？
比如KIND
kind is a tool for running local Kubernetes clusters using Docker container “nodes”.
kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
当然另外一个方面：
- 从开源项目来说，很多项目使用github action，OpenSSF badge的表格目前并不自动扫描github action，从而我们不得不手工回答这些问题。
- 另外，很多脚本比如lint，可能使用
make lint，make lints或者合并在其他脚本中…我们还是需要手工回答这些问题。
从中期，长期来讲
SBOM或者SLSA，Sigstore
谁来消费SBOM，SLSA？我如何适配Sigstore？
从技术层面上讲，通过适配SBOM的一些github action，我们可以方便的生成SBOM。作为一个懒人，现阶段，我可以把SBOM的结果放哪儿就不管了。
不过考虑到一个事情，在打包过程中生成SBOM是花费额外资源的，比如时间。对于DevOps可能就是一个/组命令的事儿。
我希望中/长期来看业界可以用起来。
Sigstore，同理
纵向技术栈
类似区块链系统，供应链是条链，那么链必然有其头。
一个严肃却又不严肃的问题组：
spring依赖的log4j不安全，我们要不要重新编译log4j？我们要不要重新编译spring？java虚拟机？jvm编译器？操作系统？
因此从纵向技术栈的角度我们总能追溯到操作系统层面：
如果认为从网上拿到的包不安全，那么要不要从编译器开始自己编译？要不要从操作系统开始自己编译？
周期
某种意义上体现周期的，是软件的版本（tag）
考虑一段简单的shell脚本。
我们可以针对它发布不同的版本，比如
v0.0.0 //不带参数执行
v0.0.1 //新增了启动参数
v0.0.2 //新增了功能
我最近看到一些讨论，考虑到git上可以re-tag的功能。有些情况下，人们使用github提交记录哈希ID而不是tag来制定某个依赖的版本。
在我目前看来，指定tag可能足够应对大多数情况了。
即便re-tag，在依赖的目标保证re-tag前后feature不变的前提下。或者tag依旧被视作稳定版本的情况下。使用某一个记录大概率只会添加维护工作的工作量。