前言

在安全领域的多个方向工作了这么多年后，我得出了一个可能会让一些同行不快的认知：安全并不特殊。它不是魔法。它不是一个独立的、神秘的学科，生活在自己的神圣空间里，由神秘的检查清单和莫名其妙的风险评分管理。它就是工程工作。有时这项工作做得很好。大多数时候，并没有。当它没有做好时，就会像其他形式的技术债务一样堆积起来——等着在你最负担不起的时候在你面前爆炸。

我知道这对一些人来说听起来很简化，但实际上这是解放性的。因为如果安全只是工程工作，解决方案并不复杂。你不需要一个戴着兜帽的魔法师。你不需要另一个厂商仪表板。你只需要像对待工程积压中的其他部分一样对待它：识别、优先排序，然后像修复任何其他缺陷或未完成功能一样修复它。

安全的重大误解

很长时间以来，我们一直将安全视为这个神秘的、专业化的领域，它以某种方式独立于"正常"工程之外。我们围绕这种误解建立了整个组织结构——安全团队与工程团队，安全积压与工程积压，安全评审与代码评审。

但是这里有一个令人不舒服的真相：这种分离是人为的和适得其反的。它是完全有害的。

当我观察我们所谓的"安全工作"时，我看到的是还没有完成的工程工作。那个漏洞扫描发现？它只是一个工程缺陷。那个缺失的访问控制？它只是一个不完整的功能。那个过时的库？它只是被忽视的维护。那个"关键P1安全工单"只是一个带有营销标签的bug。

让我们谈谈那些我们贴在安全工单上的荒谬"风险评分"。CVSS 9.8！严重程度！但是为什么我们没有为可靠性问题设置类似的戏剧性评分？当服务不稳定并丢失5%的客户交易时，我们不会给它分配"可靠性评分：灾难性"标签。我们只是修复它，因为它坏了。安全缺陷应该得到同样的待遇——它们只是需要修复的bug，而不是需要特殊处理的特殊生物。

为什么安全变成了孤岛

那么我们是如何走到这一步的？历史并不好看。部分原因是自我。安全人员想要感到特殊。是的，我说了。我们围绕我们的职业建立了神秘感，因为成为具有深奥知识的专业专家感觉很好。我们培养了"领域守护者"、"知识管理员"的形象，这些知识对工程师来说太复杂了。

合规使情况变得更糟，并为分离创造了人为需求。像SOX、PCI-DSS和HIPAA这样的法规强调"职责分离"和专业安全角色。公司通过创建孤立的安全团队来勾选合规框，而不是将安全集成到工程流程中。

厂商们很乐意强化这种模式。有一个完整的行业建立在安全工具、咨询和服务之上，这个行业依靠安全的感知特殊性蓬勃发展。如果安全变成了"只是工程"，数十亿的专业安全支出可能会重新定向到一般工程质量上。

随着时间的推移，我们制度化了技能差距——不会编码的安全人员，不理解安全的工程师——并建立了流程来保持这些差距安全地孤立。

当这些孤岛不可避免地开始拖慢速度时，我们做了大多数组织都会做的事——我们创造了另一个创可贴：Security Champion项目。让我明确一点——我建立过它们。我运行过它们。但我们需要它们这一事实本身就是问题的症状，而不是解决方案。我们创建Security Champion是因为安全还没有被视为工程日常工作的一部分。我们不得不指定特殊的人来"倡导"安全，因为否则，它根本不会被优先考虑。

但想想这个——你见过可靠性Champion吗？你见过有人被指定跑来跑去提醒团队关心延迟或可观测性吗？当然没有。这些东西已经融入我们构建系统的方式中。每个工程师都理解正常运行时间、故障处理和监控是构建生产级软件的一部分。没有人需要特殊的头衔来倡导这些。

然而，不知何故，安全仍然需要挥舞自己的旗帜。我们不组织SRE意识周，但不知何故安全有自己的"安全意识月"——就好像记住不发布不安全的软件是一年庆祝一次的事情，而不是我们每天都应该期望的事情。

安全仍然需要"Security Champion"来提醒团队验证输入或保护客户数据这一事实并不意味着成熟——它表明我们还有多远的路要走。这不是胜利。这是一个创可贴，贴在仍然将安全视为额外工作的文化上，而不是软件的基本部分。

结果正是你所期望的：安全生活在自己的积压中，有自己的语言，自己的工具，以及自己的一群人不断乞求关注。因为它生活在工程工作的日常流程之外，它几乎总是在争夺注意力的斗争中失败。

糟糕工程合理化的最佳金曲

团队忽视安全不是因为他们不关心。他们忽视它是因为他们说服自己这样做是安全的。你听过这些借口。你甚至可能说过它们。

有经典的"它在身份验证后面，所以我们是安全的"，好像任何有账户的人都不是潜在攻击者。或者大众最爱，"我们的云提供商处理这个"，而实际上，你仍然拥有应用程序、数据和你部署的每个不安全配置。

