引言

作为应用安全或产品安全（更广泛地说）领域的从业者，我们身处一个理论遭遇现实的奇妙地带，而两者往往无法如我们所愿完美契合。在我的应用安全从业经历中，我持续观察到一个现象：行业讨论应用安全的方式与我们日常实践之间存在着持久的脱节。

有效的应用安全/产品安全需要将抽象的安全概念回归到第一性原理和现实场景。然而，在会议上听到的最新安全项目成果、工具改进或AI驱动的漏洞检测/修复方案，与我们每日站会中实际面对的情况——上下文断层、集成难题以及工程速度与安全严谨性之间永无止境的平衡挑战——两者之间横亘着巨大的鸿沟。

我逐渐意识到这不仅仅是沟通问题。这是当前供应商分类与企业实际安全需求之间的根本性错配。我们围绕理论安全模型构建了整个生态系统，但这些模型与现代软件组织的实际运作方式完全脱节。

那么有效的产品安全究竟应该是什么样？根据我在不同组织环境中的经验，以及我们最终体现的各种原型角色——无论是管理多样化复杂组合的协调者、创建可扩展解决方案的构建者、深耕特定领域的专家，还是处理紧急情况的快速响应者——关键不在于拥有完美的工具链或最全面的流程。有效的应用安全要立足于组织现实：资源限制、速度要求、遗留技术债务，以及工程师平均18-24个月就会流动的事实。

现在越来越需要构建开发者真正愿意使用的安全系统，而非他们被迫忍受的安全流程。说实话，我们大多数人仍在实践中不断摸索这个平衡点。

理论与实践之间的差距体现在我们如何定义问题、解决方案中忽视实际运营约束的盲点，以及市场机制对解决错误问题的奖励上。除非直面这种脱节，我们将不断让"解决方案"适应现实——而我们真正需要的是从一开始就保持一致性。

应用安全/产品安全作为问题领域

大多数供应商的宣传都从他们声称能解决的问题开始："我们检测代码中的漏洞！""我们保护您的供应链安全！"或者最近更流行的——"AI驱动的XYZ解决方案"。

正如Kane Narraway最近关于系统性预防挑战的文章所述，这种动态在应用安全工作流程中表现得尤为突出。关键在于——这些对问题的定义往往忽略了我们应用安全从业者日常实际面临的困境。以下是我通过第一性原理（而非供应商营销话术）观察到的各组织中真实问题领域的浮现方式。

问题领域1：信息不对称的挑战

第一个基本安全问题是关于在缺乏对系统、业务逻辑和风险的充分了解情况下做出明智的安全决策。作为实践者，一个典型的例子是收到服务团队利益相关者在Slack上的询问："可以把OAuth令牌存储在localStorage里吗？需要在本周末前上线。"看似简单，但要回答这个问题，我需要了解系统的威胁模型、令牌敏感度、会话处理方式、用户权限边界以及下游数据流。简而言之，我需要本该在提问前就掌握的所有背景信息。

多数供应商将其定位为"可见性"问题，并推销资产发现工具、依赖项扫描器或架构映射解决方案。这些工具虽有一定帮助，却忽略了核心矛盾：应用安全团队需要的是辅助决策的上下文情报，而非单纯的存在性数据。我们不需要更多数据，而是需要能加速优质决策的上下文情报。最典型的例子就是SAST扫描器标记出代码库中10个SQL注入漏洞时，它输出的只是潜在漏洞位置列表。而实际需要的上下文情报应当能指出：支付处理端点中2个可直接访问客户PII数据库的漏洞需立即处理，内部管理功能中5个仅读取配置数据的漏洞可延至下个迭代周期，而3个位于极少执行的错误处理路径中的漏洞则可降级为资源允许时处理。

这就引出了一个根本性问题："根据我的威胁模型、业务关键性和部署时间表，这些发现中哪些真正重要？"检测与决策之间的鸿沟仍然巨大，因为大多数情境智能仍存在于经验丰富的从业者头脑中，而非可扩展的工具里。

问题领域2：速度与严谨的张力

