Shannon McWilliams，Orca Security 全球分销负责人——访谈系列

Shannon McWilliams是Orca Security的全球分销负责人，工作范围涵盖公司的合作伙伴生态系统及支持这一生态的工具。他曾创办一家软件开发公司，积累了将业务需求转化为应用程序的经验。近期，他使用AI开发工具搭建了Orca合作伙伴成功平台的早期版本，并与安全团队合作，推动项目从周末原型逐步迈向可投入生产的系统。

Orca Security提供云安全平台，帮助组织发现资产、识别并确定风险优先级，以及保护云环境。平台功能涵盖漏洞、错误配置、身份与权限、敏感数据和AI安全等领域。在本次访谈中，McWilliams谈到了AI如何让业务用户能够构建软件、为何已能正常运行的应用仍需要接受独立的安全审查，以及持续发现、最小权限和人工监督如何帮助企业管理这种新的开发模式。

您加入Orca Security担任全球分销负责人后，仅仅几个月就用AI亲自搭建了一个新的合作伙伴平台。您最初想解决什么问题？这个项目又是在什么时候从一次实验发展成Orca真正可以投入生产的系统的？

我加入Orca时，交给我的任务之一是审视整体的合作伙伴体验。当时我们使用的是第三方平台，但我发现有机会为合作伙伴打造更现代、更精简的解决方案。我有一些应用开发经验，但自己并不是开发人员。那年夏天稍早些时候，我曾使用一家第三方应用生成平台提供商的平台开发面向消费者的应用，因此决定尝试用AI看看自己能构建出什么。

一个周末下来，我就做出了一个基础的初始版本，后来它发展成我们的合作伙伴成功平台。它的功能超出了我在传统合作伙伴门户中见到的范围，包括理想客户匹配和交易辅导等AI驱动功能。我们在平台中增加了更多应用，例如认证进度跟踪和AI生成测验，还将整个合作伙伴认证流程设计成游戏化体验，随后开始与我们的Salesforce平台同步数据。转折点出现在CEO看到初始版本并意识到它的潜力时。也正是在那时，我们从实验阶段转向思考：要让这样的产品真正安全并达到生产就绪状态，究竟需要做些什么。我们的安全团队随即参与进来，我开始与Dudi Peretz密切合作，为环境提供安全保障，最终还请外部机构对这项工作进行了独立验证。

您此前创办过一家软件开发公司，因此了解传统的应用开发方式。通过自然语言和AI来构建软件，与管理开发人员相比有何不同？您自身的领域专业知识在哪些方面仍然最为重要？

最大的区别在于速度。传统软件开发通常要经历多个步骤：从产生想法，到将其转化为技术需求，再由开发人员构建，最后对结果进行迭代。有了AI，我只需描述自己的需求，就能看到应用逐步成形，并几乎立即继续完善。迭代只需几分钟，而不必花几天时间开会，与开发人员明确理想的用户界面以及实现功能所需的所有数据库映射。借助AI开发，只需一段2句的提示词，无须开上2天的会。

但这并不意味着专业知识不再重要，而是专业知识发挥作用的地方发生了变化。AI可以大幅降低构建应用的技术门槛，但负责引导AI的人仍需理解自己要解决的问题、怎样的体验才有用，以及应用最终需要为业务实现什么目标。最令我惊讶的是，从一个想法到做出能运行的东西，所需时间竟然可以这么短。过去可能要花几周完成的任务，例如分析数据，如今有可能一天之内就能完成。

Orca曾将合作伙伴平台的首个可运行版本描述为您在一个周末内搭建的成果。AI大幅加快了哪些环节？而在构建可投入生产的应用时，哪些部分仍比最初预想的更困难？

AI大幅缩短了从想法到可运行应用之间的距离。我可以在一个周末内构建出传统开发流程需要长得多的时间才能完成的功能，还能以极快的速度持续添加和修改功能。这种速度既令人惊叹，也有点让人害怕。

AI并没有免去让应用达到安全生产要求所需的所有工作。一旦我们决定要把这个项目变成真正的产品，安全团队就需要评估环境、解决安全问题，并确保应用得到适当保护。最终，我们还引入了一家外部机构，作为额外的验证环节。因此，AI让构建过程快得惊人，但“能够运行”和“可以在企业环境中安全运行”仍是两个截然不同的门槛。

AI开发平台自身的安全工具显示应用是安全的，但Orca随后进行的审查发现了涉及权限和数据访问的问题。这段经历让你如何看待业务用户应在多大程度上信任AI开发平台提供的安全保证？

这大概是我从这段经历中得到的最大教训之一。平台自身具备安全扫描功能，在我开发应用时提供了有用的基准。但与我们的安全团队一起走完审查流程，让我认识到再增加一层审查有多重要，尤其是在权限和数据访问等方面。这让我更加确信，内置安全工具是开发流程中的重要组成部分，但若能结合专职安全团队所具备的更深入背景知识和专业经验，效果才会最好。

这一点尤其重要，因为如今许多能够借助AI构建应用的人并非安全专家。他们可能不知道该问哪些问题、哪些权限范围过宽，或者哪些配置可能导致数据暴露。开发平台告知你应用是安全的，不能成为流程的终点。在应用发布或连接到敏感的企业系统之前，仍然需要进行全面的安全审查，不能只看应用是否通过了平台自身的检查。

安全团队发现漏洞后，你往往能够将这些发现反馈给AI开发环境，并在几分钟内生成修复方案。AI能否从根本上改变安全修复的方式，让它从漫长的开发周期变成构建者与安全团队之间持续不断的对话？