一些团队喜欢说"我们太小了，不是目标"，这使他们对寻找容易赚钱的攻击者更有吸引力。当然，还有史上第一热门金曲："我们将在发布后处理它。"

当你的工程师必须来查看安全团队的JIRA面板时，你知道你有安全债务问题，而这个面板几乎没有被打开过。当你报告与去年相同的渗透测试漏洞时，你知道你有问题。当你的安全事件经历完全不同的流程，有完全不同的操作手册，有完全不同的事件报告模板，由甚至不说同一种语言或使用同一工具的团队配备时，你真的知道你有问题了。

安全工作就是明天的工程积压

让我分享一个故事。在一家公司，想象你有一个季度"安全评审"，安全团队会像国税局审计员一样降临在工程团队身上。他们会一次又一次地发现同样的问题：

  • 未验证的输入（标记为SEC-1234的JIRA工单）

  • 缺失的访问控制（总是标记为红色的"关键"）

  • 未加密的数据存储（分配CVSS评分8.9）

  • 硬编码凭证（因为"合规风险！"升级到CIO）

每次，这些都会进入"安全积压"——一个特殊的炼狱，问题按神秘的"风险评分"排名，并与功能工作一起优先排序。他们会有特殊的"冲刺规划"会议，安全团队会乞求工程师时间，用"这是我们渗透测试的P0发现！"这样的声明恳求。

与此同时，当网站因为糟糕的错误处理或糟糕的缓存失效而宕机时，没有人需要特殊的"可靠性评分"来优先处理修复。它只是得到了处理，因为它显然坏了。

今天预防明天的工程债务

考虑威胁建模——安全人员一直在传播的一种实践。威胁建模到底是什么？它是预防性工程。

当我们对新功能进行威胁建模时，我们不应该真正将其作为安全工作来做。而是将其作为工程设计工作，与合法用例一起考虑对抗性用例，思考当系统以其创建者没有预期的方式使用时可能如何失败。

这与考虑系统在负载下可能如何失败，或当依赖关系宕机时，或当用户犯错误时，并没有根本不同。这只是考虑更广泛场景集的良好工程。

让我给你一个具体的例子。我合作的一个团队正在构建一个新的文件共享功能。在威胁建模期间，我们确定文件可能包含恶意软件，用户可能上传可能导致存储问题的极大文件，系统需要控制来防止对共享文件的未授权访问。

传统思维会将这些标记为"安全关注点"（稍后解决）。安全团队会创建SEC-4567（严重：恶意软件上传），SEC-4568（高危：存储DoS）和SEC-4569（严重：水平越权）。这些工单会进入看板，然后搁置，直到下一次安全评审，团队会因为没有解决它们而被责备。

但是剥离Security Theater，你有什么？只是需要构建的工程需求：

  • 文件类型限制是一个功能

  • 文件大小限制是一个功能

  • 适当的访问控制是一个功能

这些从一开始就应该是ENG-1234、ENG-1235和ENG-1236——冲刺积压中的常规工程任务。

通过威胁建模早期识别这些需求，我们防止了未来的安全特定债务。团队将这些控制作为初始实现的一部分构建，而不是以10倍的成本稍后改装它们。但最重要的是，我们停止将它们视为奇异的"安全功能"，只是让它们成为普通的工程工单。

检测规则仪表化

另一个例子是检测规则。在许多组织中，安全团队编写在SIEM或其他监控系统中的检测规则，与应用程序遥测和监控分离。这些检测被导入完全不同的工作流系统，由不同的团队配备，并用不同的指标跟踪。

但安全检测规则到底是什么？它只是业务流程和应用程序行为的仪表化。

例如，为了检测潜在的欺诈交易，安全团队会在Splunk中编写关联规则来识别可疑模式，如：

  • 多次失败登录尝试，然后成功登录并立即转账

  • 来自异常位置的交易

  • 刚好低于报告阈值的交易金额

当这些触发时，它们会去SOC，SOC会做初始分类，然后通过令人沮丧的Slack频道、电子邮件和工单系统传输链升级给工程团队。会有无休止的"交接会议"，安全会向工程团队解释问题（工程团队不可避免地会反击"那是误报"）。

但这些不是"安全检测"——它们是应该从一开始就构建到应用程序中的业务逻辑验证，或者SOC分析师直到现在才真正意识到的行为。检测规则只是对不完整工程工作的补偿控制。它们应该是馈送到监控性能问题或崩溃的相同告警基础设施的常规应用程序日志。

当重新构建这些作为业务需求而不是安全控制时，工程团队将开始直接将它们构建到应用程序中。失败登录限制、基于位置的风险评分，最终将成为产品功能，而不是事后的安全创可贴。当可疑事情发生时，响应系统/应用程序中断的同一个值班工程师会收到告警，因为猜猜怎么着？这都只是系统行为。

解决得越晚，成本越高

像所有技术债务一样，安全问题等待的时间越长，修复成本就越高。

