TL博士
大多数软件开发安全要求都是以意图的形式编写的，这意味着没有人能通过或不通过这些要求。 “依赖项必须安全”这句话读起来流畅，经得起审查，直到审计人员要求查看文件为止。这份软件安全需求清单用相反的12行文字说明了这一点。
- 只有当三个条件同时存在时，一项需求才能得到验证。 一个已命名的工件、一个检查它的时刻，以及检查失败时的定义行为。大多数软件安全需求都未能满足第一个条件。
- 这 12 行每一行都提供了证据。 出处证明，一份 SBOM 与已发布版本、撤销时间戳、门禁系统相关联cis离子与所有者关联。不是扫描仪报告。
- 他们分成三组。 什么会进入你的软件，什么会构建你的软件，以及什么会证明你的软件状态。
- 验证它们是 SSCS 和 ASPM 问题出在这里，不是扫描仪的问题。 六种工具可生产六种产品 dashboard审计人员只想要一个答案。证据必须来自同一来源，否则就根本无效。
为什么大多数软件开发安全要求在接受审计时都会失效？
几乎任何一份安全需求文档，你都会看到类似“第三方组件必须不存在已知漏洞”和“构建”这样的句子。 pipeline 必须确保安全”。它们读起来很流畅。它们经受住了审查。然后是审计员、客户安全问卷或 NIS2 or 多拉 评估员问了一个简单的问题：给我看看。
这时，要求就失效了，因为没人明确规定“无已知漏洞”在生命周期的哪个阶段意味着什么，由谁来决定，以及需要提交哪个文件。团队手忙脚乱地导出扫描报告，希望大量的发现能体现出他们的尽职尽责。
问题不在于工作量。团队运行四五个工具的工作量已经相当可观了。问题在于，软件安全需求描述的是一种理想状态，而不是一个可检查的事件。理想状态本身没有证据支持，而事件则有。所有使软件开发安全可审计的要素都源于这一区别。
如何使软件安全需求可验证？
三个属性，一项要求必须同时具备这三个属性：
- 一个已命名的物品。 一份证明，一份 SBOM一份签名的记录，一个大门cis离子。以文件或日志条目形式存在，并可根据请求生成的事物。
- 稍等片刻。 Pull request构建、发布或持续进行。“在某个时刻 SDLC“这不是一个瞬间。”
- 已定义的故障行为。 检查失败时会发生什么：阻止、警告、隔离，或将其路由到指定所有者并记录异常处理路径。
将你当前的需求与这三个方面进行比对。大多数需求在第一项上就会失败，这就是为什么团队最终不得不与审计人员谈判而不是直接回答他们的问题。
以下12行代码都经过精心编写，确保每一条都能通过所有三项测试。它们故意写得枯燥乏味。可验证的需求通常都是如此。
软件开发安全需求清单：12 条可实际验证的内容
每一行都列出了证明该结论的文物、检验该结论的问题以及证据的来源。
第一组：你的软件会输入什么内容
| 需求 | 验证方式 | 证据 |
|---|---|---|
| 01无需等待已发布的签名，即可对每个依赖项进行恶意行为筛查。 | 请求提供过去 30 天内添加的任何包裹的筛选结果。 | 恶意软件预警 检测代码中的恶意软件包 pipelines, IaC 在签署或发布公告之前，通过证据检测和人工智能验证，对注册信息进行收集和登记。 |
| 02每次发布都有一个 SBOM可按版本检索，由构建过程生成而非手动组装。 | 命名已发布的版本并请求其 SBOM 五分钟内 | SBOM 每次构建的生成附带漏洞披露报告 |
| 03只有当漏洞存在于你的代码中时，它才会阻止发布。 | 选取三个被阻塞的发现，并询问哪条功能路径可以使它们可利用。 | 功能层面的可达性、可利用性和 EPSS 在优先级排序漏斗中的作用 |
| 04已知易受攻击的组件包含所有者和定义。cis离子，不仅仅是一张票 | 挑出任何一个尚未解决的关键问题，问问谁承担了风险，以及风险持续到什么时候。 | 所有权和状态是根据资产本身进行跟踪的，而不是根据扫描结果进行跟踪的。 |
| 05人工智能和机器学习的依赖关系被视为普通的供应链，因为它们是 | 询问哪些 CVE 会影响当前生产环境中的机器学习库 | 对与使用该平台的 AI 资产相同的 AI 技术栈进行成分分析 |
第二组：你的软件由什么构成？
| 需求 | 验证方式 | 证据 |
|---|---|---|
| 06每次构建都会生成一份可独立验证的来源证明。 | 提取最新生产工件的证明，并将其与源文件进行比对。 commit | SLSA provenance 和 定制的全额证明 采用无密钥签名，可存储在任何注册表中，篡改痕迹在交付前即可被阻止。 |
| 07Pipeline 配置信息以代码的形式进行扫描，扫描频率与应用程序代码相同。 | 询问上次 GitHub Actions 或 Jenkins 配置更改经过安全审查的时间，以及由谁进行审查。 | CI/CD 安全性 覆盖 pipeline 配置错误、工作流程紊乱和供应链风险，以及 SSCS 内置合规性 |
| 08生命周期中任何地方发现的任何秘密都会被撤销，而不仅仅是被报告。 | 请求提供最近检测到的五个密钥及其撤销时间戳 | 跨代码、配置、容器和检测 pipeline包含超过 100 种隐藏类型，此外 自动撤销 playbooks 按凭证类型 |
| 09异常活动 pipeline 在事件发生前发出警报 | 询问什么是受损的跑步者或不寻常的跑步者 commit 模式会触发，以及谁会收到它 | 非常规信号检测 攻击前的活动 |
第三组：什么能证明你的软件状态？
| 需求 | 验证方式 | 证据 |
|---|---|---|
| 10基础设施即代码在合并前经过审核，部署后不会进行修正。 | 询问不安全的 Terraform 变更是否可以提交到主分支，以及是什么阻止了它。 | IaC 扫描 guardrails 的展览。 pull request |
| 11所有工具（包括您自己的工具和第三方工具）的调查结果都遵循同一个严重性模型。 | 询问您的团队，来自不同扫描仪的“严重”读数是否意味着相同的情况。 | 此 ASPM 层 吸收来自以下方面的发现 SAST, SCA，DAST 和 IaC 无论这些工具是由谁开发的，它们都适用于您已在使用的工具，并应用与处理原生发现相同的优先级排序、分类、解释和补救措施。 |
| 12代码库中的每个 AI 资产都已清点并可导出。 | 询问您的应用程序中正在运行哪些模型、代理和 MCP 服务器，并请求文件 | 持续探索 模型、框架、数据集、推理端点、代理、MCP 服务器、技能、提示和 AI 编码工具，以及 CycloneDX ML-BOM 每次扫描都会生成 |
清单上的每一项都由谁负责？
没有负责人栏的需求文档只是一份愿望清单。发布前请务必为每一行指定负责人：
第二列在实践中往往失效。持续验证只有在证据自行积累的情况下才有效。
如何在不添加额外控制台的情况下验证软件开发安全需求清单？
大多数程序都卡在这里。以上12项要求涉及到依赖关系， pipeline构建工件、密钥、基础设施代码和 AI 资产。使用六种不同的工具验证它们，你就创造了第七项任务：协调这六个方面。 dashboard为审计人员提供一个单一的答案，只需一个数字即可。
两项能力使这个问题变得可控。
- Software supply chain security (SSCS涵盖了介于两者之间的要求 commit 以及这件文物。 依赖关系， pipeline系统完整性、秘密和异常活动是攻击面之一，也是最难伪造的证据来源：一份签名的证明对评估人员来说比一份扫描报告更有价值，因为它事后无法重新生成。
- ASPM 是将调查结果转化为你可以汇报的立场的层面。 这一点之所以重要，原因在于：它能够整合现有扫描器生成的内容。您无需为了满足这份清单的要求而更换已付费的工具。它的输出结果会成为输入，同样的优先级排序、AI 分类、解释和修复流程同样适用于这些发现以及系统自带的漏洞。如果软件开发安全程序构建于一个仅能理解自身扫描器的平台上，那么一旦系统环境发生混合，它就会失效——而所有系统环境都是混合的。
当代理人编写代码时，会发生什么变化？
以上所有内容都基于一个假设：变更是由人编写的，并且由另一个人审核的。这种假设正在失效，并且正在重塑软件开发安全需要涵盖的范围。
当编码代理一周内生成上千个文件时，代码审查就不再是一种控制手段，而变成了一种排队机制。在这种情况下，12 行代码中有三行至关重要：恶意依赖项筛查（因为代理会快速拉取软件包，而虚构的软件包名称现在已成为一种已知的攻击途径）。 pull request 分析按可利用性而非原始严重性排序，以及人工智能资产清单。
此外，在2026年编写的任何软件安全需求清单中，还值得添加第四项要求： 指导 AI 工具运行的配置文件将作为安全工件进行审查。 技能文件、规则文件和 MCP 服务器配置是 commit它们以纯文本形式呈现，并像文档一样进行审核，它们定义了助理被指示要做什么以及被允许访问什么。
如何从清单中找到证据？
不要一开始就重写整个文档。通常情况下，只需选取下次审计、客户问卷调查或董事会审查真正会考察的三行文字即可。 SBOM 按需撤销、秘密撤销和构建溯源。用实物完整地验证这三项功能。然后进行扩展。
软件开发安全需求清单并非一份文档练习cis例如，这就像一个安全程序能够回答问题，而另一个安全程序只能描述自身，两者之间的区别就在于此。十二条可验证的语句胜过四十条空想的语句，因为前十二条语句经得起任何人的查阅。
如果你的软件安全需求无法按需生成相应的成果，那么你提出的就不是需求，而是一个带有版本号的意图。
看看你的遗产已经证明了什么。 连接存储库，并 西吉尼 返回你的依赖项， pipeline在单一姿态视图中显示 s、秘密、构建完整性状态和 AI 清单，并将证据附加到每项发现。 免费开始 or 预订演示.
常见问题解答
软件安全检查清单应该包含多少项安全要求？
比你想象的要少。真正有用的数字是你可以随时验证的数量，对大多数团队来说，这个数字在 10 到 20 之间。一份包含 60 条要求的清单，其中 45 条没有任何证据支持，远不如一份只有 12 条要求且每一条都能生成相应成果的清单有效。从你下次审核要测试的那些要求开始，然后逐步扩展。
软件开发安全和合规框架之间有什么区别？
诸如NIS2、DORA或《网络弹性法案》之类的框架会告诉你预期结果是什么。软件开发安全就是将这些结果转化为你的工程团队在特定情况下可以通过或失败的检查项。 pull request 或者构建。框架是为评估人员编写的，需求是为开发人员编写的，而合规性项目中的大部分痛点都来自于没有人进行这种转换。
我能否使用我现有的扫描仪来验证软件安全需求清单？
部分如此。扫描仪会生成结果，但其中一些要求需要以实物形式呈现：例如来源证明、…… SBOM 与已发布版本、撤销记录、大门相关cis与所有者建立联系。这就是为什么检查清单放在…… SSCS 和 ASPM 而不是依赖扫描仪。更实际的做法是保留现有的扫描仪，并在其上方添加一个图层，该图层会接收扫描仪的扫描结果，并对所有结果应用统一的优先级模型。
团队最常出错的要求是什么？
秘密。几乎所有清单都说，秘密绝对不能…… commit几乎没有哪个规范规定必须在规定的时间内撤销检测到的密钥。如果检测到密钥却不撤销，就会在代码库的历史记录中留下有效的凭证，而代码库一旦存在，历史记录就公开了。将该行代码改写为带有时间戳的撤销要求，这样就变得可验证了。
