Swarms 安全实践详解基于 SECURITY.md 的安全能力全景、遥测隐私开关与漏洞披露流程【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarms本文以 swarms 仓库根目录的 SECURITY.md 为主体完整梳理其中定义的安全特性清单与漏洞披露流程并结合仓库源码逐项验证这些安全声明的落地方式包括敏感配置的环境变量管理、遥测隐私开关、本地日志与错误隔离、工作区数据安全存储、依赖版本锁定等实现证据以及提交安全漏洞报告时的标准格式与响应承诺。读完后你将清楚知道Swarms 在安全策略上承诺了什么、哪些承诺在源码中可以直接找到对应实现、如何用SWARMS_TELEMETRY_ON等开关收紧隐私边界以及发现漏洞后应如何规范地披露。一、SECURITY.md 定义的安全特性全景SECURITY.md 的核心是一张安全特性总表声明了 Swarms 作为企业级多智能体编排框架在安全维度上的能力集合。这张表是理解整个安全策略的骨架原文如下完整保留安全特性收益说明环境变量Environment Variables安全配置通过环境变量安全管理敏感配置无遥测No Telemetry强化隐私不采集遥测数据优先保障用户隐私数据加密Data Encryption数据保护加密敏感数据以防未授权访问认证Authentication访问控制确保只有授权用户可访问系统授权Authorization细粒度访问基于角色和权限授予用户特定的访问权依赖安全Dependency Security降低漏洞风险安全管理依赖以防止漏洞安全安装Secure Installation完整性保障通过可信来源和校验和确保软件完整性定期更新Regular Updates持续防护定期更新以修补漏洞日志与监控Logging and Monitoring运营监督跟踪系统活动以进行安全监控和异常检测错误处理Error Handling健壮安全安全地管理错误以防止敏感信息泄露数据存储安全Data Storage Security安全数据处理安全地存储数据确保机密性和完整性数据传输安全Data Transmission Security安全数据传输保护传输中的数据免受窃听和篡改访问控制机制Access Control Mechanisms受限访问将系统访问限制在授权人员范围内漏洞管理Vulnerability Management主动防护有效识别和缓解安全漏洞法规合规Regulatory Compliance法律遵从确保系统符合相关法规和标准安全审计Security Audits原文此行未完成需要说明两点事实边界其一表中“数据加密”“认证/授权”“法规合规”等条目属于安全策略层面的声明当前仓库中并未检索到与之直接对应的加密模块或鉴权中间件实现认证相关的可参考实现仅以示例形式存在于 examples/mcp/mcp_deployer/token_verifier_with_scopes.py 与 examples/mcp/mcp_deployer/custom_auth_per_tenant.py 中它们是面向 MCP 部署场景的示例代码不代表框架内置了统一鉴权层其二表中“No Telemetry”条目与当前源码存在值得注意的差异下文第三节的遥测模块会专门分析这一点。二、敏感配置管理环境变量是第一道安全边界“Environment Variables — Secure Configuration”是安全表中第一条其源码支撑是 swarms/env.py。该文件只有十几个行实现了整个框架的.env加载入口def load_swarms_env(*, override: bool False) - bool: Load a .env file by searching upward from the current working directory. dotenv_path find_dotenv(.env, usecwdTrue) if not dotenv_path: return False return load_dotenv(dotenv_pathdotenv_path, overrideoverride)从源码结构看这里体现的安全设计有三层密钥不落代码所有 LLM 服务密钥API Key通过.env文件注入进程环境而非硬编码。README.md 的 “Environment Configuration” 章节给出的标准模板为OPENAI_API_KEY WORKSPACE_DIRagent_workspace ANTHROPIC_API_KEY GROQ_API_KEY这套配置对应 requirements.txt 中声明的python-dotenv依赖。可发现性搜索find_dotenv(.env, usecwdTrue)从当前工作目录向上查找.env保证在子进程、子目录运行脚本时仍能找到统一配置减少“临时把密钥写在命令行”的泄密面。覆盖可控override参数默认False意味着已存在的进程环境变量不会被.env文件悄悄覆盖——在生产环境中这对“环境变量优先级高于文件”的部署惯例是符合安全预期的避免低权限的仓库内文件篡改高权限的运行环境。三、遥测与隐私文档声明“无遥测”与源码中可开关的 OTel 实现之间的差异这是阅读 SECURITY.md 时必须核实的要点。文档表格声明 “No Telemetry —— 不采集遥测数据”但当前仓库中确实存在一个完整实现的遥测子系统位于 swarms/telemetry/ 目录main.py、otel.py、bootup.py。以源码为准其真实行为是默认开启、可显式关闭swarms/telemetry/otel.py 中的telemetry_on()读取单个总开关SWARMS_TELEMETRY_ON。该变量未设置时返回True遥测开启设置为false、0、no、off、disable、disabled不区分大小写之一或设为空字符串SWARMS_TELEMETRY_ON才会关闭。测试文件 tests/telemetry/test_telemetry.py 中有test_telemetry_on_unset_defaults_to_on与test_telemetry_on_empty_value_is_off等用例逐条验证了上述语义其中特别断言了“在.env里写空值SWARMS_TELEMETRY_ON是关闭而不是打开”这一反直觉细节。数据最小化与长度约束即便遥测开启上报内容也经过严格约束。swarms/telemetry/otel.py 定义了两个截断上限SWARMS_OTEL_MAX_CHARS默认 16000 字符限制单个属性值长度SWARMS_OTEL_MAX_CONFIG_CHARS默认 65536限制整体配置序列化长度超长的输入输出会被截断并追加…[truncated]标记。不留内存地址_describe()与_sanitize()swarms/telemetry/otel.py专门处理无法 JSON 序列化的对象注释明确指出“内存地址会让相同配置在不同运行间产生差异……因此这里不允许回退到默认的object.__repr__”遇到不可序列化对象时降级为unserializable ClassName而非抛出异常或输出对象地址。fail-safe 原则SwarmTelemetry类的文档声明 “Never raises into the caller”——遥测的任何失败缺依赖、网络不可达、配置错误都只会让实例处于惰性状态ready False所有方法退化为廉价空操作绝不打断业务代码。上报地址与超时导出端点为swarms-telemetry-capturer-production服务下的/v1/tracesswarms/telemetry/otel.py并通过SWARMS_OTEL_TIMEOUT默认 8 秒限制导出时间“bound worst-case so a dead network cant stall exit”。服务名可用OTEL_SERVICE_NAME配置默认swarms。机器指纹的哈希化swarms/telemetry/main.py 中get_machine_id()对platform.node()做 SHA-256 哈希后才使用generate_user_id()则使用随机uuid4避免原始主机名直接外发。实践结论如果你的部署环境要求“零遥测”不应依赖 SECURITY.md 表格中“无遥测”的字面表述而应显式设置环境变量来关闭——这是当前源码实际提供的隐私控制手段# 在 .env 或 shell 中显式关闭 OTel 遥测 SWARMS_TELEMETRY_ONfalse同时可结合 examples/changelogs/v14-zena/01_opentelemetry_tracing.py 查看官方示例中如何配置与验证 OpenTelemetry 追踪链路。需要强调遥测开关在进程启动时读取一次swarm_telemetry()是lru_cache单例运行中途修改SWARMS_TELEMETRY_ON不会生效须重启进程。四、日志与监控、错误处理把异常信息关在本地安全表中的 “Logging and Monitoring” 与 “Error Handling” 两行对应仓库中两条并行的实现线。本地错误日志。swarms/telemetry/bootup.py 的bootup()在框架初始化时读取SWARMS_VERBOSE_GLOBAL默认False为false时禁用CRITICAL级别以下的输出并静默 wandbWANDB_SILENTtrue随后调用 swarms/utils/disable_logging.py 的disable_logging()。后者把 tensorflow、urllib3、git 等第三方 logger 压到CRITICAL/ERROR级并建立两个 ERROR 级 handler——一个写到工作区的error.txt文件一个输出到终端swarms/utils/disable_logging.py。从安全角度看这套机制的意义是错误信息只落在本地工作区WORKSPACE_DIR或默认的agent_workspace而不是向远程端点回传异常堆栈bootup()里对遥测初始化异常的捕获也是“记录后吞掉”Telemetry error: {e}保证启动链路不因监控问题失败。异常内容的外发约束。若遥测处于开启状态异常确实会被记录到 spanswarms.error.type与截断后的swarms.error.message见 swarms/telemetry/otel.py但始终经过_truncate()限长且异常消息只是str(exc)的截断形式而非任意对象 repr——这与第三节“错误处理防止敏感信息泄露”的策略表述是一致的。对开发者而言capture_error()swarms/telemetry/otel.py的文档还明确区分了两类错误传播出去的异常由capture_run自动捕获而被业务逻辑吞掉的异常例如单个 agent 失败但 swarm 继续运行应主动调用capture_error记录避免“静默丢失”这类最难排查的故障。五、数据存储安全本地工作区的路径安全与写入隔离“Data Storage Security”在源码中的对应物是工作区管理模块 swarms/utils/workspace_manager.py。各 swarm 类型统一通过WorkspaceManager将对话历史等运行数据写入本地目录如conversation_history.json该模块的模块注释强调其安全基调“Nothing here raises. Autosave is a side effect of a run, never a reason for one to fail”——自动保存的任何失败只记日志、返回None不会让一次运行因写盘问题而崩溃。其中与数据安全直接相关的是路径清洗函数sanitize_name()swarms/utils/workspace_manager.py_INVALID_PATH_CHARS :/\\|?* _MAX_NAME_LEN 100 def sanitize_name(name: str) - str: if not name: return unnamed sanitized str(name) for char in _INVALID_PATH_CHARS: sanitized sanitized.replace(char, _) sanitized sanitized.strip(. ).replace( , -) return sanitized[:_MAX_NAME_LEN] or unnamed它把智能体/群组名称中可能引起路径穿越或非法文件名的字符:/\|?*替换为_剥离首尾的.与空格并把长度限制在 100 字符内。从源码结构看这是典型的“用 LLM 生成的名字拼文件路径前先清洗输入”的防御式写法防止恶意或异常的agent_name把写入位置带出预期目录。工作区目录本身由WORKSPACE_DIR环境变量决定bootup()中的_prepare_workspace()swarms/telemetry/bootup.py还处理了“用户给的路径不可创建时回退到默认./agent_workspace”的场景确保存储位置失败也不会阻断import swarms。六、依赖安全与可验证安装版本锁定与最小依赖面“Dependency Security”一行可以由 requirements.txt 直接印证。核心依赖采用了精确锁定与受限区间两类策略pydantic2.12.5 litellm1.76.1 mcp1.28.1,3.0.0其中 LLM 调用层litellm与数据校验层pydantic使用精确锁版本mcp则用3.0.0的上界区间约束大版本。框架整体直接依赖保持在 17 个包左右见 requirements.txt 全文遥测依赖opentelemetry-sdk与opentelemetry-exporter-otlp-proto-http也在其中明确列出不存在隐式拉取。安装方式的验证入口见 scripts/setup.shDocker 场景下 scripts/docker/Dockerfile 与 scripts/docker/DOCKER.md 提供了基于仓库构建的镜像路径。七、报告安全漏洞流程、格式与响应承诺SECURITY.md 的下半部分定义了完整的漏洞披露流程这是安全文档中唯一“对外操作型”的章节要点如下报告渠道发现安全漏洞后应通过邮件发送至安全团队地址kyeswarms.world原文给出的联系方式。响应承诺安全团队表示会在24 小时内确认收到报告并在调查过程中定期提供进展更新对全部漏洞报告保持及时响应的目标。报告内容要求原文明确要求提供“详细的信息”至少包括——复现步骤steps to reproduce潜在影响potential impact已知缓解措施any known mitigations。处置方式评估确认后处置手段“可能包括发布安全补丁、发布安全公告或实施其他适当的缓解措施”。拒收条件与所声明的版本范围无关、或信息不足以评估的报告可能被拒绝受理原文“not related to the specified versions or do not provide sufficient information may be declined”。按此流程一份合格的最小漏洞报告模板可以是标题[Swarms 版本号] 组件名 漏洞类型简述 正文 1. 环境swarms 版本 / Python 版本 / 操作系统 2. 复现步骤最小可运行代码或命令序列 3. 预期行为 vs 实际行为 4. 潜在影响影响面数据泄露/拒绝服务/远程执行等与严重度评估 5. 已知缓解临时规避方案如关闭某环境变量、升级/降级某依赖八、小结如何基于本文收紧一次 Swarms 部署的安全姿态结合文档声明与源码证据落地检查项可以收敛为四步密钥管理所有 API Key 只写入.env由 swarms/env.py 的load_swarms_env()加载不进入代码与 CI 日志生产环境优先用进程环境变量而非仓库内文件。遥测决策明确阅读 swarms/telemetry/otel.py 的telemetry_on()语义——默认是开启的需要零遥测时显式设置SWARMS_TELEMETRY_ONfalse或0/off/disable等并用SWARMS_OTEL_MAX_CHARS/SWARMS_OTEL_MAX_CONFIG_CHARS/SWARMS_OTEL_TIMEOUT进一步约束上报内容与超时。存储与日志通过WORKSPACE_DIR把自动保存数据对话历史、error.txt定向到受控目录用SWARMS_VERBOSE_GLOBAL控制运行期日志噪音。漏洞响应按第七节的渠道与格式提交报告确保包含复现步骤、影响面与缓解措施避免因“信息不足”被拒收。最后重申本文的证据边界安全表中的“数据加密”“认证/授权”“法规合规”等条目目前属于策略声明仓库内可核验的实现集中在环境变量管理、遥测开关与数据最小化、本地错误日志、工作区路径清洗、依赖版本锁定这五个方面对任何超出源码证据的能力描述例如“已加密存储”“已通过某合规认证”请以官方后续发布的安全公告为准。【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Swarms 安全实践详解：基于 SECURITY.md 的安全能力全景、遥测隐私开关与漏洞披露流程
Swarms 安全实践详解基于 SECURITY.md 的安全能力全景、遥测隐私开关与漏洞披露流程【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarms本文以 swarms 仓库根目录的 SECURITY.md 为主体完整梳理其中定义的安全特性清单与漏洞披露流程并结合仓库源码逐项验证这些安全声明的落地方式包括敏感配置的环境变量管理、遥测隐私开关、本地日志与错误隔离、工作区数据安全存储、依赖版本锁定等实现证据以及提交安全漏洞报告时的标准格式与响应承诺。读完后你将清楚知道Swarms 在安全策略上承诺了什么、哪些承诺在源码中可以直接找到对应实现、如何用SWARMS_TELEMETRY_ON等开关收紧隐私边界以及发现漏洞后应如何规范地披露。一、SECURITY.md 定义的安全特性全景SECURITY.md 的核心是一张安全特性总表声明了 Swarms 作为企业级多智能体编排框架在安全维度上的能力集合。这张表是理解整个安全策略的骨架原文如下完整保留安全特性收益说明环境变量Environment Variables安全配置通过环境变量安全管理敏感配置无遥测No Telemetry强化隐私不采集遥测数据优先保障用户隐私数据加密Data Encryption数据保护加密敏感数据以防未授权访问认证Authentication访问控制确保只有授权用户可访问系统授权Authorization细粒度访问基于角色和权限授予用户特定的访问权依赖安全Dependency Security降低漏洞风险安全管理依赖以防止漏洞安全安装Secure Installation完整性保障通过可信来源和校验和确保软件完整性定期更新Regular Updates持续防护定期更新以修补漏洞日志与监控Logging and Monitoring运营监督跟踪系统活动以进行安全监控和异常检测错误处理Error Handling健壮安全安全地管理错误以防止敏感信息泄露数据存储安全Data Storage Security安全数据处理安全地存储数据确保机密性和完整性数据传输安全Data Transmission Security安全数据传输保护传输中的数据免受窃听和篡改访问控制机制Access Control Mechanisms受限访问将系统访问限制在授权人员范围内漏洞管理Vulnerability Management主动防护有效识别和缓解安全漏洞法规合规Regulatory Compliance法律遵从确保系统符合相关法规和标准安全审计Security Audits原文此行未完成需要说明两点事实边界其一表中“数据加密”“认证/授权”“法规合规”等条目属于安全策略层面的声明当前仓库中并未检索到与之直接对应的加密模块或鉴权中间件实现认证相关的可参考实现仅以示例形式存在于 examples/mcp/mcp_deployer/token_verifier_with_scopes.py 与 examples/mcp/mcp_deployer/custom_auth_per_tenant.py 中它们是面向 MCP 部署场景的示例代码不代表框架内置了统一鉴权层其二表中“No Telemetry”条目与当前源码存在值得注意的差异下文第三节的遥测模块会专门分析这一点。二、敏感配置管理环境变量是第一道安全边界“Environment Variables — Secure Configuration”是安全表中第一条其源码支撑是 swarms/env.py。该文件只有十几个行实现了整个框架的.env加载入口def load_swarms_env(*, override: bool False) - bool: Load a .env file by searching upward from the current working directory. dotenv_path find_dotenv(.env, usecwdTrue) if not dotenv_path: return False return load_dotenv(dotenv_pathdotenv_path, overrideoverride)从源码结构看这里体现的安全设计有三层密钥不落代码所有 LLM 服务密钥API Key通过.env文件注入进程环境而非硬编码。README.md 的 “Environment Configuration” 章节给出的标准模板为OPENAI_API_KEY WORKSPACE_DIRagent_workspace ANTHROPIC_API_KEY GROQ_API_KEY这套配置对应 requirements.txt 中声明的python-dotenv依赖。可发现性搜索find_dotenv(.env, usecwdTrue)从当前工作目录向上查找.env保证在子进程、子目录运行脚本时仍能找到统一配置减少“临时把密钥写在命令行”的泄密面。覆盖可控override参数默认False意味着已存在的进程环境变量不会被.env文件悄悄覆盖——在生产环境中这对“环境变量优先级高于文件”的部署惯例是符合安全预期的避免低权限的仓库内文件篡改高权限的运行环境。三、遥测与隐私文档声明“无遥测”与源码中可开关的 OTel 实现之间的差异这是阅读 SECURITY.md 时必须核实的要点。文档表格声明 “No Telemetry —— 不采集遥测数据”但当前仓库中确实存在一个完整实现的遥测子系统位于 swarms/telemetry/ 目录main.py、otel.py、bootup.py。以源码为准其真实行为是默认开启、可显式关闭swarms/telemetry/otel.py 中的telemetry_on()读取单个总开关SWARMS_TELEMETRY_ON。该变量未设置时返回True遥测开启设置为false、0、no、off、disable、disabled不区分大小写之一或设为空字符串SWARMS_TELEMETRY_ON才会关闭。测试文件 tests/telemetry/test_telemetry.py 中有test_telemetry_on_unset_defaults_to_on与test_telemetry_on_empty_value_is_off等用例逐条验证了上述语义其中特别断言了“在.env里写空值SWARMS_TELEMETRY_ON是关闭而不是打开”这一反直觉细节。数据最小化与长度约束即便遥测开启上报内容也经过严格约束。swarms/telemetry/otel.py 定义了两个截断上限SWARMS_OTEL_MAX_CHARS默认 16000 字符限制单个属性值长度SWARMS_OTEL_MAX_CONFIG_CHARS默认 65536限制整体配置序列化长度超长的输入输出会被截断并追加…[truncated]标记。不留内存地址_describe()与_sanitize()swarms/telemetry/otel.py专门处理无法 JSON 序列化的对象注释明确指出“内存地址会让相同配置在不同运行间产生差异……因此这里不允许回退到默认的object.__repr__”遇到不可序列化对象时降级为unserializable ClassName而非抛出异常或输出对象地址。fail-safe 原则SwarmTelemetry类的文档声明 “Never raises into the caller”——遥测的任何失败缺依赖、网络不可达、配置错误都只会让实例处于惰性状态ready False所有方法退化为廉价空操作绝不打断业务代码。上报地址与超时导出端点为swarms-telemetry-capturer-production服务下的/v1/tracesswarms/telemetry/otel.py并通过SWARMS_OTEL_TIMEOUT默认 8 秒限制导出时间“bound worst-case so a dead network cant stall exit”。服务名可用OTEL_SERVICE_NAME配置默认swarms。机器指纹的哈希化swarms/telemetry/main.py 中get_machine_id()对platform.node()做 SHA-256 哈希后才使用generate_user_id()则使用随机uuid4避免原始主机名直接外发。实践结论如果你的部署环境要求“零遥测”不应依赖 SECURITY.md 表格中“无遥测”的字面表述而应显式设置环境变量来关闭——这是当前源码实际提供的隐私控制手段# 在 .env 或 shell 中显式关闭 OTel 遥测 SWARMS_TELEMETRY_ONfalse同时可结合 examples/changelogs/v14-zena/01_opentelemetry_tracing.py 查看官方示例中如何配置与验证 OpenTelemetry 追踪链路。需要强调遥测开关在进程启动时读取一次swarm_telemetry()是lru_cache单例运行中途修改SWARMS_TELEMETRY_ON不会生效须重启进程。四、日志与监控、错误处理把异常信息关在本地安全表中的 “Logging and Monitoring” 与 “Error Handling” 两行对应仓库中两条并行的实现线。本地错误日志。swarms/telemetry/bootup.py 的bootup()在框架初始化时读取SWARMS_VERBOSE_GLOBAL默认False为false时禁用CRITICAL级别以下的输出并静默 wandbWANDB_SILENTtrue随后调用 swarms/utils/disable_logging.py 的disable_logging()。后者把 tensorflow、urllib3、git 等第三方 logger 压到CRITICAL/ERROR级并建立两个 ERROR 级 handler——一个写到工作区的error.txt文件一个输出到终端swarms/utils/disable_logging.py。从安全角度看这套机制的意义是错误信息只落在本地工作区WORKSPACE_DIR或默认的agent_workspace而不是向远程端点回传异常堆栈bootup()里对遥测初始化异常的捕获也是“记录后吞掉”Telemetry error: {e}保证启动链路不因监控问题失败。异常内容的外发约束。若遥测处于开启状态异常确实会被记录到 spanswarms.error.type与截断后的swarms.error.message见 swarms/telemetry/otel.py但始终经过_truncate()限长且异常消息只是str(exc)的截断形式而非任意对象 repr——这与第三节“错误处理防止敏感信息泄露”的策略表述是一致的。对开发者而言capture_error()swarms/telemetry/otel.py的文档还明确区分了两类错误传播出去的异常由capture_run自动捕获而被业务逻辑吞掉的异常例如单个 agent 失败但 swarm 继续运行应主动调用capture_error记录避免“静默丢失”这类最难排查的故障。五、数据存储安全本地工作区的路径安全与写入隔离“Data Storage Security”在源码中的对应物是工作区管理模块 swarms/utils/workspace_manager.py。各 swarm 类型统一通过WorkspaceManager将对话历史等运行数据写入本地目录如conversation_history.json该模块的模块注释强调其安全基调“Nothing here raises. Autosave is a side effect of a run, never a reason for one to fail”——自动保存的任何失败只记日志、返回None不会让一次运行因写盘问题而崩溃。其中与数据安全直接相关的是路径清洗函数sanitize_name()swarms/utils/workspace_manager.py_INVALID_PATH_CHARS :/\\|?* _MAX_NAME_LEN 100 def sanitize_name(name: str) - str: if not name: return unnamed sanitized str(name) for char in _INVALID_PATH_CHARS: sanitized sanitized.replace(char, _) sanitized sanitized.strip(. ).replace( , -) return sanitized[:_MAX_NAME_LEN] or unnamed它把智能体/群组名称中可能引起路径穿越或非法文件名的字符:/\|?*替换为_剥离首尾的.与空格并把长度限制在 100 字符内。从源码结构看这是典型的“用 LLM 生成的名字拼文件路径前先清洗输入”的防御式写法防止恶意或异常的agent_name把写入位置带出预期目录。工作区目录本身由WORKSPACE_DIR环境变量决定bootup()中的_prepare_workspace()swarms/telemetry/bootup.py还处理了“用户给的路径不可创建时回退到默认./agent_workspace”的场景确保存储位置失败也不会阻断import swarms。六、依赖安全与可验证安装版本锁定与最小依赖面“Dependency Security”一行可以由 requirements.txt 直接印证。核心依赖采用了精确锁定与受限区间两类策略pydantic2.12.5 litellm1.76.1 mcp1.28.1,3.0.0其中 LLM 调用层litellm与数据校验层pydantic使用精确锁版本mcp则用3.0.0的上界区间约束大版本。框架整体直接依赖保持在 17 个包左右见 requirements.txt 全文遥测依赖opentelemetry-sdk与opentelemetry-exporter-otlp-proto-http也在其中明确列出不存在隐式拉取。安装方式的验证入口见 scripts/setup.shDocker 场景下 scripts/docker/Dockerfile 与 scripts/docker/DOCKER.md 提供了基于仓库构建的镜像路径。七、报告安全漏洞流程、格式与响应承诺SECURITY.md 的下半部分定义了完整的漏洞披露流程这是安全文档中唯一“对外操作型”的章节要点如下报告渠道发现安全漏洞后应通过邮件发送至安全团队地址kyeswarms.world原文给出的联系方式。响应承诺安全团队表示会在24 小时内确认收到报告并在调查过程中定期提供进展更新对全部漏洞报告保持及时响应的目标。报告内容要求原文明确要求提供“详细的信息”至少包括——复现步骤steps to reproduce潜在影响potential impact已知缓解措施any known mitigations。处置方式评估确认后处置手段“可能包括发布安全补丁、发布安全公告或实施其他适当的缓解措施”。拒收条件与所声明的版本范围无关、或信息不足以评估的报告可能被拒绝受理原文“not related to the specified versions or do not provide sufficient information may be declined”。按此流程一份合格的最小漏洞报告模板可以是标题[Swarms 版本号] 组件名 漏洞类型简述 正文 1. 环境swarms 版本 / Python 版本 / 操作系统 2. 复现步骤最小可运行代码或命令序列 3. 预期行为 vs 实际行为 4. 潜在影响影响面数据泄露/拒绝服务/远程执行等与严重度评估 5. 已知缓解临时规避方案如关闭某环境变量、升级/降级某依赖八、小结如何基于本文收紧一次 Swarms 部署的安全姿态结合文档声明与源码证据落地检查项可以收敛为四步密钥管理所有 API Key 只写入.env由 swarms/env.py 的load_swarms_env()加载不进入代码与 CI 日志生产环境优先用进程环境变量而非仓库内文件。遥测决策明确阅读 swarms/telemetry/otel.py 的telemetry_on()语义——默认是开启的需要零遥测时显式设置SWARMS_TELEMETRY_ONfalse或0/off/disable等并用SWARMS_OTEL_MAX_CHARS/SWARMS_OTEL_MAX_CONFIG_CHARS/SWARMS_OTEL_TIMEOUT进一步约束上报内容与超时。存储与日志通过WORKSPACE_DIR把自动保存数据对话历史、error.txt定向到受控目录用SWARMS_VERBOSE_GLOBAL控制运行期日志噪音。漏洞响应按第七节的渠道与格式提交报告确保包含复现步骤、影响面与缓解措施避免因“信息不足”被拒收。最后重申本文的证据边界安全表中的“数据加密”“认证/授权”“法规合规”等条目目前属于策略声明仓库内可核验的实现集中在环境变量管理、遥测开关与数据最小化、本地错误日志、工作区路径清洗、依赖版本锁定这五个方面对任何超出源码证据的能力描述例如“已加密存储”“已通过某合规认证”请以官方后续发布的安全公告为准。【免费下载链接】swarmsThe Enterprise-Grade Multi-Agent Orchestration Framework. Website: https://swarms.ai项目地址: https://gitcode.com/GitHub_Trending/swar/swarms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考