“安全左移”
在过去 5 年多的时间里，任何从事网络安全和软件开发工作的人，都不可避免地听到过 "安全左移 "这个词。
它与 DevSecOps 等概念的兴起不谋而合，重点都是将安全融入到整个 SDLC 中。安全左移是指将安全左移到 SDLC 早期的阶段，以便在生产阶段之前发现并修复缺陷。
支持安全左移的常见说法是：在 SDLC 早期修复缺陷的成本远低于在生产阶段的修复成本。
问题出在哪里？
这种说法和支持这种说法的数据是建立在谎言之上的，或者至少是建立在从未证实过的非常可疑的来源之上的。美国网络安全和基础设施安全局（CISA）网络安全咨询委员会（CSAC）下属的一个小组提交的一份报告中提出了这一观点。详情如下：
CISA 的报告指出，"安全左移 "节省成本的推测来源于一个自1980年代以来就不复存在的组织，且该组织甚至不是一个正式的研究机构。同样地，Barry Boehm提出的另一个说法也是毫无根据的，他说在交付后修复软件问题要比在设计阶段发现和修复问题 "贵 100 倍"，而且没有确凿地实证数据来支持这一说法。
报告还指出，即便是现代的一些报告，如 IBM 和 Ponemon 的《数据泄露成本》报告，也没有提供在安全漏洞发生前发现并修复安全漏洞的实际成本数据。
因此，虽然安全左移并在生产前修复软件缺陷是合乎逻辑的，也是合理的，但这一运动是建立在非官方来源的推测之上的，其中一些可能根本就不存在。
我在 LinkedIn 上就这一话题发布了一个主题，有位用户分享了下面这张图片，显然这就是最早用来证明安全左移可以节约成本的原始来源。
CISA在报告中进一步建议，应进行更多研究，以提供实证数据来验证在SDLC早期修复安全漏洞是否确实更具成本效益。
他们甚至表示：
"如果发现没有可量化的财务影响，那么或许应当考虑放弃将经济理由作为推动安全开发的激励手段"
但是，如果安全左移没有任何财务影响或经济价值，我们打算如何激励企业（财务驱动型企业）在 SDLC 的早期阶段优先考虑安全问题，并在风险向下游转移到客户、消费者和社会之前降低风险？
我们可以说，从安全的角度来看，在生产前减少缺陷、错误、配置错误、不安全地设计和漏洞是至关重要的，以防止它们被利用，当然，这并不像之前引用的那些声称开发者成本节约达100倍或更多的研究那样具有吸引力，因为后者强调的是“节省成本”。
这就是为什么 CISA 建议开展正式研究，以获取实证数据，看看安全左移以及在 SDLC 早期修复缺陷是否确实节省了成本。在安全方面，重要的是我们要以企业关心的方式（钱）来呈现安全发现。
谈论漏洞、可利用性和其他安全用语不太可能引起我们业务同事的注意。正如那句老话所说，先看钱。
进一步加大这一挑战的是，我们发现安全事件与股价等商业指标之间的相关性极小。
最近的研究 表明，以提交 SEC 8K 的组织为例，其股价仅下跌了约 1.4%，在事件发生后 40 天左右跌至谷底，53 天后恢复，并继续攀升至事件发生前的水平。同一研究表明，SSN 等敏感数据泄露居然比电子邮件地址等信息泄露对股价的负面影响还小，这令人费解。
CISA 在他们自己的报告中，讨论以下问题时也提出了类似的结论：
“事实还是神话？——安全缺陷让人们远离解决方案。”
他们的共识是什么？
"总的来说，质量问题似乎并不总是影响客户的忠诚度"。
他们指出了以下三个例子：
以 Target、三星和 SolarWinds 为例，他们展示了影响广泛且引人注目的安全事件通常不会对组织地客户群、收入、市场份额等方面造成负面影响。
正如他们所说，影响客户行为的因素不仅仅是事件本身，还包括转换成本、客户深入了解事件的难度（LOE） 以及受影响公司在事件后的公关方式。
CISA 报告的特别之处在于，它甚至直截了当地指出，仅仅告诉企业不修复漏洞会影响其业务并不足以激励他们采取行动。
然而，当我们观察 “安全设计/默认安全” 的指导，“默认安全”承诺以及其他例子时（我并不想针对 CISA，因为我是他们的忠实粉丝），我们会发现这些都是我们作为安全行业在告诉厂商和组织，他们应该修复漏洞，因为……好吧，就是这样。
如果他们知道（现在也有数据验证了这一点），在 SDLC 早期修复漏洞所节省的成本存在投机性，而事故、漏洞等对企业的影响微乎其微，那么他们还会优先考虑安全问题吗？
阻碍安全左移的另一个挑战是——业界采取了一种工具导向的方法，并将其视为流程而非产品。但安全本身不是看你买了什么，而是你做了什么。
这些都是网络安全中的错误做法，甚至在 Mark Simos 的 RSA 演讲"安全行业常见的错误做法！来看看你有没有中招"。
多年来，“左移”和“DevSecOps”等术语被滥用，常常指的是在流水线中添加一堆缩略词工具（例如SAST、SCA、IaC等），然后声称自己已经实现了左移或在进行DevSecOps。
别误会我的意思，这些工具对于在 SDLC 早期识别并修复缺陷确实非常有价值，但它们远不能体现“将安全内置于流程中，而不是事后附加上去”这一原始概念的真正含义。
威胁建模和安全编码等活动，涉及系统设计中的安全性、架构安全审查等，同样是将安全集成到软件开发生命周期（SDLC）开始和早期阶段的基本且关键的环节。
美国国防部DevSecOps 参考设计 是个不错的例子，具体如下：
工具导向思维有多种原因，其中一些原因与人类的天性——倾向寻找快速解决方案有关，他们认为购买某样东西就能立即解决问题。工具导向思维是网络安全思维的“Ozempic”。
（Ozempic是一种用于减肥和控制血糖的药物，因为它能带来较快的效果，所以很多人认为只要用它就能轻松解决肥胖问题，而不需要改变生活方式或饮食习惯。）
正如我的朋友、《软件透明度》的合著者托尼-特纳（Tony Turner）在 LinkedIn 上指出的那样：工具导向思维在很大程度是由厂商推动的。因为与其他一些活动相比，工具更容易销售，而这些其他活动更多的是实践或行动，是我们要去做的事情，而不是直接可以买到的东西。
对于初创公司而言，向风险投资公司推销一个围绕工具的产品会更容易，例如描述总潜在市场（TAM）、提出与CI/CD流水线等其他产品的集成方案，并制定市场计划，将该产品销售到企业中，以便客户可以购买、部署和/或集成到他们的环境中。相比之下，如果主打威胁建模、安全编码以及安全系统需求和设计等需要积极参与的活动就会困难得多。（尽管确实有一些工具确实有用）
我们必须记住，当一种趋势（如安全左移、零信任、安全设计等）开始出现时，这些趋势就会被初创企业、创新实践者和投资者视为商机。他们希望将能力产品化并实现商业化，以供市场消费。
然而，这种以工具为导向方法（包括安全左移）正在显露一些问题。安全领导者和项目团队在不断追逐各种安全工具，仿佛在玩“安全工具宝可梦”一样（必须集齐所有工具！），又或者是 “Gartner流行术语象限宾果游戏”。