在初始开发期间实现需要15分钟的缺失输入验证，一旦代码进入生产，可能需要数小时来改装，特别是如果它被其他组件无意中依赖。如果验证差距导致数据泄露？现在你可能面临数百万的成本、事件响应流程、事后会议、根本原因分析和安全改进计划，这些将消耗你整个工程组织数月。

但是像Log4Shell这样的依赖漏洞呢？它们不是不同的吗？不。它们只是第三方代码中的bug——与任何其他糟糕依赖没有不同。

快速修补的团队在安全方面并不更好。他们在工程方面更好。他们有可靠的依赖管理、清晰的组件清单和对测试的信心。

那些挣扎的团队在安全方面没有失败——他们在基本软件质量方面失败了。他们的技术债务只是恰好披着安全标签出现。

这就是为什么Log4Shell在每个厂商演示中都会出现。不是因为它不可能修复，而是因为安全遵循了一个独立的、破碎的流程，与工程其余部分的运作方式脱节。

如何将安全视为工程工作

那么我们如何执行这种观点？这里有一些实际的转变：

1. 停止将安全需求与功能需求分离

安全特性就是功能特性。身份验证、授权、输入验证、输出编码——这些不是独立于应用程序功能的；它们定义了应用程序如何运作。不应该有"安全需求"这样的东西——只有包含安全特性的产品需求。

2. 使威胁建模成为正常的设计活动

就像你不会在不考虑性能或可靠性的情况下设计系统一样，不要在不考虑安全的情况下设计系统。这不是单独的"安全评审"——这只是彻底的工程设计。你的架构决策记录应该默认包含安全考虑，而不是作为特殊附录。

3. 将安全仪表化构建到你的可观测性栈中

你的应用程序的安全遥测不应该生活在由单独团队管理的单独系统中。它应该是你统一可观测性方法的一部分，给你系统行为的完整图像。不应该有单独的安全仪表板，只有包含安全信号与性能、可靠性和业务指标的仪表板。

4. 像测量其他技术债务一样测量安全债务

使用你用来跟踪其他形式技术债务的相同机制跟踪安全问题。测量它们对速度、可靠性和维护成本的影响。停止使用没有人理解的奇异风险评分框架。如果你必须有严重性级别，使用你用于常规bug的相同级别：P0-P4或你组织的任何标准。

5. 停止为"安全事件"遵循单独的IR流程

当有违规或漏洞利用时，不要将其标记为"安全事件"——它只是一个事件。运行你用于中断或数据损坏问题的相同事件响应流程。使用相同的事后模板、相同的严重性分类和相同的修复跟踪。

回报

当你停止将安全视为独立的、特殊的东西时，安全实际上变得更好。

  • 它被构建到正常的工程工作流中，而不是后来螺栓连接。

  • 它出现在设计决策中，而不是发布后。

  • 它生活在相同的可观测性栈中，而不是在孤立的SOC中。

最重要的是，安全和工程之间的墙壁开始消解。安全人员停止成为"门口的审计员"，开始成为工程合作伙伴。工程师停止等待"安全签字"，开始默认设计安全。

这就是真正的左移看起来的样子。 不是你IDE中的另一个插件。 不是你管道中的另一个扫描器。 这是工程从一开始就拥有安全。

当组织做出这种转变时，他们不仅获得更好的安全——他们更快地发布更好的软件。因为好的安全就是好的工程。

技术债务就是技术债务，无论你是否标记为"安全"。 唯一的问题是你是现在偿还它，还是稍后——带着利息。

行动号召：拆除安全孤岛

所以这是我对双方的挑战：

对安全专业人员： 停止假装你是特殊的。你不是魔法师或战士——你是恰好专注于特定类别问题的工程师。放弃FUD、专业术语、"天塌了"的修辞。开始说工程的语言：需求、缺陷、bug、测试覆盖率。先是工程师，其次是安全专家。

对工程领导： 停止将安全视为别人的问题。安全工作就是工程工作，句号。它属于你的积压、你的冲刺、你的代码评审、你的设计文档和你的架构决策。如果你在跟踪技术债务但不跟踪安全债务，你实际上没有跟踪所有债务。

安全不是魔法。它不是合规。它不是检查清单。它就是工程。我们越早接受这一点，我们就能越早开始构建更安全的系统，而不需要所有的戏剧、孤岛和相互指责，这些已经困扰我们行业太久了。

我不是建议我们不需要安全专业知识——我们绝对需要。但我们需要这种专业知识嵌入到我们的工程流程中，而不是隔离到自己的特殊王国，有特殊语言、特殊工具和特殊工作流。

因为我们花在维护安全和工程之间人为边界的每一秒，都是我们没有花在实际关注问题上的一秒。我开始相信最好的安全项目根本不像安全项目。它们看起来像工程卓越项目，自然地将安全作为质量的一个方面纳入其中。

原文链接

https://srajangupta.substack.com/p/security-is-just-engineering-tech

声明：本文来自RedTeam，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。