Jeff Williams，OWASP创始人和Contrast Security创始人兼CTO – 采访系列

Jeff Williams，OWASP创始人和Contrast Security创始人兼CTO，被广泛认为是现代应用程序安全领域最具影响力的专家之一。过去几十年中，他帮助塑造了组织对安全软件开发、漏洞管理和运行时应用程序保护的方法。威廉姆斯在OWASP从一个小型志愿者倡议发展成为一个全球公认的非营利性安全基金会中发挥了核心作用，为标志性的项目做出了贡献，例如OWASP Top Ten、WebGoat、ESAPI、ASVS和XSS防御备忘录。在2014年创立Contrast Security之前，他还创立了Aspect Security，这是最早专门从事应用程序安全咨询、培训、渗透测试和企业组织安全开发实践的公司之一。

OWASP是一个专注于通过开源项目、全球社区合作、教育和行业标准提高软件安全性的非营利性基金会。该组织成立于2001年，已成为应用程序安全领域最重要的权威之一，拥有数百个本地分会、数千名贡献者和被全球开发人员、安全专业人员、企业和政府广泛采用的资源。OWASP最著名的项目包括OWASP Top Ten，该项目确定了最关键的Web应用程序安全风险，以及众多安全框架、测试工具、文档项目和培训计划。该组织遵循供应商中立的理念，使其教育资源和安全指导免费提供给全球技术社区。

Contrast Security是一家专注于保护软件免受内部运行应用程序攻击的应用程序安全公司，而不是仅仅依赖外部扫描工具。该公司的平台使用运行时仪表技术提供对漏洞、攻击、API、开源依赖项和应用程序行为的实时可见性，涵盖开发和生产环境。其产品涵盖交互式应用程序安全测试（IAST）、应用程序检测和响应（ADR）、运行时应用程序自我保护（RASP）和软件组成分析等领域。Contrast Security将自己定位为将安全性直接集成到现代DevSecOps工作流中，使开发人员、应用程序安全团队和安全运营团队能够更快速地识别和修复漏洞，同时保持快速的软件交付周期。

在帮助塑造现代应用程序安全的OWASP工作之后，您发现了什么行业空白而创立了Contrast Security？最初的设想如何随着安全挑战的演变而演变？

行业被理论静态发现淹没，无法专注于真正重要的问题。安全团队使用扫描器生成大量待处理漏洞，但不知道哪些漏洞可以被利用、在生产环境中被攻击。我们创立Contrast的想法很简单：安全决策应该来自直接观察实际运行的应用程序，而不是从外部猜测。

最终，我希望行业能够发展到不再陷入发现问题、修复问题、再发现问题的无限循环中。我希望我们能够开始创建具有强大安全架构的软件，并具有合理的防御机制来应对预期的威胁。运行时安全和人工智能的结合具有潜力，但我们距离实现这一目标还很远。

您曾经提到“神话级漏洞”的出现。什么定义了这一新类别的风险，为什么它们对传统安全工具如此难以检测？

神话级漏洞是现代软件栈复杂性所致的缺陷。框架行为、依赖项和架构模式之间的交互作用如此复杂，以至于开发人员往往无法完全理解。传统工具仍然针对相对简单的已知模式和可观察事件进行优化。神话级漏洞通常需要对应用程序行为、执行流程和运行时上下文有更深入的理解。

为什么整个漏洞类别在现代安全运营中心（SOC）环境中无法产生警报，这又揭示了安全团队当前如何衡量风险？

大多数SOC都是围绕可观察事件构建的：日志、签名、网络流量、端点活动。但是许多应用程序层攻击永远不会在这些系统中产生有意义的信号。开发人员不知道有漏洞，也没有添加任何日志记录来揭示利用。因此，大多数应用程序利用在日志中是完全不可见的。SOC团队只能响应他们可以看到的内容。因此，随着应用程序和API层变得越来越重要，必须确保我们用安全传感器来检测和报告异常行为来仪表化它。

现代应用程序架构，如微服务、API和无服务器系统，已经迅速演变。这些架构在哪里超出了当前的基于检测的安全方法？

这些架构摧毁了旧的周边模型。请求现在跨越数十个服务、短暂函数、API、队列和第三方依赖项才能完成一个事务。大多数检测系统仍然看到片段，而不是完整的执行路径。它们可以检查数据包或日志，但无法理解意图、数据流或是否执行了危险代码。安全性是关于上下文的，因此我们需要构建应用程序基础设施的数字孪生模型，以便我们（或AI代理）能够推理我们看到的内容。