第二个需要平衡的是彻底的安全评估与开发速度要求之间的关系。产品团队希望安全决策不会拖慢开发周期，而有意义的应用安全评估则需要理解业务逻辑、审查架构选择，并经常测试实现细节。你被夹在这两个难以兼顾的标准之间：既要快速给出精确答案，又要建立使这些答案有意义的情境基础。

根据我在不同组织速度和团队结构中的工作经验，这种张力表现方式各异但始终存在。最终你只能基于模式识别提供快速评估而非全面分析，而当这些快速评估遗漏风险时，你就要承担相应责任。

"左移"运动将其视为工具问题——在开发流程早期实现安全测试自动化。"开发者优先"的安全趋势则将其视为用户体验问题——让安全工具更便于开发者使用。这两种方法都认识到安全必须融入开发工作流，因而有所帮助。然而，其假设都围绕工具部署或界面设计这一核心问题，而非速度与彻底性之间的根本矛盾。

问题领域3：集成复杂性挑战

下一个问题领域是如何在现实资源限制下，让工具、人员和流程（任何组织应用安全成功的三要素）协同工作的复杂平衡。我们经常看到这样的场景：有SAST工具、SCA扫描器、DAST设置和CSPM监控。每个供应商都承诺他们的工具能解决特定漏洞类别，但应用安全团队却要花费数月时间进行集成工作，编写自定义脚本，并进行持续维护（那臭名昭著且无人感激的"保持系统运转"工作）才能让所有工具真正协同工作。供应商推销时说"只需添加这个工具"，但现实是你现在需要运行一个小型IT运维团队才能保持安全技术栈的正常运转。

我们也要正视资源问题——大多数人其实都处于研究者所称的"安全贫困线"以下。零利率时代结束后的预算限制使得安全工具采购变得困难，而安全工作正与功能开发直接争夺工程资源。你试图在供应商演示中鲜少提及的种种限制下，建立一套全面的安全防护体系。

随着我在资源受限环境中的工作经历增多，以及与业内同行交流经验，我逐渐认识到成功不在于拥有完美的工具组合，而在于做出明智的权衡，构建真正适应当前运营现实的解决方案。大多数供应商将这个问题拆解为："平台整合"（从单一供应商采购所有工具）、"流程编排"（通过API连接工具）或"自动化"（减少人工操作）。这种分类方式通过承认工具泛滥的现实而具有实际意义。

然而，这些供应商方案忽略了一个根本问题：它们完全在错误的抽象层级上解决问题。以下是实际映射到从业者需求时，应用安全工具领域的真实情况：

这揭示了集成复杂性挑战持续存在的原因。供应商正大力投资于从业者操作痛感最少的底层架构，却几乎完全忽视了团队在日常决策和组织扩展中最为挣扎的上层架构。前三层架构代表了从业者消耗大部分认知精力的领域，但由于这些领域难以产品化，它们至今仍基本未被解决。

问题领域4：组织扩展困境

如何在扩展安全团队规模的同时，避免让安全从业者沦为组织粘合剂？随着组织规模扩大，如何构建应用安全团队并分配职责而不丧失效率，是另一个值得强调的问题。

我在不同组织环境中观察到的一个现象是，尽管职位名称同为"应用安全/产品安全工程师"，实际职责却因组织约束条件而存在根本性差异。随着经验积累，从业者往往需要叠加不同角色原型，根据组织需求而非安全效果最优解，在不同基础技能要求之间不断切换。

大多数供应商假设团队结构和职责是统一的，他们为通用的应用/产品安全团队构建解决方案。即使承认组织差异，通常也只是围绕公司规模（企业级与初创公司）而非运营模式或角色类型。这种做法造成的系统性错配——安全工作的实际开展方式与供应商解决方案定位之间的脱节——弊大于利。不同的组织类型需要根本不同的工具方法，但市场大多忽视了这些结构性现实。思考一个鲜明现实：组织环境如何塑造工具需求。高速运转的组织全天候持续部署代码，他们抵触那些为部署流程增加摩擦的安全工具——他们需要快速、故障安全的扫描方案以匹配其发布速度。而受严格监管的企业按照结构化发布周期运作，他们恰恰需要相反的特性：完整的审计追踪、详尽的合规文档以及支持其重量级变更管理的工具。