这是最令人振奋的可能性之一。Dudi和安全团队发现问题后，我可以把他们的反馈直接输入AI开发环境，并让它极快地生成修复方案。这样一来，构建应用的人与负责保障应用安全的团队之间，就有望形成紧密得多的反馈闭环。

过去，软件的构建和发布可能要花很长时间。如今，有人每天都可以进行更改并发布。安全工作也必须以同样的速度推进。我们有机会将持续安全评估纳入开发流程，从而更快地发现问题、将问题反馈给构建者、进行修复，并重新评估应用。

但修复速度变快，并不意味着我们可以降低验证标准。AI可以快速生成修复方案；安全团队仍然需要一种方法来确认修复确实解决了风险，而且没有引入新的风险。

由此打造的Partner Success Platform整合了AI助手、销售管道智能、营销活动生成和交易辅导。你是如何确定哪些工作应由AI直接处理，哪些决策应由合作伙伴或销售人员本人作出的？

对我来说，目标并不是把人从合作伙伴关系或销售流程中排除，而是利用AI帮助人们加快工作进度，更有效地利用已有信息。交易辅导就是一个很好的例子：AI可以帮助发现如何推进在销售管道中停滞已久的商机，并为相关人员提供更多背景信息或建议的下一步行动。

在我看来，关键的区别在于，AI能够迅速从不同系统中提取信息、分析其相关性，并将信息整理成用户可以据此采取行动的形式。平台应当提升合作伙伴或销售人员的工作成效，而涉及商业判断的决策仍由人来负责。目标是借助平台互动，缩短从发现交易机会到成交赢单的时间。

AI让销售、营销、财务及其他部门的员工无需经过工程团队，就能构建自己的应用。在允许这些应用连接客户数据、内部系统或云基础设施之前，应当具备哪些最低限度的安全和治理控制？

首要要求是具备可见性。组织的政策应鼓励此类探索和创新，但如果组织不知道某个应用的存在，就无法保障它的安全。因此，与其让员工把项目藏起来，不如鼓励创新，让他们更愿意公开自己的项目。在此基础上，组织需要了解应用使用了哪些身份和权限、能够访问哪些数据、与哪些第三方系统通信，以及这些权限是否确有必要。要为创新创造条件，同时建立能够支持创新者并满足安全要求的流程。

最小权限原则尤为重要。我们看到的风险之一是，应用获得的访问权限超出了实际所需。安全检查也不能只在上线前进行一次。应用可以持续变化，组织也必须能够持续重新评估应用。

传统的软件治理模式围绕工程团队、拉取请求、发布周期以及相对受控的部署流程而设计。如果业务用户现在可以持续修改和部署应用，企业软件开发生命周期需要如何改变？

根本挑战在于，开发节奏已经改变。过去，软件通常按照相对成熟的流程，经过一段时间开发并发布。借助 AI 开发工具，人们可能每天都能制作并发布新内容。在这种环境下，围绕定期检查点建立的安全与治理流程将难以满足需求。

我们需要转向持续运作、能够跟上开发周期的安全模式。这意味着要发现正在构建的内容，了解其配置方式及连接情况，在它发生变化时进行扫描，并向构建者提供可执行的反馈，让他们能够迅速采纳。解决办法不能是阻止员工使用这些工具；它们带来的生产力提升机会太重要了。挑战在于建立适当的防护措施，让创新能够安全地进行。

你曾将 AI 构建应用的兴起比作更难应对的“影子 IT”。这一代影子软件可能更具挑战性的原因是什么？组织又该如何发现安全或 IT 团队甚至可能并不知情的应用？

传统的影子 IT 通常是员工采用了未经 IT 批准的 SaaS 应用。如今的不同之处在于，员工可以自己创建应用，而且速度极快。有人可以通过个人账户构建应用，将其与第三方系统集成，甚至可能在安全团队发现它存在之前，就将它连接到企业数据。

这正是问题特别棘手的原因：应用构建变得如此容易，以至于应用数量及其变化速度很快就会超出传统治理模式的应对能力。首席信息安全官面临着同一个基本问题：如果你甚至不知道构建了什么，或它是如何配置的，又该如何保障其安全？

因此，发现应用必须成为安全策略的核心组成部分。支持创新者、鼓励他们探索，同时要求他们登记自己的项目，是实现有效发现的好方法。组织不仅需要了解代码，还需要掌握其环境中运行的应用、与这些应用相关的身份和权限、它们访问的数据，以及它们进行通信的外部系统。

展望未来几年，你认为大多数知识工作者都会借助 AI 成为某种形式的软件构建者吗？如果是，这会如何改变企业内部专业开发人员、安全团队和业务领导者的职责？

我们正迈向这样一个世界：“软件构建者”的定义将大大拓宽。AI 让那些了解业务问题、却并非传统开发人员的人，也能极快地将想法转化为可运行的应用。我亲身体验过这一点。

我不认为这会降低专业开发人员或安全团队的重要性，而是改变了需要他们发挥专长的领域。业务用户越来越能够自行构建解决方案，开发人员则可以专注于更复杂的技术问题；与此同时，安全团队必须建立相应的可视性和防护措施，让新一代构建者能够安全地创新。应用支持和维护也因此有了新的意义。“构建者”并不总是最适合担任“维护者”的人。他们带来愿景并了解业务需求，但长期支持应用仍然是更适合由 IT 部门和应用团队承担的工作。对于业务领导者而言，这带来了巨大的机遇，也带来了新的责任。如果你的团队能够创建软件，就需要将软件风险纳入业务考量，而不能只把它视为工程部门的事。

感谢你接受这次精彩的采访。希望进一步了解云安全、AI 构建应用以及如何保护企业环境的读者，请访问 Orca Security。