安全代码执行实际上需要什么

Source: Dev.to

每个人都声称提供安全的代码执行，但大多数运行代码的平台——在线评测、沙箱 API 或嵌入式执行引擎——只依赖表层保护就算完事：超时、基本的容器化，或许还有内存限制。这不是安全，而是侥幸。

如果你在生产环境中运行任意代码，“安全”必须意味着更严格的要求。下面是实现真正安全代码执行所需的要点。

硬资源边界（不仅仅是超时）

• 超时可以防止无限循环，但不能防止：
  • 内存耗尽攻击
  • Fork 炸弹
  • CPU 饥饿
  • 文件描述符滥用

真正的安全执行需要：

• 硬性的 CPU 限额（例如 cgroups）
• 硬性的内存限制
• 进程数量限制
• I/O 约束
• 严格的执行时间强制

没有这些，恶意脚本就能削弱甚至崩溃宿主机器。

真正的隔离（短暂且可销毁）

在多次运行之间复用容器是风险所在。安全的执行引擎应当：

• 为每次执行生成全新的、短暂的容器
• 运行之间不共享任何状态
• 完成后立即销毁环境
• 避免持久化的可写层

如果状态持久化，攻击面会不断累积。

网络边界

不受限制的网络访问会把沙箱变成跳板。安全系统必须定义：

• 明确的出站策略
• 无内部网络可见性
• 无主机访问权限
• 防止特权提升

隔离必须在网络层面强制，而不仅仅是文件系统层面。

可预测的失败模式

安全不仅是防御，还包括在压力下的行为。安全的执行引擎必须：

• 在过载时快速失败
• 对每个租户强制配额
• 在并发执行时保持隔离
• 提供确定性的限制

如果引擎在并发情况下崩溃，那它是脆弱的——而非安全的。

明确的架构边界

安全代码执行是一种架构纪律，而不是功能开关。面向生产的模型需要：

• 薄层 API
• 严格的编排组件
• 容器管理器
• 集中签名日志
• 可审计的执行追踪
• 控制平面与执行平面之间的清晰分离

安全是系统性的，而不是装饰性的。

为什么这很重要

我们正进入一个时代：

• AI 代理执行真实代码
• 教育平台运行不可信代码片段
• 内部工具自动化基础设施任务
• DevOps 工作流触发动态执行

攻击面在不断扩大。如果“安全”仅等同于 “Docker + 超时”，我们就在低估问题。

安全代码执行应当意味着

安全的执行引擎应当保证：

• 硬性的 CPU 限额
• 硬性的内存上限
• 进程隔离
• 短暂的运行环境
• 网络限制
• 确定性的失败模式
• 可审计的日志

低于此标准的只能算是便利，而非安全。

最后思考

真正的问题不是 “它能运行代码吗？” 而是 “当代码试图破坏你的系统时会发生什么？”

如果你正在构建或采用代码执行引擎，请提出严苛的问题。安全不是一个勾选框，而是一种架构立场。