当大多数人想到圣克拉拉时，他们立刻会想到旧金山49人队，因为这是他们的体育场所在之处。他们可能还会想到加利福尼亚大乐园，这是一个自1970年代以来一直以来让人们娱乐的游乐园。考虑到许多科技公司总部都设在那里，包括先进微设备、英特尔和英伟达，许多人认为它是硅谷的重要组成部分。对于那些在十月底聚集在那里的几千人来说，他们会永远将其与API和AI的进展联系在一起，这要归功于2023年API世界展。
今年的活动与AI Dev World合并举办，汇集了这两个高度相关领域的从业人员。这是有道理的，因为近几年人工智能和大型学习模型LLM的最大创新都涉及将API集成到诸如OpenAI的ChatGPT和IBM Watson等服务中。似乎开发任何AI都意味着构建和维护一个API。
#APIWorld #AIDevWorld
在为期三天的活动中，有超过70位讲者。在这篇文章中无法详细介绍所有内容，但以下是一些亮点。
人工智能的未来是无法预测的
在他们的开场主题演讲“在人工智能时代的发明、创新和颠覆中航行”中，Deloitte咨询公司的Khurram Latif以及Shutterstock的Justin Hiza和Michaël Chaize阐述了他们在通过AI驱动的产品上合作的一些令人兴奋的方式，并分享了对技术未来的一些看法。
Shutterstock是一家出售预制图片、视频、音频和其他多种类型媒体的库存内容公司。多年来，他们一直在使用AI主要用于自动分类和推荐他们网站上相关内容。然而，用于个性化内容的生成式AI对于他们来说是一项新的工作，这也是他们与Deloitte合作的原因。
他们展示了一些例子，包括他们的“魔术画笔”功能，该功能允许用户根据提供的提示自定义现有内容。例如，如果有人需要戴上“符合品牌颜色”的帽子，你只需告诉AI你想要的，它就会在几秒钟内进行位置设置、光照校正和其他所有修饰。另一个例子是一个根据给定图像衍生主题的自定义文本创作者，将请求的文本定制以完美匹配图像的主题。
团队分享了在合作进行许多AI项目时学到的一些重要经验。其中最重要的一课是我们正在进入一个没有所有答案的世界。他们得出结论，即即使提前过度设计某样东西，也很可能花费很多时间试图使AI做一些它可能无法实现的事情。
行之有效的是快速进行原型设计，并尽快获取反馈。从客户的目标和目的出发，他们赋予了其工程团队以展示任何能够朝着这些目标发展的概念的能力；最终，客户是决定一个AI创新是否有价值的人。
#APIWorld正式揭幕，第一场来自#ShutterStock和Deloitte的研讨会：“在人工智能时代的发明、创新和颠覆中航行”，演讲者为Khurram Latif、Justin Hiza和Michaël Chaize。
良好的API安全性不仅仅依靠工具
API World的参与者有幸聆听了42Crunch的联合创始人和现场CTO Isabelle Mauny的三场不同的演讲。在这些演讲中，她强调了API安全的重要性以及我们如何使用最近更新的OWASP API Top 10。
在活动的第一天，她在题为“Common API Security Pitfalls: Learning from Others’ Mistakes”的演讲中，向我们展示了涉及API的几起安全事件。其中一个案例涉及一家微型啤酒厂，其API允许黑客打印数千张免费啤酒优惠券。另一个案例涉及一所大学的物理访问控制系统，其未实施任何授权，意味着任何账户都可以获得管理员权限。她总结了她所有例子中的主要问题，即API安全是事后考虑的。尽管使用通用OWASP Top 10开展我们的安全工作是好的，但我们需要在设计阶段更早地关注OWASP API Top 10所提出的问题。
之后，她深入讨论了API安全的更大的文化问题。在她的“为什么这么多API安全解决方案没有交付成功”演讲中，Isabelle表示最大的担忧之一是大多数组织都不知道他们管理多少个API。这源于对治理的缺乏、缺乏培训以及只是试图用技术工具来解决问题的倾向。良好的治理意味着建立和传达关于如何正确构建API、报告其存在以及保护它们的文档。
“Common API Security Pitfalls: Learning from Others’ Mistakes”由Isabelle Mauny在#APIWorld上演讲。
保护您的API并不是您应用程序的责任
在Akamai安全战略首席技术官Patrick Sullivan的演讲“Research Revelations: Emerging API Threats & How to Mitigate Them”中，他再次强调了利用OWASP API Top 10解决API安全的建议。他强调传统应用程序安全依赖于WAF规则和网关，而API威胁则不同。API可以用于爬取数据、帮助攻击者绘制网络图，并使拒绝服务攻击更容易执行。
安全方法的另一个重大区别在于，应用程序安全是由应用程序处理的，而应用程序不承担保护API的责任。他说，当与某人面对API漏洞时，他们最常听到的是，“我认为应用程序会解决这个问题。”尤其是在授权方面，这一说法尤为正确。传统应用程序内置了逻辑，只有在满足特定条件时才允许请求成功，而大多数API允许任何通过身份验证的人进行几乎任何调用。开发人员需要通过代码处理安全的这个方面。
Patrick Sullivan在#APIWorld上的“Research Revelations: Emerging API Threats & How to Mitigate Them”演讲。
不要只盲目遵循快乐测试路径
在他的“为什么您应该攻击自己的API”演讲中，APIsec的创始人Dan Barahona表示，API安全的一个最大问题是缺乏测试。通常会对API进行测试以确保其执行您想要的操作，但丹表示，我们往往不测试它是否执行了其设计之外的操作。我们倾向于遵循一条快乐的路径，而实际上我们需要像攻击者一样思考，并查看我们可以强制引发的意外行为。
他通过几个最近的API安全失误案例进行了讲解，其中大多数是与授权相关的逻辑错误。他提及的公司包括Coinbase，其中一位研究人员因发现一个可能导致公司崩溃的漏洞而获得了25万美元的奖励；Duolingo，通过猜测用户ID导致260万用户的电子邮件和姓名被窃取；以及Peleton，由于授权漏洞导致超过400万用户的数据泄露。
我们在API安全方面的工作是在问题出现之前发现漏洞。我们听说从OWASP API前10名开始是不错的选择，但他说我们需要更一致和自动化地测试意外用途。他在演讲结束时迅速列出了在APISEC大学的免费课程中使用的自己的前10名最佳实践：
1. 从治理开始。2. 了解您的API生态系统。3. 让安全和开发团队进行沟通。4. API文档是必不可少的。5. 培训API开发人员和所有者有关API安全的知识。6. 集中管理API。7. 不要相信任何东西；验证一切。8. 不要依赖UI来提供安全保障。9. 认证不是授权。授权必须在逻辑中进行。10. 在可能的情况下自动化预生产测试。
“为什么您应该入侵自己的API” 来自APIsec创始人 Dan Barahona 在 #APIWorld
API安全紫队的需求
应用程序就像一只章鱼。威胁X的安全策略和现任CISO的安全策略总监Jeremy Ventura在他的演讲“红+蓝=紫：API安全策略的探讨”中说到。像一只章鱼一样，有一个中央的身体和头部提供应用程序的动力。API就像每一只伸出的手臂，使章鱼能够移动和与世界互动。
传统的安全“蓝队”专注于保护中央应用程序，而不是手臂。红队越来越注重通过任意途径进入。由于API调用现在负责超过80％的网络流量，清楚地表明这是新的战线。我们需要在中间会合，并将重点转向安全和发现API的弱点。
Jeremy说，最大的问题之一是大多数组织不知道他们管理多少个API。这导致了一堆“僵尸API”，它们本应该被废弃，但仍然允许进行调用。他说，在与客户的平均合作中，他们会发现比最初预计的API数量多8倍。
除了OWASP API前10名外，Jeremy说大多数API还需要解决速率限制和日志记录的问题。他说仅靠保存日志是不够的，您必须积极采取行动应对任何可疑活动。我们可以通过共同努力制定政策，培训人员并在开发过程的早期使用更好的测试工具来解决这些问题。虽然技术很重要，但解决安全问题时始终将人放在第一位。
来自威胁X的安全策略和现任CISO的安全策略总监Jeremy Ventura的“红+蓝=紫：API安全策略的探讨”在 #APIWorld
良好的安全从了解您拥有的开始
在活动中，在涉及API或AI安全的任何会话中，几乎每个演讲者都提到了了解您的资产的重要性，作为安全旅程的第一个重要步骤。毕竟，如果不知道它的存在，就无法保护它。这也是我在我的演讲中提到的内容“您知道您的机密信息在哪里吗？探索机密溢出和机密管理成熟度问题”，基于GitGuardian的机密管理成熟度模型。在演讲的一部分中，我们讨论了成熟的组织不仅知道其机密信息的位置，而且可以通过像Hashicorps’ Vault Enterprise或Doppler这样的机密管理服务审计和监控其创建和使用。
还重要的是要了解您代码中的机密信息以及其他不应明文存放的位置。这就是自动机密扫描的作用所在。例如，当将存储库与GitGuardian机密检测平台连接时，它将进行历史扫描，让您了解这些机密信息在您的git历史中的存在位置。从那里开始，它将积极监视任何新进入周边的机密信息，并向您报警。
在秘密管理、API安全以及AI安全方面，事后随意添加安全措施并不是一个选择。我们需要解决在开发生命周期早期列举出的OWASP API Top 10中的漏洞，并停止将每个问题视为仅靠技术解决的问题。我们还需要好的管理机制，创造出好的流程供人们培训。在保护应用程序和顾客方面，我们的代码和API还有很长的路要走，但只有共同学习，相互借鉴，才能找到最佳的保护途径。