OWASP Top Ten继续强调不安全的设计和易受攻击的组件等问题。为什么这些风险仍然存在，尽管人们已经意识到并且有了工具？

意识并不能解决激励或复杂性问题。大多数组织仍然通过扫描量、票据关闭或合规性清单来衡量成功，而不是实际暴露度减少。

同时，软件供应链在规模上爆炸式增长。开发人员从成千上万个他们没有编写也没有评估其安全性的组件中组装应用程序。安全团队被理论风险的_triage_淹没，无法专注于真正重要的1-2％。没有运行时证据，优先级会失效。而且随着强大的AI模型和_harness_的出现，数量正在呈指数级增加。

组织应该如何重新思考对日志和警报的依赖，当一些最关键的漏洞没有可观察的信号时？

日志是应用程序选择报告的证据，而不是实际发生的事情的证据。这是一个危险的区别。组织需要从间接观察转变为直接观察。安全系统不应该希望利用会创建可检测的工件，而应该在运行时识别易受攻击的行为和利用行为。如果执行了危险代码，系统应该立即知道——无论是否存在日志条目。

您提倡运行时可见性作为解决方案。真正的运行时可见性是什么样的，它如何改变安全团队的日常运营？

真正的运行时可见性意味着了解应用程序在生产环境中实际上正在做什么：哪些路由被暴露，哪些库处于活动状态，敏感数据流向哪里，哪些代码被执行，以及攻击是否到达了易受攻击的功能。从操作角度来看，它将安全性从反应性狩猎练习转变为精确的学科。团队停止追逐大量的漏洞库存，开始关注那些可达、关键且正在积极针对的暴露。这种方法大大提高了信号与噪音的比率和响应速度。平均而言，只有38％的开源库被打包到应用程序中并加载到内存中执行。并非所有代码都被使用。因此，运行时安全性使我们能够专注于实际运行的代码，而不是应用程序附带的未使用库和函数。

基于仪表的安全性与传统方法（如SAST、DAST或周边监控）相比，在有效性和可扩展性方面如何？

传统工具从外部推断风险。仪表观察到现实，通过观察实际运行的代码。仪表可以看到实际的执行路径、框架行为、身份验证上下文、数据流和利用成功的实时情况。它消除了大量的假阳性，并暴露了周边工具完全遗漏的漏洞。在规模上，这种精度变得至关重要。组织无法再手动_triage_数百万个理论发现。运行时证据正在成为唯一可持续的过滤器。运行时工作在实时，因此它比扫描和_triage_更适合开发和CI/CD管道。运行时是连续的，因此您不仅限于特定时间点的安全性快照。

随着AI系统和自主应用程序变得更加普遍，这些不可见的漏洞是否变得更加危险，团队应该如何准备？

AI使不可见的漏洞变得更加危险，因为它加速了问题的两方面。开发人员正在更快地生成软件，攻击者也正在更快地找到和利用弱点。但大多数安全计划仍然依赖于无法以AI速度运行的人工流程。团队应该通过两种方式来准备。首先，建立更强大的运行时防御，以便在生产环境中检测、阻止和包含攻击，同时修复漏洞。这为组织提供了空中掩护。其次，使用AI和自动化来编写更安全的代码——具有更好的设计、测试、审查和验证。否则，我们只是以比我们能够管理的速度更快地创建风险。

如果您正在为现代安全运营中心（SOC）领导者提供建议，他们应该采取哪些具体步骤来关闭可见性差距，防止其导致重大漏洞？

首先，接受周边遥测数据不足以满足现代应用程序安全性的事实。事实上，许多应用程序和API攻击在周边无法看到或阻止。SOC需要在运行应用程序中看到内部，而不仅仅是主机应用程序的基础设施。其次，优先考虑运行时证据而不是理论发现。专注于在活动代码中、攻击路径中和生产环境中实际执行的暴露服务。最后，统一应用程序安全性和检测工程。未来SOC不能将应用程序视为不透明的黑盒。应用程序现在是主要的攻击面，需要在运行时具有一级可见性。

感谢这次精彩的采访，希望了解更多的读者可以访问OWASP或Contrast Security。