一位负责协调多个产品团队安全的AppSec工程师正淹没在各团队警报的噪音中——他们需要能穿透混乱、呈现真实且相关组织风险的高层仪表盘。而嵌入单个产品团队工作流的AppSec工程师则需要能说团队语言的专业工具——不是通用安全平台，而是理解其特定代码库与业务逻辑的解决方案。

问题领域5：门禁式与护栏式理念的错配

用刹车保护不了速度，你需要的是方向盘。作为实践者，北极星原则始终是提供安全控制措施来赋能而非限制开发速度。

在高节奏工作环境中，我深刻体会到关卡式安全机制实际上与我们追求的目标背道而驰。当团队每天需要多次部署代码时，要求他们暂停进行安全评估会打断心流状态、引入延迟，并在安全团队与工程团队之间制造对立关系。大多数安全工具仍基于关卡式工作流程设计，要求团队停下等待安全审批。"DevSecOps"运动虽然意识到这种矛盾，但往往只关注工具集成而非工作流理念革新。持续安全方法认识到需要实时监控，但未能从根本上区分"关卡"与"护栏"的差异。分类方法通过承认安全必须融入开发和CI/CD流程而有所助益，但其局限性在于将之视为自动化问题，而非认识到需要根本不同的安全控制模型——这种模型应将持续指导嵌入开发流程，让开发者保持心流状态，而非要求他们定期停留在安全检查点。

重大解决方案缺口

话虽如此，让我们更深入地审视应用安全解决方案领域中真实存在的缺口。这些正是从业者痛点尖锐、但市场却未能提供有效缓解方案的领域。这些缺口揭示了安全行业运作的一个重要现象：那些无法被简单归类到现有厂商产品矩阵中的问题，往往会被忽视或流于表面解决——即便它们恰恰代表着从业者日常面临的最严峻挑战。

这些差距之所以特别引人关注，在于LLMs本有望解决其中诸多挑战，但令人惊讶的是，在它们最能发挥价值的领域，实际验证成功的应用案例却极为有限。当前安全工具中的人工智能集成主要聚焦于检测和分类任务，而非从业者最为困扰的推理与决策支持难题。

情境感知决策支持缺口

当今安全工具领域最显著的缺口集中在决策支持而非数据收集方面。现有安全工具在信息收集方面表现出色：漏洞扫描器识别潜在问题，资产发现工具绘制基础设施图谱，合规平台追踪策略遵循情况等。

试想安全从业者实际需要做出安全决策时的场景。例如，当开发人员询问实施某个OAuth流程是否会带来不可接受的风险时，要正确回答这个问题，安全从业者不能仅停留在技术实现层面。这涉及业务背景、现有威胁模型、组织风险承受能力以及潜在运营影响等多重因素。决策关键不在于实现是否存在漏洞，而在于现有漏洞在特定情境下是否可被接受。LLMs能够基于架构模式、业务风险承受能力和合规要求，生成具有上下文感知的修复建议。它们可以充当安全副驾驶，帮助从业者处理诸如"根据我们的风险承受能力和部署时间表，应该立即修复这个漏洞还是推迟到下个版本？"这类问题。此外，AI还能通过帮助从业者基于不完整的系统架构图或高层应用描述，推理可能的攻击路径和缓解措施，从而增强威胁建模能力。 无论如何，这一切都需要深刻理解组织动态以及实际企业中如何做出权衡取舍。这很难产品化，尤其是在大规模应用时——相比之下，持续暴露更多问题并称之为"洞察"要容易得多。

工作流原生安全鸿沟

第二大差距源于行业倾向于构建通用安全平台而非针对特定工作流程的工具。大多数安全供应商通过创建号称适用于任何组织中任何安全团队的解决方案来追求广泛市场吸引力。这种一刀切的做法忽视了安全工作的现实差异——这些差异会因组织结构、团队规模和运营环境而显著变化。

