第47章 Unsloth Studio 与 Desktop 的安全保障机制

unsloth

下载

☰ 下载

博客：Unsloth Studio 和 Desktop 如何保障安全 2026年10月6日 • Unsloth 团队 2026年10月6日 • Unsloth 团队

你的安全对我们很重要，也是我们构建 Unsloth 时始终坚持的原则。无论你是在尝试新模型，还是在推进项目，我们都希望你在使用 Unsloth Studio 和 Unsloth Desktop 时感到安心。我们通过模型下载检查、工具使用管控和账号保护措施来落实这份用心，同时还会审查代码、检查每个版本所包含的软件。

下面带你了解幕后进行的安全检查，以及你在使用 Unsloth 时会看到的各种控制选项。

模型运行前的检查

当你从 Hugging Face 选择一个模型时，Unsloth 会在运行自定义代码前先检查其仓库。我们会拦截试图开启反向 shell、访问云元数据或窃取凭证的代码。如果模型需要运行仓库中的自定义代码，系统会先征求你的许可，才会以 trust_remote_code=True 方式运行。

例如，deepseek-ai/deepseek-ocr 会请求批准，并提示一条 exec/eval 发现。moonshotai/Kimi-VL-A3B-Instruct 同样会请求批准，并带有高级混淆标记。在我们的改编版仓库 unsloth/DeepSeek-OCR 和 unsloth/DeepSeek-OCR-2 中，我们已移除 eval 调用及其他问题代码段。即使扫描器没有发现任何可疑之处，自定义代码仍需你的许可。

模型的自定义代码需要批准。对话框会在你决定前展示扫描发现。

我们还会检查模型在 Hugging Face 上的恶意软件扫描状态。测试仓库 mcpotato/42-eicar-street 会被禁止加载，并显示警告，列出存在风险的文件，说明这些文件从未被下载。在 PyTorch 模型加载方面，我们要求 PyTorch 2.6 以上版本，使 .bin 权重以 weights_only=True 方式加载。

被拦截的模型下载，警告中列出了受影响的文件。

工具权限由你决定

我们希望你对机器上运行的内容保持掌控。代码执行依赖操作系统沙箱：Linux 上使用 bubblewrap，macOS 上使用 Seatbelt，Windows 上使用 MXC。HTML 和 MCP 制品则在带有独立 Content Security Policy 的沙箱框架中渲染，生成的内容也有自己的隔离边界。

你可以选择 ask、auto 或 full 三种批准模式。在 auto 模式下，网络和文件系统导入会被标记等待批准，文件路径也需要批准，危险的 shell 命令则会被直接拦截。建议选择满足工作所需的最低权限模式，并在批准前仔细阅读代码执行请求。

文件编辑操作会暂停等待你的决定，你可以允许或拒绝该请求。

保护账号与凭证

Unsloth 会限制登录失败次数，失败过多后会显示重试倒计时。密码使用加盐的 PBKDF2-HMAC-SHA256 存储。首个管理员密码由系统随机生成，首次登录时必须更换。

保存的提供商凭证均经过加密。在浏览器中输入的 API 密钥，会用为该安装实例专门创建的 RSA 密钥加密。

在共享安装环境中，受管账号只能访问自己的文件夹，无法读取所有者的 Hugging Face token，需要所有者授权才能使用模型，并被禁止运行仓库代码。这让安装所有者可以放心共享访问权限，同时保持各账号权限清晰。

所有者与受管账号相互独立，访问权限由所有者控制。

通过 HTTPS 远程连接

如果你想远程访问 Unsloth，unsloth studio --secure 会通过 Cloudflared 隧道提供仅限 HTTPS 的端点。配置时需要注意一个细节：隧道不会关闭已监听在所有网络接口上的服务器的原始端口。

HTTPS 只加密连接本身，但工具仍以你的操作系统用户身份运行。任何拿到 API 密钥并有网络访问权限的人，都能在这台机器上执行代码。请妥善保管凭证，在对外暴露 Unsloth 时使用 --disable-tools，并在启用隧道前阅读远程访问指南。

阅读安全远程访问指南

检查构建中的每个环节

保障安全也意味着检查我们交付的软件。一个版本的发布依赖的不只是我们自己的代码，因此我们对依赖更新、安装脚本和构建流程也做了相应检查。

npm 设置 min-release-age=7 会拒绝最近七天内发布的软件包。allowScripts 白名单限制了哪些包可以运行安装脚本，一旦有未审查的内容试图运行，CI 就会失败。Lockfile 和 npm ci 保证安装可复现，安装程序会将用户升级到 npm 11 或更高版本。

在执行任何 npm ci 或 cargo fetch 之前，lockfile_supply_chain_audit.py 会检查是否存在 Shai-Hulud 式注入的迹象。scan_npm_packages.py 和 scan_packages.py 会检查 npm tarball 和 PyPI 包，包括读取凭证的安装脚本。

代码检查工具会扫描不安全的加载器和动态执行，并通过基线跟踪发现结果。编译代码路径有单独的动态执行白名单。我们还运行 pip-audit、带签名校验的 npm audit 以及 cargo audit，排查依赖中的已知问题。

贯穿开发全程的安全审查

开发过程中，我们使用 Codex Security 和多轮 Codex 审查，在代码变更时就发现安全问题与 bug。CodeQL 和 Semgrep 提供进一步的代码分析。Dependabot 更新设有三到七天的冷却期，每个 GitHub Action 都固定到具体的 commit SHA，而非可能被篡改的 tag。

一次 Codex Security 审查示例。其结果仅适用于所审查的 commit。

验证 Desktop 版本

预构建的 llama.cpp 二进制文件会与其发布版 SHA-256 摘要进行校验。另有独立的工作流审计 Windows 版 llama.cpp 的签名。所有 Unsloth Desktop 版本都会经过 VirusTotal 扫描。

这个 Desktop 版本示例在扫描时，70 家厂商中检测数为 0。

日常安全使用 Unsloth

守护你的安全是我们持续进行的工作。扫描和审查帮助我们及早发现问题，软件迭代过程中我们也会不断检查。每项检查结果只针对当时被检查的文件或 commit，因此任何单项检查都无法覆盖所有情况。

一些日常好习惯同样重要：保持 Unsloth Studio、Unsloth Desktop 及其依赖为最新版本，花点时间审查代码执行请求，妥善保管访问凭证。选择一种恰好满足工作所需权限的批准模式。完整细节和本文中的示例都可以在我们的安全文档中找到。

阅读 Unsloth 安全文档

通过界面运行和训练模型 免费开始使用

加入我们的 Discord