联邦买家要求软件声明：这份文件究竟覆盖哪个发布版本？
先把联邦请求、CISA 声明、产品范围和实际发布版本接在一起，再判断安全软件保障服务该做什么。
重点监测信号
- 联邦买家或主承包商点名一个软件产品，要求在发布或授标节点前提供当前 CISA 安全软件声明
- 生产者有公司级安全开发制度，却无法说明这份声明如何覆盖即将交付的准确产品和版本
- 机构另行要求 SBOM、评估或其他材料，销售记录却把它们误写成声明表格的一部分
一项联邦安全软件声明请求，只有同时落到一家请求机构、一个软件生产者、一个产品或产品线和实际交付的发布版本上，才适合进入服务范围讨论。公司安全开发制度、软件物料清单（SBOM）或另一产品去年签过的表，都不能自动补上这条关系。到了 2026 年 8 月，还必须核对机构当前的保障政策和合同文字：CISA 的现行说明是机构“可以”使用通用声明表，而不是每笔采购一律强制。
这正是软件供应链保障服务商 BD 在获准访问的联邦承包商、软件供应商和安全保障 Telegram 群里要找的 Signal。真正值得马上查看的，不是“联邦项目要声明”，而是产品名、买家或主承包商、尚未确认的版本边界，以及本周发布、投标或验收节点。晚一天看到，可能错过工程、法务和获授权签署人确定声明范围的会议。
这是一份开发实践陈述，不是“版本无漏洞证书”
CISA 安全软件开发声明表页面说明，表格以美国国家标准与技术研究院特别出版物 800-218，即安全软件开发框架（SSDF）1.1 版为基础。通用表让生产者写明覆盖的软件，并对列出的安全开发实践作出声明；无法作出某项声明时，也有相应填写路径。
它不证明某个版本不存在漏洞，也不代表 CISA 已经评估产品，更不会自动包含机构另外要求的所有附件。声明、产品范围和支撑材料必须在销售记录里分开保存。
政策时间线也不能混写。OMB M-22-18在 2022 年 9 月提出联邦机构获取相关软件自我声明的方向，并以 NIST 的安全开发实践为基础。M-23-16于 2023 年 6 月更新实施安排和通用表流程。CISA 当前页面则指向 OMB M-26-05：机构应维护软硬件清单，按风险和任务建立保障政策；机构可以采用 M-22-18 形成的资源，也可以在合同中另行要求当前 SBOM。
因此，2023 年备忘录可以解释表格来源，却不能代替 2026 年的采购要求。销售必须找到当前机构政策、招标文件、合同条款或验收指令。
把声明接到实际发布版本
第一轮判断只需一条六字段记录，不必假装已经完成评估：
- **请求方：**机构、采购办公室或主承包商，以及要求出现在哪份文件里。
- **生产者：**对软件负责的法律实体，不是单纯转发文件的经销商。
- **覆盖软件：**表格上填写的产品或产品线。
- **发布物：**买家实际接收的版本、构建、镜像或发布系列。
- **声明：**表格日期、声明人，以及能声明和不能声明的实践。
- **另行材料：**合同另外点名的 SBOM、漏洞报告、第三方评估或整改计划。
第四项最容易丢。通用表可以覆盖产品或产品线，但采购和工程处理的是具体发布物。公司制度说“所有代码都接受评审”，只能作为背景；它没有说明哪个代码库、构建服务和签名身份产生了交付镜像。反过来，一份发布版本 SBOM 列出了组件，也没有自动证明生产者遵循表中全部实践。
示例：有三份文件，仍不知道覆盖哪个版本
以下是说明用的复合片段，不是客户消息：
“主承包商说周五切镜像前要 CISA 声明。我们有去年的表，还有 4.8 的 SBOM。法务说制度没变，这样够吗？”
这里已有主承包商要求、周五节点、旧表和标为 4.8 的 SBOM；仍不知道机构、旧表上的产品名、周五发布的版本、签署人、当前请求是否仍采用通用表，以及 4.8 清单是否对应最终镜像。
先不要在群里回答“够”或“不够”，而要把空项保留下来：
请求方：已知主承包商，机构待确认；生产者：法律实体待确认；旧表覆盖软件：尚未读取；交付版本：待确认；表格日期与签署人：待核；另行材料：4.8 SBOM，与周五镜像关系未知。
这时服务方向才开始清楚。旧表若覆盖同一产品线，但证据负责人无法接到新版本，可能需要做发布证据映射；生产者若无法作出某项声明，应按表格如实处理缺口，而不是藏起来；如果只缺最终镜像的 SBOM，则应转给组件清单生成或验证工作，不能写成“续证”。
公开群里只问范围，不收敏感证据
首次跟进需要请求原文、表格范围和发布标识，不需要任何人在 Telegram 里发送源代码、凭据、漏洞细节或联邦客户私有记录。可以具体问：哪家机构或主承包商发出要求；表上是什么生产者和产品；交付哪个版本、何时决定；谁有权签署；哪项声明需要证据复核；合同是否另行要求 SBOM 或评估。
如果问题实际是分支控制证据，可查看分支保护供应商风险证据；如果要证明哪些依赖进入发布物，可查看依赖锁文件供应商风险证据。
TOP Prospect 可以筛选用户主动连接且有权访问的 Telegram 群，保留原始消息、来源和时间，去除明确重复，并说明为什么产品名、“CISA 表格”、版本和周五发布同时出现。它不能读取私有代码库、判断机构政策、代签声明、审计 SSDF 实践、联系群成员或保证验收。价格与访问方式介绍的是信息发现层，不是保障意见。
关键事实
- CISA 说明通用表以 NIST SP 800-218、SSDF 1.1 版为基础。
- 通用表识别生产者、覆盖的软件或产品线以及声明人。
- M-22-18 于 2022 年 9 月提出联邦自我声明方向，M-23-16 于 2023 年 6 月更新实施安排。
- CISA 在 2026 年 8 月 14 日访问的页面说明，机构可以在风险保障政策下使用该表，也可以另行要求当前 SBOM。
- SBOM 是组件清单，不是生产者的安全开发声明。
- 产品范围与准确版本或交付镜像之间的关系必须核实，不能靠推断。
FAQ
每一笔联邦软件采购都强制使用 CISA 安全软件声明表吗？
不能这样概括。CISA 当前页面说明，OMB M-26-05 要求机构维护软硬件清单，并按自身风险和任务制定保障政策；机构可以使用 M-22-18 下的通用资源，也可以通过合同提出具体要求。必须回到请求机构和合同核实。
声明记录至少要写清哪些对象？
通用表会识别软件生产者、覆盖的软件或产品线以及声明人。销售记录还应补上准确版本或发布物、请求机构、交付节点和支持声明的证据负责人。
SBOM 和安全软件声明是一回事吗？
不是。SBOM 是组件清单；声明是生产者对安全开发实践作出的陈述。机构可以同时要求两者，但两份材料不能互相替代。
经销商能否代软件生产者签署？
不能只因销售渠道存在就作此推断。表格针对软件生产者及获授权的声明人，实际提交前必须核实生产者、覆盖产品和签署权限。
当团队能在同一行指向买家的当前要求、生产者的声明和准确发布版本，而且没有假装其中一份文件能证明另外两项，商业交接才算完成。
常见问题
每一笔联邦软件采购都强制使用 CISA 安全软件声明表吗？
不能这样概括。CISA 当前页面说明，OMB M-26-05 要求各机构维护软硬件清单，并按自身风险和任务制定保障政策；机构可以选用 M-22-18 下形成的通用资源，包括这份表，也可以通过合同提出具体要求。必须回到请求机构和合同核实。
声明记录至少要写清哪些对象？
通用表会识别软件生产者、覆盖的软件或产品线以及作出声明的人。销售记录还应补上准确版本或发布物、请求机构、交付节点和支持声明的证据负责人。
SBOM 和安全软件声明是一回事吗？
不是。软件物料清单（SBOM）是组件清单；声明是生产者对安全开发实践作出的陈述。机构可以同时要求两者，但两份材料不能互相替代。
经销商能否代软件生产者签署？
不能只因销售渠道存在就作此推断。表格针对软件生产者及获授权的声明人，实际提交前必须核实生产者、覆盖产品和签署权限。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