试想不同安全角色在日常工作流程中的显著差异。负责跨多个产品团队安全协调的统筹者需要协同工具、全局可视性和一致性追踪能力。而嵌入单一产品团队的专项专家则需深度融入开发流程、精通系统细节并建立快速反馈机制。至于处理紧急安全事件的快速响应者，他们需要高效的分类处置能力、直达决策层的快速通道以及精简的升级路径。这些角色本质上有着不同的信息需求、成功标准和操作限制。然而，多数安全工具仍将其视为通用"应用安全工程师"的变体，最终导致软件看似普适却无法真正满足任何角色的卓越需求。

AI驱动的工具可以根据使用团队的具体工作流程模式，定制化处理代码审查、事件通知和修复方案。然而目前大多数AI安全工具提供的都是通用输出，并不考虑用户角色或组织背景的差异。

资源约束感知型解决方案的缺口

当前供应商格局中最显著的缺口，或许是几乎完全缺乏专为资源受限环境设计的解决方案。大多数安全工具的构建前提是假设企业拥有专职安全团队、充足预算以及实施和维护复杂安全计划的操作能力。这种假设与许多企业的现实情况存在根本性错配——这些企业资源不足以实施全面的安全计划、缺乏维护复杂工具的人员，且存在制约其大举投资安全基础设施的优先事项竞争。

对于在这些限制条件下运作的团队而言，真正的挑战并非寻找功能更丰富的安全工具，而是寻求能以最小运营开销实现最大安全效益的解决方案。这意味着需要打破"安全会拖慢开发速度"的固有认知。那些优先考虑操作简便性、瞄准资源受限团队、并能无缝集成到现有工作流（开发、CI/CD、项目管理、沟通及监控观测）中的解决方案，将在提供既能保障安全又不制约开发速度的控制措施方面占据显著优势。

结论

应用安全理论与实践的差距不仅是一个令人困扰的现实，更是我们领域面临的核心挑战。安全防护的失效并非因为缺乏工具、框架或最佳实践，而是因为大多数解决方案忽视了实际工作中混乱、高速运转且资源受限的环境。作为应用安全从业者，我们面临的根本性挑战并非技术问题，而是理念问题。弥合这一鸿沟需要的不仅是"左移"策略或购买更智能的扫描器，它要求我们的安全理念、必须支持的工作流程以及所处的现实环境之间实现深度契合。

这对实践者意味着什么？我们需要保持务实态度，同时推动行业朝着真正解决日常问题的方案迈进。这意味着诚实地评估哪些方法有效、哪些无效，建立内部能力以填补供应商尚未解决的空白，并持续倡导那些能够赋能而非限制软件开发实践的安全方案——正是这些实践推动着现代商业的成功。

对于安全领域的创始人和产品领导者而言，这种现状既带来挑战也孕育机遇。当前融资环境不仅要求创新技术，更需要从早期阶段就展现出明确的市场吸引力和运营可持续性。

市场上充斥着单点解决方案，而成功的网络安全公司（尤其是应用安全领域）将是那些能同时处理我们讨论的抽象堆栈多个层级，同时为实践者简化产品方案的企业。毕竟，任何成功初创企业的核心都在于解决客户实际问题和创造价值。这意味着要解决我们强调的三大痛点——情境化决策、工作流整合和资源限制。

只有当你的产品能解决客户正在经历的具体痛点，并完美融入他们现有工作流程时，客户才会采用。如果你的解决方案难以使用或要求他们改变工作方式，无论技术多么先进，他们都会弃之不用。此外，定期与客户沟通对于紧跟从业者不断变化的需求至关重要；这些对话不能仅限于功能需求，而应真正共情倾听，理解从业者日常面临的挫折和限制。

建立持久客户关系需要打造让用户感到被倾听和重视的支持体验，通过快速解决问题来培养用户忠诚度，最终将普通用户转化为品牌拥护者。随着企业安全需求日趋复杂，构建可随客户需求扩展的解决方案才能确保长期成功。

应用安全领域理论与实践之间的鸿沟不会自行消失。只有明确承认这一差距并系统性地加以解决，我们才能在每天面对的组织现实中建立起真正有效的安全防护体系。

原文链接：

https://ventureinsecurity.net/p/appsecprodsecs-reality-gap-why-theory

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