PraisonAI 安全政策与漏洞披露指南多包生态的安全边界、报告流程与源码级防护实现【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAI导读本文基于 PraisonAI 仓库根目录的 SECURITY.md系统梳理该多包项目Python SDK、TypeScript SDK、平台端的安全政策全貌哪些包在支持范围、哪些问题属于漏洞报告范围、如何通过私有安全通告Private Security Advisory上报、上报后会经历怎样的处置流程以及维护者侧的标准审计工作流。同时结合仓库源码展示 PraisonAI 在提示注入防御、审计日志、SBOM、依赖审计、PII 脱敏等方向的实际实现帮助开发者、安全研究者和 Agent 贡献者准确理解该项目的安全边界与协作方式。一、支持的软件包与安全边界PraisonAI 以 monorepo 形式维护多个独立发布的产品安全政策按包package划分支持范围。上报漏洞时必须指明具体受影响的包因为平台侧问题不一定影响核心 SDK反之亦然。包名发布渠道Registry仓库源码路径praisonaiagentsPyPIsrc/praisonai-agents/praisonaiPyPIsrc/praisonai/praisonainpmsrc/praisonai-ts/其中praisonaiagents是核心 Agent SDK包含工具tools、MCP、内存、Agent 执行与沙箱sandbox等关键路径praisonaiPython是上层封装/编排层包含 CLI、能力扩展、MCP 服务端、沙箱与 recipe 等praisonainpm/TypeScript是 TypeScript 版本 SDK。独立仓库维护的组件praisonai-platformpraisonai-platform目前在其独立的仓库MervinPraison/PraisonAI-Platform中维护独立进行版本管理与发布不随本仓库 SDK 一起发布。因此平台侧漏洞应通过该独立仓库的安全通告渠道上报而不是在本仓库提交——这一点与维护者审计工作流 security-audit.md 中platform-only 漏洞从不在本仓库处理的规则一致。二、漏洞报告范围In scope / Out of scopeSECURITY.md 对哪些问题值得报告给出了明确清单这有助于研究者在提交前先做自我过滤。属于报告范围In scope认证、授权与多租户隔离问题例如 workspace 边界被突破工具执行、沙箱逃逸sandbox escape与代码执行路径已发布代码中的 SSRF、注入与不安全反序列化MCP、网关gateway以及 Bot/Webhook 集成密钥Secrets处理、JWT/会话配置与默认凭据问题已发布包制品中的供应链supply-chain问题。不属于报告范围Out of scope未由项目维护的 fork 或部署实例中的问题需要物理接触设备或完全攻陷操作员机器才能利用的漏洞针对已不再发布、且无受支持升级路径的版本的报告在文档化、受支持配置下没有实际影响的理论性问题已通过显式文档化 opt-out如仅开发环境使用的环境变量覆盖的行为。从源码角度看上述 In scope 项都能在仓库中找到对应实现面例如 MCP 集成安全在 src/praisonai-agents/praisonaiagents/mcp/mcp_security.py、沙箱安全在 src/praisonai-agents/praisonaiagents/sandbox/security.py、Bot 侧 Webhook 安全在 src/praisonai-bot/praisonai_bot/bots/webhook_security.py以及代码工具的受保护路径守卫见下文防护路径守卫。因此这些条目不是抽象声明而是有具体代码承载的安全关注域。三、如何报告漏洞私有安全通告流程SECURITY.md 要求采用负责任披露responsible disclosure首选方式是打开一个私有private安全通告。上报时请包含以下四类信息受影响的包与版本Affected package and version清晰可复现的步骤Clear reproduction steps影响评估保密性Confidentiality、完整性Integrity、可用性Availability三方面的影响建议的修复方案可选。同时请为分诊triage与补丁发布预留合理时间在补丁版本发布之前不要公开披露。维护者侧对应的工作流要求来自 security-audit.md还包括几条红线供报告者理解项目的处理风格维护者绝不会在公开 issue/PR 中暴露利用细节修复提交使用泛化 commit message如refactor: harden input validation而非暴露攻击向量的标题安全补丁直接在main分支修复并推送不使用特性分支。四、上报后的预期处置流程一旦报告被受理SECURITY.md 明确了四阶段预期Triage分诊——维护者验证报告并给出处置结论real真实漏洞、duplicate重复、wontfix不修复等Fix修复——在main上实施最小化、向后兼容的补丁Release发布——先将修复版本发布到 PyPI/npm再发布安全通告这样 Dependabot 等工具才能把用户指向可用的修复版本Advisory通告——发布 GitHub Security Advisory为报告者署名并在适用时申请 CVE 编号。其中先发补丁、后发通告的顺序是核心原则通告发布时用户必须已经能升级到已修复版本。维护者工作流 security-audit.md 进一步细化了这一过程详见下一节。五、维护者审计工作流从分诊到 CVESECURITY.md 末尾将读者引向维护者/Agent 的官方审计流程文档 src/praisonai-agents/.agent/workflows/security-audit.md该文档以四个阶段完整定义了安全漏洞的标准处置路径这里作要点提炼以下内容均来自该仓库文档Phase 1 — Triage分诊通过gh api列出并读取所有安全通告然后在源码中逐一验证通告所述漏洞是否真实存在或已被修复并打上分诊标签。典型命令形如gh api repos/MervinPraison/PraisonAI/security-advisories \ --jq .[] | \(.ghsa_id) \(.state) \(.severity) \(.summary | .[0:70])Phase 2 — Validate Fix验证并修复修复前必须通过四项校验任何一项不通过都应记录原因并跳到下一条通告是否是真实有效的安全问题而非误报或预期行为修复是否会移除现有功能若会则停止并升级处理修复是否会使 SDK 膨胀只允许最小、聚焦的改动修复是否值得承担复杂度低风险问题可能根本不需要修复。通过校验后在main上做本地修复运行单元测试并为每个修复补充针对性冒烟测试防止后续审计轮次把已修复的漏洞重新打开。Phase 3 — 发布包必须在 Phase 4 之前完成Python 核心 SDK从 src/praisonai-agents/ 目录执行praisonai publish pypi内部走 uvuv lock → uv build → uv publish自动 bump patch 版本需要PYPI_TOKEN环境变量Python 封装层在 src/praisonai/ 目录执行python scripts/bump_and_release.py WRAPPER_VERSION --agents AGENTS_VERSION --wait脚本会等待 core 包在 PyPI 就绪后统一 bump 版本、构建、提交、打 tag、推送并创建 GitHub ReleaseTypeScript SDK仅当漏洞针对 src/praisonai-ts/ 时执行npm version patch npm publishpraisonai-platform绝不从本仓库发布其分诊、补丁、发布与通告全部在其独立仓库完成本仓库没有任何代码 import 它因此平台通告从不要求 SDK 发版。Phase 4 — 更新通告与申请 CVE将通告重新打开为 draft 状态写入patched_versions、vulnerable_version_range与报告者 credits{login: REPORTER_LOGIN, type: reporter}patched_versions必须指向真正包含修复的那个包不要暗示用户需要升级所有包发布通告后再通过 API 请求 CVEGitHub 通常 1~3 个工作日完成审核分配。分诊标签体系标签含义处置动作real可复现的真实安全问题修复 → 发布 → 通告already-fixedmain上已修复但通告仍开启把 patched version 设为当前版本并发布通告duplicate与另一条 GHSA 根因相同关闭或合并链接到主通告not-reproducible无法按步骤复现请求更多细节保持 triage 状态theoretical前置条件苛刻或无实际影响记录理由按 wontfix/低优先级关闭documented-opt-out有文档化逃生通道的预期行为按 wontfix 关闭指向文档/环境变量out-of-scope包、fork 或部署不属于项目发布范围说明理由后关闭版本线与发布边界包版本线说明praisonaiagentspraisonaiPython对齐的 patch 版本例如1.6.62/4.6.62此为文档示例核心 SDK 与封装层通过bump_and_release.py一起发布praisonainpm独立 semverTypeScript SDK从src/praisonai-ts发布praisonai-platform独立 semver独立仓库不从本仓库发布六、仓库中的安全实现佐证源码级安全政策之外当前仓库实际内置了多套可落地的安全能力以下是与其相关的核心实现均为仓库内可核验的代码1. Agent 运行时安全praisonai.security模块入口 src/praisonai/praisonai/security/init.py 提供三项功能且默认零开销、全部 opt-in提示注入防御基于 6 项检查的检测流水线注册在praisonaiagents.hooks的BEFORE_TOOL与BEFORE_AGENT事件上覆盖指令覆盖instruction override、权威声明authority claim、边界操纵boundary manipulation、混淆obfuscation、金融操纵financial manipulation与自伤指令等类别。实现见 src/praisonai/praisonai/security/injection.py其中威胁等级ThreatLevel分为 LOW/MEDIUM/HIGH/CRITICAL 四级严格指令覆盖类短语如ignore all previous instructions、jailbreak、developer mode enabled单次命中即升级为 HIGH 并阻断审计日志追加式append-onlyJSONL 审计日志默认写入~/.praisonai/audit.jsonl可配置是否包含工具输出用于合规场景防护路径守卫对.env、.git/config等关键文件提供受保护路径检查防止 Agent 代码工具误改敏感文件。启用方式极为简单来自 examples/python/security_example.pyfrom praisonai.security import enable_security from praisonaiagents import Agent enable_security() # 一行开启注入防御 审计日志 agent Agent(instructionsYou are a helpful research assistant.) response agent.start(What are the key benefits of open-source AI models?)也可以选择性启用并自定义参数enable_injection_defense(extra_patterns[rACME_SECRET_OVERRIDE])追加公司专属检测模式enable_audit_log(log_path./audit.jsonl, include_outputTrue)记录工具输出。模块还暴露scan_text()可对任意文本单独跑 6 项检查流水线以及is_protected(path)/get_protection_reason(path)检查文件路径是否受保护。需要注意的是源码 docstring 中的明确警告这些 hook 注册在进程级全局的praisonaiagents.hooks注册表上会作用于进程内的所有 Agent在多租户宿主如praisonai serve中不能依赖它做租户级隔离需要保留返回的 hook ID 并通过praisonaiagents.hooks.remove_hook按需拆除——这与 SECURITY.md 将多租户隔离列为 In scope 关注点的定位完全吻合。2. Recipe 供应链安全SBOM、签名与依赖审计src/praisonai/praisonai/recipe/security.py 针对 recipe可复用的 Agent 配方包提供供应链安全能力直接呼应 SECURITY.md 中供应链问题在范围内的条目SBOM 生成generate_sbom()支持 CycloneDX 1.4 与 SPDX 2.3 两种格式自动收集 praisonai 自身版本、lockfile 中的 Python 依赖支持 uv.lock / requirements.lock / poetry.lock以及 recipe 声明的工具与外部依赖Bundle 签名与验证sign_bundle()/verify_bundle()使用 RSA-PKCS1v15-SHA256 对.praisonbundle 的 SHA-256 哈希签名校验时先比对哈希再验签防止 bundle 被篡改依赖审计audit_dependencies()定位 lockfile、收集依赖清单并在可用时调用pip-audit检查已知漏洞输出 vulnerabilities/warnings 报告与passed结论Lockfile 校验validate_lockfile()支持strict模式——严格模式下缺失 lockfile 即判定失败非严格模式仅给出可复现性警告PII 检测与脱敏detect_pii()/redact_pii()内置 email、phone、SSN、信用卡、IP 地址等正则模式支持allow/redact/deny三种策略模式deny 模式下检测到指定 PII 直接抛SecurityError。完整的可运行演示见 examples/security/security_example.py。3. 安全相关的测试保障仓库在多个包内都维护了安全加固与回归测试例如 src/praisonai-agents/tests/unit/test_security_hardening.py、src/praisonai-agents/tests/unit/test_security_audit_fixes.py核心 SDK 侧以及 src/praisonai/tests/unit/test_security_fixes_core.py封装层侧此外还有针对 MCP 安全的 src/praisonai-agents/tests/test_mcp_security.py 与沙箱安全的 src/praisonai-sandbox/tests/test_docker_security.py 等。从这些测试文件的命名与分布可以推断项目对已处置的 GHSA 普遍采用每个 GHSA 一条回归测试的策略以阻止已修复漏洞被后续改动重新打开。七、给报告者的实操建议先定位包再报告确认漏洞位于praisonaiagents、praisonaiPython还是praisonainpm并按上文支持的软件包表格对应到源码路径src/praisonai-agents/、src/praisonai/、src/praisonai-ts/先对照范围用In scope / Out of scope清单自查例如仅影响 fork 部署、或已被显式文档化环境变量覆盖的行为不必提交提供完整信息受影响版本、可复现步骤、CIA 影响评估可选修复建议可显著加快分诊耐心等待补丁在补丁版本发布前保持私有披露发布后通告会为报告者署名并在适用时分配 CVE平台相关漏洞走平台仓库praisonai-platform独立维护、独立发版相关漏洞请在其独立仓库的通告入口提交。八、相关资源SECURITY.md 的 Resources 一节维护了官方仓库、文档站、官网与安全通告聚合入口等链接对维护者与 Agent 贡献者本仓库还提供了标准审计工作流文档 src/praisonai-agents/.agent/workflows/security-audit.md含四阶段流程、分诊标签、版本发布边界与关键规则以及可供学习的安全示例 examples/security/security_example.py 与 examples/python/security_example.py。希望参与安全加固的开发者也可以从本文第六节列出的安全模块源码与测试用例入手了解项目当前的安全边界与防护实现。【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PraisonAI 安全政策与漏洞披露指南：多包生态的安全边界、报告流程与源码级防护实现
PraisonAI 安全政策与漏洞披露指南多包生态的安全边界、报告流程与源码级防护实现【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAI导读本文基于 PraisonAI 仓库根目录的 SECURITY.md系统梳理该多包项目Python SDK、TypeScript SDK、平台端的安全政策全貌哪些包在支持范围、哪些问题属于漏洞报告范围、如何通过私有安全通告Private Security Advisory上报、上报后会经历怎样的处置流程以及维护者侧的标准审计工作流。同时结合仓库源码展示 PraisonAI 在提示注入防御、审计日志、SBOM、依赖审计、PII 脱敏等方向的实际实现帮助开发者、安全研究者和 Agent 贡献者准确理解该项目的安全边界与协作方式。一、支持的软件包与安全边界PraisonAI 以 monorepo 形式维护多个独立发布的产品安全政策按包package划分支持范围。上报漏洞时必须指明具体受影响的包因为平台侧问题不一定影响核心 SDK反之亦然。包名发布渠道Registry仓库源码路径praisonaiagentsPyPIsrc/praisonai-agents/praisonaiPyPIsrc/praisonai/praisonainpmsrc/praisonai-ts/其中praisonaiagents是核心 Agent SDK包含工具tools、MCP、内存、Agent 执行与沙箱sandbox等关键路径praisonaiPython是上层封装/编排层包含 CLI、能力扩展、MCP 服务端、沙箱与 recipe 等praisonainpm/TypeScript是 TypeScript 版本 SDK。独立仓库维护的组件praisonai-platformpraisonai-platform目前在其独立的仓库MervinPraison/PraisonAI-Platform中维护独立进行版本管理与发布不随本仓库 SDK 一起发布。因此平台侧漏洞应通过该独立仓库的安全通告渠道上报而不是在本仓库提交——这一点与维护者审计工作流 security-audit.md 中platform-only 漏洞从不在本仓库处理的规则一致。二、漏洞报告范围In scope / Out of scopeSECURITY.md 对哪些问题值得报告给出了明确清单这有助于研究者在提交前先做自我过滤。属于报告范围In scope认证、授权与多租户隔离问题例如 workspace 边界被突破工具执行、沙箱逃逸sandbox escape与代码执行路径已发布代码中的 SSRF、注入与不安全反序列化MCP、网关gateway以及 Bot/Webhook 集成密钥Secrets处理、JWT/会话配置与默认凭据问题已发布包制品中的供应链supply-chain问题。不属于报告范围Out of scope未由项目维护的 fork 或部署实例中的问题需要物理接触设备或完全攻陷操作员机器才能利用的漏洞针对已不再发布、且无受支持升级路径的版本的报告在文档化、受支持配置下没有实际影响的理论性问题已通过显式文档化 opt-out如仅开发环境使用的环境变量覆盖的行为。从源码角度看上述 In scope 项都能在仓库中找到对应实现面例如 MCP 集成安全在 src/praisonai-agents/praisonaiagents/mcp/mcp_security.py、沙箱安全在 src/praisonai-agents/praisonaiagents/sandbox/security.py、Bot 侧 Webhook 安全在 src/praisonai-bot/praisonai_bot/bots/webhook_security.py以及代码工具的受保护路径守卫见下文防护路径守卫。因此这些条目不是抽象声明而是有具体代码承载的安全关注域。三、如何报告漏洞私有安全通告流程SECURITY.md 要求采用负责任披露responsible disclosure首选方式是打开一个私有private安全通告。上报时请包含以下四类信息受影响的包与版本Affected package and version清晰可复现的步骤Clear reproduction steps影响评估保密性Confidentiality、完整性Integrity、可用性Availability三方面的影响建议的修复方案可选。同时请为分诊triage与补丁发布预留合理时间在补丁版本发布之前不要公开披露。维护者侧对应的工作流要求来自 security-audit.md还包括几条红线供报告者理解项目的处理风格维护者绝不会在公开 issue/PR 中暴露利用细节修复提交使用泛化 commit message如refactor: harden input validation而非暴露攻击向量的标题安全补丁直接在main分支修复并推送不使用特性分支。四、上报后的预期处置流程一旦报告被受理SECURITY.md 明确了四阶段预期Triage分诊——维护者验证报告并给出处置结论real真实漏洞、duplicate重复、wontfix不修复等Fix修复——在main上实施最小化、向后兼容的补丁Release发布——先将修复版本发布到 PyPI/npm再发布安全通告这样 Dependabot 等工具才能把用户指向可用的修复版本Advisory通告——发布 GitHub Security Advisory为报告者署名并在适用时申请 CVE 编号。其中先发补丁、后发通告的顺序是核心原则通告发布时用户必须已经能升级到已修复版本。维护者工作流 security-audit.md 进一步细化了这一过程详见下一节。五、维护者审计工作流从分诊到 CVESECURITY.md 末尾将读者引向维护者/Agent 的官方审计流程文档 src/praisonai-agents/.agent/workflows/security-audit.md该文档以四个阶段完整定义了安全漏洞的标准处置路径这里作要点提炼以下内容均来自该仓库文档Phase 1 — Triage分诊通过gh api列出并读取所有安全通告然后在源码中逐一验证通告所述漏洞是否真实存在或已被修复并打上分诊标签。典型命令形如gh api repos/MervinPraison/PraisonAI/security-advisories \ --jq .[] | \(.ghsa_id) \(.state) \(.severity) \(.summary | .[0:70])Phase 2 — Validate Fix验证并修复修复前必须通过四项校验任何一项不通过都应记录原因并跳到下一条通告是否是真实有效的安全问题而非误报或预期行为修复是否会移除现有功能若会则停止并升级处理修复是否会使 SDK 膨胀只允许最小、聚焦的改动修复是否值得承担复杂度低风险问题可能根本不需要修复。通过校验后在main上做本地修复运行单元测试并为每个修复补充针对性冒烟测试防止后续审计轮次把已修复的漏洞重新打开。Phase 3 — 发布包必须在 Phase 4 之前完成Python 核心 SDK从 src/praisonai-agents/ 目录执行praisonai publish pypi内部走 uvuv lock → uv build → uv publish自动 bump patch 版本需要PYPI_TOKEN环境变量Python 封装层在 src/praisonai/ 目录执行python scripts/bump_and_release.py WRAPPER_VERSION --agents AGENTS_VERSION --wait脚本会等待 core 包在 PyPI 就绪后统一 bump 版本、构建、提交、打 tag、推送并创建 GitHub ReleaseTypeScript SDK仅当漏洞针对 src/praisonai-ts/ 时执行npm version patch npm publishpraisonai-platform绝不从本仓库发布其分诊、补丁、发布与通告全部在其独立仓库完成本仓库没有任何代码 import 它因此平台通告从不要求 SDK 发版。Phase 4 — 更新通告与申请 CVE将通告重新打开为 draft 状态写入patched_versions、vulnerable_version_range与报告者 credits{login: REPORTER_LOGIN, type: reporter}patched_versions必须指向真正包含修复的那个包不要暗示用户需要升级所有包发布通告后再通过 API 请求 CVEGitHub 通常 1~3 个工作日完成审核分配。分诊标签体系标签含义处置动作real可复现的真实安全问题修复 → 发布 → 通告already-fixedmain上已修复但通告仍开启把 patched version 设为当前版本并发布通告duplicate与另一条 GHSA 根因相同关闭或合并链接到主通告not-reproducible无法按步骤复现请求更多细节保持 triage 状态theoretical前置条件苛刻或无实际影响记录理由按 wontfix/低优先级关闭documented-opt-out有文档化逃生通道的预期行为按 wontfix 关闭指向文档/环境变量out-of-scope包、fork 或部署不属于项目发布范围说明理由后关闭版本线与发布边界包版本线说明praisonaiagentspraisonaiPython对齐的 patch 版本例如1.6.62/4.6.62此为文档示例核心 SDK 与封装层通过bump_and_release.py一起发布praisonainpm独立 semverTypeScript SDK从src/praisonai-ts发布praisonai-platform独立 semver独立仓库不从本仓库发布六、仓库中的安全实现佐证源码级安全政策之外当前仓库实际内置了多套可落地的安全能力以下是与其相关的核心实现均为仓库内可核验的代码1. Agent 运行时安全praisonai.security模块入口 src/praisonai/praisonai/security/init.py 提供三项功能且默认零开销、全部 opt-in提示注入防御基于 6 项检查的检测流水线注册在praisonaiagents.hooks的BEFORE_TOOL与BEFORE_AGENT事件上覆盖指令覆盖instruction override、权威声明authority claim、边界操纵boundary manipulation、混淆obfuscation、金融操纵financial manipulation与自伤指令等类别。实现见 src/praisonai/praisonai/security/injection.py其中威胁等级ThreatLevel分为 LOW/MEDIUM/HIGH/CRITICAL 四级严格指令覆盖类短语如ignore all previous instructions、jailbreak、developer mode enabled单次命中即升级为 HIGH 并阻断审计日志追加式append-onlyJSONL 审计日志默认写入~/.praisonai/audit.jsonl可配置是否包含工具输出用于合规场景防护路径守卫对.env、.git/config等关键文件提供受保护路径检查防止 Agent 代码工具误改敏感文件。启用方式极为简单来自 examples/python/security_example.pyfrom praisonai.security import enable_security from praisonaiagents import Agent enable_security() # 一行开启注入防御 审计日志 agent Agent(instructionsYou are a helpful research assistant.) response agent.start(What are the key benefits of open-source AI models?)也可以选择性启用并自定义参数enable_injection_defense(extra_patterns[rACME_SECRET_OVERRIDE])追加公司专属检测模式enable_audit_log(log_path./audit.jsonl, include_outputTrue)记录工具输出。模块还暴露scan_text()可对任意文本单独跑 6 项检查流水线以及is_protected(path)/get_protection_reason(path)检查文件路径是否受保护。需要注意的是源码 docstring 中的明确警告这些 hook 注册在进程级全局的praisonaiagents.hooks注册表上会作用于进程内的所有 Agent在多租户宿主如praisonai serve中不能依赖它做租户级隔离需要保留返回的 hook ID 并通过praisonaiagents.hooks.remove_hook按需拆除——这与 SECURITY.md 将多租户隔离列为 In scope 关注点的定位完全吻合。2. Recipe 供应链安全SBOM、签名与依赖审计src/praisonai/praisonai/recipe/security.py 针对 recipe可复用的 Agent 配方包提供供应链安全能力直接呼应 SECURITY.md 中供应链问题在范围内的条目SBOM 生成generate_sbom()支持 CycloneDX 1.4 与 SPDX 2.3 两种格式自动收集 praisonai 自身版本、lockfile 中的 Python 依赖支持 uv.lock / requirements.lock / poetry.lock以及 recipe 声明的工具与外部依赖Bundle 签名与验证sign_bundle()/verify_bundle()使用 RSA-PKCS1v15-SHA256 对.praisonbundle 的 SHA-256 哈希签名校验时先比对哈希再验签防止 bundle 被篡改依赖审计audit_dependencies()定位 lockfile、收集依赖清单并在可用时调用pip-audit检查已知漏洞输出 vulnerabilities/warnings 报告与passed结论Lockfile 校验validate_lockfile()支持strict模式——严格模式下缺失 lockfile 即判定失败非严格模式仅给出可复现性警告PII 检测与脱敏detect_pii()/redact_pii()内置 email、phone、SSN、信用卡、IP 地址等正则模式支持allow/redact/deny三种策略模式deny 模式下检测到指定 PII 直接抛SecurityError。完整的可运行演示见 examples/security/security_example.py。3. 安全相关的测试保障仓库在多个包内都维护了安全加固与回归测试例如 src/praisonai-agents/tests/unit/test_security_hardening.py、src/praisonai-agents/tests/unit/test_security_audit_fixes.py核心 SDK 侧以及 src/praisonai/tests/unit/test_security_fixes_core.py封装层侧此外还有针对 MCP 安全的 src/praisonai-agents/tests/test_mcp_security.py 与沙箱安全的 src/praisonai-sandbox/tests/test_docker_security.py 等。从这些测试文件的命名与分布可以推断项目对已处置的 GHSA 普遍采用每个 GHSA 一条回归测试的策略以阻止已修复漏洞被后续改动重新打开。七、给报告者的实操建议先定位包再报告确认漏洞位于praisonaiagents、praisonaiPython还是praisonainpm并按上文支持的软件包表格对应到源码路径src/praisonai-agents/、src/praisonai/、src/praisonai-ts/先对照范围用In scope / Out of scope清单自查例如仅影响 fork 部署、或已被显式文档化环境变量覆盖的行为不必提交提供完整信息受影响版本、可复现步骤、CIA 影响评估可选修复建议可显著加快分诊耐心等待补丁在补丁版本发布前保持私有披露发布后通告会为报告者署名并在适用时分配 CVE平台相关漏洞走平台仓库praisonai-platform独立维护、独立发版相关漏洞请在其独立仓库的通告入口提交。八、相关资源SECURITY.md 的 Resources 一节维护了官方仓库、文档站、官网与安全通告聚合入口等链接对维护者与 Agent 贡献者本仓库还提供了标准审计工作流文档 src/praisonai-agents/.agent/workflows/security-audit.md含四阶段流程、分诊标签、版本发布边界与关键规则以及可供学习的安全示例 examples/security/security_example.py 与 examples/python/security_example.py。希望参与安全加固的开发者也可以从本文第六节列出的安全模块源码与测试用例入手了解项目当前的安全边界与防护实现。【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考