Jenkins插件，提供脚本审批工作流和Groovy沙箱，以强制执行安全的脚本执行，带有ACL感知的权限检查和管理员的允许列表管理。
（改编自 CloudBees 插件指南中 模板插件 的信息）
多个 Jenkins 插件要求用户定义自定义脚本，最常见的是使用 Groovy 语言，以定制 Jenkins 的行为。如果编写这些脚本的每个人都是 Jenkins 管理员——特别是拥有 Overall/RunScripts 权限（例如脚本控制台链接所使用的权限）——那么他们可以编写任何他们喜欢的脚本。这些脚本可以使用插件所用的相同 API 直接引用 Jenkins 内部对象。这类用户必须完全受信任，因为他们可以对 Jenkins 做任何事情（甚至更改其安全设置或在服务器上运行 shell 命令）。
然而，如果某些脚本作者是只有有限权限的“普通用户”（例如 Job/Configure），则不适合让他们运行任意脚本。为了支持这种角色分工，脚本安全库插件可以集成到各种功能插件中。它支持两个相关的系统：脚本批准和 Groovy 沙箱。
第一个且更简单的安全系统是允许运行任何类型的脚本，但必须经过管理员的批准。有一个全局维护的已批准脚本列表，这些脚本被判定不会执行任何恶意操作。
当管理员保存某种配置（例如一个 job）时，由管理员编辑的脚本会自动获得批准，无需进一步干预即可运行。对于由较低权限用户提交的脚本，将出现适当的警告，指示需要批准。管理员可以使用“脚本批准”配置页面或通过编辑脚本并保存来批准这些脚本。在以前版本的脚本安全插件中，管理员可以通过直接保存由非特权用户提交的脚本（不做任何修改）来自动批准它们，但此功能已被禁用，以防止基于社会工程的攻击。（“保存”通常指通过 Web UI 进行操作，但也可能通过 REST 或 CLI 上传新的 XML 配置。）
当非管理员保存模板配置时，会检查任何包含的脚本是否已从已批准的文本进行过编辑。（更准确地说，是检查请求的内容之前是否已被批准过。）如果未获批准，则会向队列中添加一个批准请求。（当脚本的当前文本未获批准时，配置屏幕 UI 中也会显示一条警告。）
管理员现在可以转到 管理 Jenkins » 处理中脚本批准，其中会显示待批准的脚本列表。只要请求的内容看起来没有危险，点击“批准”即可让脚本今后得以运行。
如果你尝试运行未批准的脚本，它会直接失败，通常会显示一条消息说明正在等待批准。一旦脚本获得批准，你可以重试。此行为的具体细节可能因集成此库的功能插件而异。
等待管理员批准对脚本的每一个更改（无论看起来多么微不足道）在跨时区团队或紧迫的截止日期下可能是不可接受的。作为替代选项，脚本安全系统允许无需批准即可运行 Groovy 脚本，只要它们将自己限制在被认为固有安全的操作中。这种受限的执行环境被称为沙箱。（目前没有可用于其他语言的沙箱实现，因此所有非管理员配置的非 Groovy 脚本都必须经过批准。）
要切换到这种模式，只需在 Groovy 脚本输入字段下方勾选“使用 Groovy 沙箱”复选框。沙箱化脚本可以由任何人立即运行。（即使是管理员，脚本也受同样的限制，无论编写者是谁。）当脚本运行时，每个方法调用、对象构造和字段访问都会对照白名单进行检查。如果尝试执行未获批准的操作，脚本将被终止，并且相应的 Jenkins 功能暂时无法使用。
脚本安全插件自带一个较小的默认白名单，集成插件可以向该列表添加操作（通常是该插件特有的方法）。
但你不必局限于默认白名单：每当脚本因尝试执行尚未列入白名单的操作而失败时，该操作会自动添加到另一个批准队列中。管理员可以前往上述用于批准整个脚本的同一页面，查看待批准的操作列表。如果点击某个操作签名旁边的“批准”，它将立即被添加到白名单，并可供沙箱化脚本使用。
大多数签名形式为 method class.Name methodName arg1Type arg2Type…，表示一个具有特定“接收者”类（this）、方法名和参数类型列表的 Java 方法调用。（将提供尝试调用的方法的最通用签名以供批准，即使实际调用对象是覆盖该方法的更具体类型。）你可能还会看到用于静态（类）方法的 staticMethod、用于构造函数的 new 以及用于字段访问（获取或设置）的 field。
在安全敏感环境中的管理员应仔细考虑要列入白名单的操作。更改持久化对象状态的操作（例如 Jenkins jobs）通常应被拒绝。大多数 getSomething 方法是无害的。
但请注意，即使是某些“getter”方法也会检查特定权限（使用 ACL：访问控制列表），而脚本通常由系统伪用户运行，该用户拥有所有权限。因此，例如 method hudson.model.AbstractItem getParent（获取包含 job 的文件夹或 Jenkins 根目录）本身是无害的，但后续可能的调用 method hudson.model.ItemGroup getItems（列出文件夹内按名称排序的 jobs）会检查 Job/Read。这第二个调用如果无条件列入白名单将是危险的，因为这意味着在文件夹中拥有 Job/Create 权限的用户将能够从该文件夹中的任何 jobs 中读取至少部分信息，即使这些 jobs 根据基于项目的授权策略本应是隐藏的；只需在文件夹中创建一个包含如下 Groovy 脚本的 job 即可（具体细节因集成插件而异）：
println("嗅探到: ${thisjob.getParent().getItems()}!");
运行时，脚本输出将至少显示出本应保密的项目名称。管理员也可以点击“批准，但假设进行权限检查”，这样当脚本作为实际用户运行时（如果集成插件确实这样做）将允许该调用，而作为系统用户运行时（更常见的情况）则禁止该调用。在这种情况下，getItems 实际上被实现为仅返回当前用户有权限访问的 jobs，因此如果在前一种情况（作为特定用户）下运行，描述将只显示他们本来就能看到的 jobs。这个更高级的按钮仅对方法调用（和构造函数）显示，并且仅在你知晓 Jenkins 正在进行权限检查时才应使用。
对于典型的 Groovy 集成，如果你想为用户提供使用脚本批准或沙箱的选项，请将你的描述对象（describable）中 String 类型的脚本字段改为 SecureGroovyScript 字段。在你的构造函数中，在存储值之前，调用 configuringWithKeyItem（如果每个顶级项目只应有一个此类脚本）或 configuringWithNonKeyItem（如果可能有多个）。配置表应使用 <f:property field="…"/> 来获取脚本和沙箱配置。当你想要运行脚本时，只需调用 evaluate 方法。
（为了兼容旧数据，请选择一个不同的字段名称并将原始字段标记为已弃用。然后你可以定义一个 readResolve 方法，将新字段设置为一个关闭沙箱的 SecureGroovyScript，并对其调用 configuring(ApprovalContext.create()) 以通知系统已加载了一个未批准的脚本，然后取消设置旧字段。）
如果你需要比 SecureGroovyScript 提供的更多控制，请使用以下方式：
在配置中引入一个布尔型沙箱字段。
当未设置时，你需要在 @DataBoundConstructor 中调用 ScriptApproval.configuring。使用 ApprovalContext.withCurrentUser，并在适用时（每个 job 仅有一个脚本时）使用 withItemAsKey；否则至少使用 withItem（如果适用），和/或使用 withKey（当你能够从上下文中唯一标识此用法时——StaplerRequest.findAncestorObject 在此处很有帮助）。这会让系统知道某个（可能是新的）脚本已由特定人员配置。你还需要一个 readResolve 方法，当从磁盘加载了可配置的脚本时（此时配置者未知），调用 configuring 通知系统。在脚本运行时调用 ScriptApproval.using，并在必要时捕获 UnapprovedUsageException。描述器应对脚本字段使用表单验证并调用 ScriptApproval.checking（通常你的描述器应已对该字段执行至少语法检查）。
当设置了沙箱字段时，你只需使用 GroovySandbox.createSecureCompilerConfiguration 设置 Groovy shell，然后调用 GroovySandbox.run；同时准备捕获 RejectedAccessException 并调用 ScriptApproval.accessRejected。
要预批准某些特定方法调用，如果你在插件中，只需用 @Whitelisted 注解它们；否则，你可以注册（使用 @Extension）一个委托给 StaticWhitelist.from 并加载列出白名单方法的文本文件的 ProxyWhitelist。
当构造一个 GroovyShell 来评估脚本，或调用 SecureGroovyScript.evaluate 时，你必须传递一个 ClassLoader，它代表脚本的有效类路径。你可以使用 Jenkins 核心的加载器、你的插件加载器或 Jenkins.getInstance().getPluginManager().uberClassLoader。
无论你选择什么，都不要允许非特权用户通过创建 URLClassLoader 来添加任意类路径条目！这将使使用沙箱时容易被绕过所有安全性。（用户只需让本 job 或另一个 job 归档一个包含某个带有 @Whitelisted 静态方法并能执行任意操作的类的 JAR，然后从其脚本中调用该方法。）在使用整个脚本批准时，尚未证明存在此类攻击——具有正常父类优先委托的 URLClassLoader 不允许通过受损版本轻松伪装无害的 API——但某些巧妙地使用 META-INF/services/org.codehaus.groovy.transform.ASTTransformation 或类似机制可能会导致原本安全的脚本以意外和未授权的方式运行。JENKINS-22834 提出了一个安全的标准化替代方案。
当为使用脚本安全插件的插件编写测试时，你可能会遇到一些测试错误。
如果你的测试直接或间接调用了 ScriptApproval.get() 方法，则你的单元测试必须使用 JenkinsRule，以便 Jenkins.getInstance() 不返回 null。很可能之前正常工作的测试现在会失败，如果你没有使用沙箱的话。这是因为它们被加入到了批准队列中。如果你需要无论批准与否都执行脚本，ScriptApproval.get().preapprove(script, GroovyLanguage.get()) 将确保所有配置的脚本都被批准。或者，你可以让测试使用沙箱运行脚本。在这种情况下，你可能需要将测试中使用的方法列入白名单——要么针对真实用户全局性地，要么使用 @TestExtension 来设置仅供测试使用的白名单。
请参见 更新日志。