返回首页
24小时热榜
大家好，我是JJ，Gecko Security的联合创始人（[https://www.gecko.security](https://www.gecko.security)）。我们正在构建一种新型的静态分析工具，利用大型语言模型（LLMs）来发现当前扫描器遗漏的复杂业务逻辑和多步骤漏洞。我们已经在Ollama、Gradio和Ragflow等项目中发现了30多个CVE（公共漏洞和暴露）记录（[https://www.gecko.security/research](https://www.gecko.security/research)）。您可以在任何开源软件（OSS）代码库上亲自试用（[https://app.gecko.security](https://app.gecko.security)）。
任何使用过静态应用程序安全测试（SAST）工具的人都知道，它们存在高假阳性率的问题，同时也会漏掉像身份验证绕过或权限提升等整个类别的漏洞。这一限制源于其核心架构。SAST工具的设计是将代码解析为简单的模型，如抽象语法树（AST）或调用图，这在动态类型语言或微服务边界中很快失去上下文，并且仅限于解析基本的调用链。在检测漏洞时，它们依赖于正则表达式或YAML规则进行模式匹配，这对于基本的技术类漏洞（如XSS、SQL注入）可能有效，但对于不符合已知模式的逻辑缺陷，以及需要长序列依赖操作才能达到可利用状态的漏洞则显得不足。
我和我的联合创始人在国家情报和军事网络部队的职业生涯中看到了这些限制，我们在其中构建了自动化工具来保护关键基础设施。我们意识到，具有正确架构的LLMs可以最终解决这些问题。
漏洞是有上下文的。可利用性完全依赖于每个应用程序的安全模型。我们意识到，准确的检测需要理解什么是应该被保护的，以及破坏它的原因。这意味着将威胁建模直接嵌入我们的分析中，而不是将其视为事后考虑。
为了实现这一目标，我们首先必须解决代码解析问题。我们的解决方案是构建一个自定义的、编译器精确的索引器，灵感来自GitHub的堆栈图方法，以精确导航代码，类似于集成开发环境（IDE）。我们基于LSIF方法（[https://lsif.dev/](https://lsif.dev/)），但用紧凑的protobuf模式替代冗长的JSON，以二进制格式序列化符号定义和引用。我们使用特定语言的工具来解析和类型检查代码，生成一系列Protobuf消息，记录符号的位置、定义和引用信息。通过使用Protobuf的高效性和强类型特性，我们可以生成更小的索引，同时保留检测复杂调用链所需的编译器精确语义信息。
这就是为什么大多数使用AST解析的“SAST + LLM”工具失败的原因——它们向LLMs提供了来自传统解析器的不完整或不正确的代码信息，使得在缺乏上下文的情况下很难准确推理安全问题。
通过我们的索引器提供准确的代码结构，我们使用LLM进行威胁建模，分析开发者意图、数据和信任边界以及暴露的端点，以生成潜在攻击场景。这正是LLMs倾向于产生幻觉的特性成为突破性功能的地方。
对于每个生成的潜在攻击路径，我们进行系统搜索，查询索引器以收集所有必要的上下文，并重建从源到汇的完整调用链。为了验证漏洞，我们使用蒙特卡洛树自我优化（MCTSr）算法和“胜利函数”来确定假设攻击成功的可能性。一旦发现的结果超过设定的实用性阈值，就确认其为真正的阳性。
通过这种方法，我们发现了像CVE-2025-51479这样的漏洞，该漏洞出现在ONYX（一个开源企业搜索平台）中，策展人可以修改任何组，而不仅仅是他们被分配的组。用户组API有一个用户参数应该检查权限，但从未使用它。Gecko推断开发者意图限制策展人的访问，因为用户界面和类似的API函数都正确验证了该权限。这确立了“策展人具有有限范围”作为一个安全不变式，而这个特定API违反了这一点。传统SAST无法检测到这一点。任何标记未使用用户参数的规则都会淹没在假阳性中，因为许多函数合法地保留未使用的参数。更重要的是，检测这一点需要知道哪些函数处理授权，理解ONYX的策展人权限模型，并识别多个文件中的验证模式——这是SAST根本无法做到的上下文推理。
我们有几家企业客户正在使用Gecko，因为它解决了他们无法用传统SAST工具处理的问题。他们在相同代码库上看到假阳性减少了50%，并发现了以前只在手动渗透测试中出现的漏洞。
深入探讨假阳性，没有任何静态分析工具能够实现完美的准确性，无论是人工智能还是其他方法。我们在两个关键点上减少假阳性。首先，我们的索引器消除了任何程序解析错误，这些错误会导致传统AST工具易受影响的错误调用链。其次，我们通过提出具体的、上下文相关的问题来避免不必要的LLM幻觉和推理错误，而不是开放式问题。LLM知道哪些安全不变式需要保持，并可以根据上下文做出确定性的评估。当我们标记某些内容时，人工审核也很迅速，因为我们提供了完整的源到汇的数据流分析，附带概念验证代码和基于置信度评分的输出结果。
我们非常希望得到社区的反馈、未来方向的想法或在这一领域的经验。我会在评论区回复大家！
嗨，Hacker News社区，
我很高兴与大家分享Nova，这是一个为Erlang构建的新型网络框架，旨在使Erlang的网络开发变得更简单、更快速和更易于接触。Nova利用Erlang的并发性、可靠性和可扩展性，创建了一个强大而轻量的框架，用于构建现代网络应用程序。
主要特点：
* 轻量且模块化：易于与现有的Erlang项目集成。
* 为并发而生：利用Erlang的演员模型，实现高性能的网络应用。
* 开发者友好：简化路由、中间件和模板处理。
* 可扩展：支持插件和自定义集成。
请查看：
GitHub: [https://github.com/novaframework/nova](https://github.com/novaframework/nova)
主页: [https://novaframework.org](https://novaframework.org)
入门指南: [https://dev.to/taure/getting-started-with-nova-1ioo/stats](https://dev.to/taure/getting-started-with-nova-1ioo/stats)
我们目前处于开发早期，非常希望得到社区的反馈！如果你是Erlang爱好者，或者对使用这种以可靠性著称的语言（想想WhatsApp或RabbitMQ）构建网络应用感兴趣，请试试Nova，并告诉我们你的想法。
你对使用Erlang进行网络开发有什么看法？你希望在这样的框架中看到哪些功能？
嗨，Pietro 和 Luigi 在这里，我们是 mcp-use 的作者（<a href="https://github.com/mcp-use/mcp-use">https://github.com/mcp-use/mcp-use</a>）。
<p>当第一批 MCP 服务器发布时，我们对这项技术感到非常兴奋，但当我们想要深入了解时，发现 MCP 只能通过 Claude Desktop 或 Cursor 使用。作为工程师，我们对此并不满意。MCP 似乎是一个你想要自己用来构建产品和应用的工具，而不是一个隐藏在闭源应用后面的东西。
<p>于是我们开始接触 SDK，但对开发者体验感到相当不满（双重异步循环，大量样板代码）。我们决定编写 mcp-use 来简化我们的工作。
<p>mcp-use 让你只需 6 行代码即可将任何 LLM 连接到任何 MCP 服务器。我们提供了一个高层次的抽象，覆盖了官方 MCP SDK，使你的生活更轻松，并支持协议的所有功能。
<p>演示视频在这里：<a href="https://www.youtube.com/watch?v=nL_B6LZAsp4" rel="nofollow">https://www.youtube.com/watch?v=nL_B6LZAsp4</a>。
<p>我们提供的关键抽象称为 MCPClient 和 MCPAgent。
<p>MCPClient 接收一组服务器配置，自动检测传输类型，并创建一个后台任务来处理与服务器之间的流。
<p>MCPAgent 是 MCPClient、LLM 和自定义系统提示的组合。它通过将工具、资源和提示转换为模型无关的工具来消费 MCP 客户端，这些工具可以被 LLM 调用。
<p>该库还包含一些很酷的实用工具：
<p>- 安全的沙箱执行 MCP 服务器（我们知道该协议在安全性方面表现不佳）
<p>- 允许代理搜索可用服务器和工具的元工具（以避免上下文泛滥），并动态连接到所需的服务器（你可以用这个创建全能代理）。
<p>我们用这个做了一些很酷的事情：
- 编写一个可以使用浏览器的代理，创建/读取更新了最新信息的线性票据。
<p>- 编写一个可以访问我们公司指标的代理，自动生成每周报告。
<p>- 我将一个代理连接到我在 IKEA 窗帘上黑客攻击的 MCP，以根据光照情况的图像调整我的房间照明。
<p>- 重建了一个开源的 Claude 代码风格 CLI，具有完整的 MCP 功能，但使用自定义模型和 BYOK（<a href="https://github.com/mcp-use/mcp-use-cli">https://github.com/mcp-use/mcp-use-cli</a>）。
<p>我们最近的下载量超过了 100,000 次，许多组织，包括 NASA，都在使用我们的工具！
<p>我们很想听听你们的想法，最重要的是我们如何改进它！我们乐意回答任何问题，并期待你们的反馈。
大家好，我们是 Haakam、Michael 和 Adi。我们正在构建 AgentMail（<a href="https://agentmail.to">https://agentmail.to</a>），这是一个为 AI 代理提供独立电子邮箱的 API。我们不是在谈论为您的电子邮件提供 AI，而是为您的 AI 提供电子邮件。
我们开始构建电子邮件代理，因为它们可以在收件箱中与用户对话，自动化基于电子邮件的工作流程，并与第三方应用进行身份验证。鉴于这些独特的功能，我们认为电子邮件将成为代理的核心接口。
但我们最初是在 Gmail 的基础上进行开发，这让我们感到很挣扎：API 支持差、订阅费用高、速率限制、发送限制、GCP Pub/Sub、OAuth、糟糕的关键词搜索，以及整体糟糕的开发者体验。
Gmail 和其他提供商并不适合我们。因此，我们决定迎难而上，自己构建一个。
AgentMail 类似于 Gmail，但以 API 为先，支持程序化收件箱创建、通过 Webhook 和 WebSocket 发送事件、简单的 API 密钥认证、全组织的语义搜索、结构化数据提取，以及基于使用量的定价，随着发送/接收的电子邮件数量而扩展。
这里有一个构建电子邮件代理的演示：<a href="https://youtu.be/1V7BISeFUTM" rel="nofollow">https://youtu.be/1V7BISeFUTM</a>
这里有一个拥有自己电子邮箱的语音代理的演示：<a href="https://youtu.be/eG2fCsRK4RY" rel="nofollow">https://youtu.be/eG2fCsRK4RY</a>
到目前为止，AgentMail 已经被部署在多个用例中，例如为每个用户提供独立收件箱的应用、实时接收文档的语音代理、自动化账户配置和质量测试、拥有数千个收件箱的冷外呼平台、处理发票的自动化，以及与人类和其他代理协调工作的代理。
我们非常希望听到您的想法和反馈。您可以在 <a href="https://chat.agentmail.to">https://chat.agentmail.to</a> 尝试我们的演示平台。