2022 年 XNUMX 月，美国管理和预算办公室 (OMB) 发布了 里程碑式的备忘录 关于将您的软件供应链保护到美国联邦政府可接受的程度所需的步骤。任何希望与政府和任何生产软件的联邦机构开展业务的公司都需要遵守该法案中提出的要求和时间表。 M-22-18 备忘录.
M-22-18 重点关注软件供应链的安全性和完整性，特别关注 物料清单。它包括一系列要求和实施合规所需步骤的时间表。
该备忘录确立了 NIST 制作的两份主要文件： 安全软件开发框架（SDF）， SP 800-218及 软件供应链安全指南 作为 NIST 关于安全软件开发的指南。该备忘录还概述了软件生产商有责任在联邦机构自由使用其产品之前自我证明其遵守 NIST 的指导。该自我证明将采取签署的自我证明“通用表格”的形式。三类软件需要这种自我证明表格：新软件购买、主要版本升级和软件续订。
M-22-18 要求 CISA 在该备忘录日期（120 年 14 月 2022 日）后 120 天内制定此标准自我证明“通用表格”。 2023 年 XNUMX 月，这 XNUMX 天已经过去，但表格仍在 表格草稿 尽管评论期于 26 年 2023 月 XNUMX 日结束。 OMB 备忘录最初指示各机构开始收集关键软件证明的时间大致在此时。
根据收到的有关该通用证明表的一些意见，OMB 认为适合于 22 年 18 月 9 日发布 M-2023-XNUMX 修正案。该修正案的标题为 M-23-16. 新备忘录延长了 M-22-18 上发布的各机构从软件生产商处收集证明的时间表。现在要求各机构收集 自我证明“通用形式” 在 CISA 通用自我认证表获得 OMB 批准后三个月内，由软件生产商提供“关键”软件。所有其他软件生产商在自我证明表格获得 OMB 批准后有六个月的时间。
从此 标准自我证明表格似乎占据了中心舞台，让我们更详细地检查一下其中包含的内容。我们还将了解到底谁应该签署它以及这样的签名意味着什么。
安全软件自我认证通用表格
遵循从 EO 14028 到 NIST 指导文件再到 OMB 备忘录的监管链，很明显，政府的目标是保护每个人，包括联邦机构和私营部门公司，免受 软件供应链漏洞 和入侵。由于私营部门在这方面做得还不够（在政府看来），政府已着手制定新的法规，每个人（向联邦政府出售产品的人）都必须遵守。
当然，即使您（尚未）不向联邦政府出售产品，遵守这些规则并自我证明您是“安全的”也符合您的最佳利益，因为此类公司将成为更具吸引力的业务合作伙伴。谁愿意与一家无法确认他们正在尽一切努力保护其产品和用户的公司开展业务？
由于我们已经确定 NIST 指南是新法规和最佳实践的基础，因此出现相同的建议也就不足为奇了，例如， SSDF 也出现在自我证明表格中。
以下是文档草案中的一个简短示例：
摘自安全软件自我认证通用表格草案
我们可以看到左侧的要求，后面是相关的 EO 部分，然后是 SSDF 实践和任务。这是一个相当全面的要求列表（一页半），如果读者不从事网络安全和/或 DevOps 或 DevSecOps 业务，则不一定完全清楚。
该文件要求公司签字人亲自证明表格中概述的所有要求均得到一致维护，并且如果列表中的任何元素不再有效，公司将通知受影响的机构。
该文件没有具体说明公司中的谁应该签署该文件，但由于此表格是公司与联邦政府及其机构开展业务的要求，因此首席执行官是应该承担责任的人这里。 CEO 可能不会盲目签署，并要求其 CTO 和 CISO 验证（可能以书面形式）公司确实遵循所有这些准则和要求。
由于没有既定的产品或运营模式来收集和证明所有这些要求，从某种意义上说，每个签约公司都需要为自己“重新发明轮子”，并希望不会发生任何不好的事情。
如果确实发生了不好的事情，那么联邦政府将追查签字人，以证明他们可以支持所有表格的要求。
如果我不签名会怎样？
首先，目前只有当您的软件由联邦机构使用、您打算将您的软件出售给联邦政府，或者您的软件由其软件正在使用的供应商使用时，整个证明事情才相关。或打算出售给联邦政府。
请注意，我说的是“当前”，因为有迹象表明 SSDF 合规性（无论是作为自我证明还是以其他可验证的形式）将成为软件生产领域的新“最佳实践”。
因此，假设您的公司属于上述群体，并且您无法心安理得地签署这份文件，那么一切还没有丢失。只要你能说明认证的不足之处并提供满意的证明 行动计划和里程碑 (POA&M) 有关联邦机构仍然可以购买/使用您的产品，并代表您向 OMB 寻求软件延期。
坏消息是，无论是否有 POA&M 计划，您最终都需要提供完整的证明表格，这意味着您需要能够向联邦法院核实您的公司是否遵循了该表格要求的所有步骤，并且您的软件开发过程至少与表单的要求一样安全。
目前唯一免于这种形式证明的软件是联邦机构开发的软件和免费提供的软件，又称开源软件。当然，大多数 软件供应链安全 漏洞可以通过某种方式追溯到代码中的某些开源包，但试图迫使免费工作的开源开发人员和维护人员为其软件提供具有法律约束力的保证是一个真正的问题。任何使用开源软件的人都应该有责任验证其安全性，无论是在一般情况下还是在特定的嵌入软件中。
最坏的情况
整个软件供应链的安全责任始于著名的 SolarWinds的 破解。无需透露太多细节，黑客攻击时，该公司超过 18,000 名客户受到影响，其中包括 9 个联邦机构。
直到几年后的现在，我们才开始看到这一事件的一些法律结果。美国证券交易委员会， 美国证券交易委员会， 正在追捕该公司 整体以及几位C级高管之后。这可以被视为政府意图的一个例子，如果这样的事件或类似的事件发生在软件生产商身上，他们证明了他们的安全开发实践，但却成为黑客攻击的受害者。
就 SolarWinds 而言，该公司全力支持任何受到此类法律诉讼的员工。了解美国的法律体系，此类案件可能需要数年时间并花费大量资金。罚款并非不可能，根据估计，罚款金额可能达到数百万美元。 遭受的损害.
您可以想象，并非所有公司，尤其是中小型公司，都像 SolarWinds 那样坚定地保护员工。问题是，如果被告是公司的首席执行官，那么市场对公司及其产品的信任很可能会严重受损。在没有财力雄厚的大公司支持的情况下面对美国证券交易委员会可能会毁掉毫无戒心的首席执行官以及他们的公司。当然，其目的是让人们认真承担确保发展的责任，但恐惧可能会让人们犯下自我保护的错误。这意味着，如果人们认为自己无法赢得 SEC 的潜在案件，或者担心此类案件的成本和不良宣传会非常严重，因此无论法庭案件结果如何，最好隐藏它们，他们宁愿隐藏网络安全事件。
我怎样才能签名？
NIST SSDF 指南充满了建议和最佳实践，但缺乏实用性。由于每个公司都是独一无二的，因此很难推出适合每个人的产品或系统。在这种情况下，私营部门正在介入填补真空，创建一个生态系统来帮助您满足要求。
例如， Scribe搭建了一个平台 基于创建证明、签署证明并提供验证能力的概念。我们很快就会发布一份专门针对 CISA 自我证明表，演示 Scribe 解决方案如何帮助您满足要求的每个部分。敬请关注。
尝试 Scribe 的平台是免费的。我鼓励您尝试一下，看看如何使该平台符合您的要求，同时问心无愧地签署 CISA 的自我认证表格。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
